# TIF2 Preliminary Proposal ## <ins>1. Multisig smart contract (Gnosis safe alternative)</ins> category: DeFi & security Releated existing project: https://gnosis-safe.io/ ### Abstract Gnosis Safe is a smart contract wallet running on Ethereum that requires a minimum number of people to approve a transaction before it can occur (M-of-N). If for example you have 3 main stakeholders in your business, you are able to set up the wallet to require approval from all 3 people before the transaction is sent. This assures that no single person could compromise the funds. This is smart contract based wallet/vault/store so it shines in the following areas: - Multi-signature saftey and security - Enourmous capital management - Trust enhancement among stakeholders - flexible, can be used from any existing tezos compatible wallet as a signer - Privacy - Time-based scheduler (offchain) ### Work plan - I am looking forward to build a mimimal generic version equivalent of gnosis-safe and a basic UI to interact with it. - primary aim would be to make smart contract which acts as a proxy and is able to delegate to the target address after confirming signature majority and updates the nonce (to prevent replay attacks) - This smart contract will use storage of itself while executing in the logic in context of target address. - UI will be of 2 pages, one to create a multisig smart contract and other to use created multisig smart contract to interact with other smart contracts. ### Devloper stack - Javascript/Typescript - SmartPy - Truffle(experimental support) - Taquito.js - React.js/Svelte - Nautilus/TezosDatahub & better-call.dev ### Things I will need help with - I am transitioning from ethereum ecosystem so i will need help with converting terminolgies to equivalent in terms of tezos ecosystem. - I am relatively better on smart contracts & backend compared to frontned, so i want to team up with frontend or in general anyone working on same idea. ## <ins>2. All-in-one locking & vesting contract</ins> category: DeFi & security Releated existing project: https://cryptexlock.me/, https://deeplock.io/, https://dxsale.app/, etc. ### Abstract With the DeFi boom, we are witnessing that lots of new tokens are delployed daily. A token may fall in certain categories like utility, meme, social, art, stable value, ecosystem representative and many more. A way-to go live i.e public launch is to put the liqudity out on decentralized exchange in pair with some other token, so users can go to DEX and buy some new token hoping to hold it or store value and captalizing by trusting on entity's goals/protocol/business. However, this comes with several tremendous risk factors and attack vectors. The party who provided liquility on DEX might have lots of extra quantity of same token which they can cash-in once people have bought their token and price has increased. In this case, the token will drop in value (nearly to 0 most of the times) at the cost people who bought that incuring massive losses. This is termed as "Rug Pull", it is technically not a hack or bug, but more of cause of unknown. Best way to prevent the users for falling for such ponzi and evil mindset tokens is to make sure team/entity behind the the protocol/project does not have complete control over large quantity of tokens. Entity can decide vesting schedule (rate at which they want to unlock their tokens) and lock all their remaining tokens after adding liquidity into a secure smart contract which will release them according to vested schedule. For example, a protocol team needs to sell 5% of their token every month for covering the cost of development and business and let's say they utlize 40% of tokens in starting to add liquidty. Remaining 60% is locked in a smart contract from which, team can withdraw no more than 5% each month. This combined with minimal audit of thier FA1.2 or FA2 token will lead to increased security. Every entity/protocol using such methodoly can be considered less vulnerable to "Rug Pull" and can be relatively trusted. So end users who purchase token can check status of lock/vesting and decide whether not invest on that token or not. ### Work plan - Smart contract will have functionality to transfer FA1.2 from caller to itself (i.e lock), transfer locked FA1.2 to only allowed entity as per the vesting schedule (or locking period). - It will also allow to lock & unlock LP tokens as well after carefully re-searching DEX on tezos. - UI will be of three simple pages, create an agreement to lock and provide vesting schedule and second page to unlock the tokens at certain intervals from the locker smart contract. Third page to display all all the locked tokens and thier status. ### Devloper stack - Javascript/Typescript - SmartPy - Truffle(experimental support) - Taquito.js - React.js/Svelte - Nautilus/TezosDatahub ### Things I will need help with - I am transitioning from ethereum ecosystem so i will need help with converting terminolgies to equivalent in terms of tezos ecosystem. - I am relatively better on smart contracts & backend compared to frontned, so i want to team up with frontend or in general anyone working on same idea.