Smart SAFT

Our project explores the possibilities of moving certain legal documentation on-chain. We looked into SAFT, NDA, and SAFE agreements. Currently, these off-chain forms of documentation are used to dictate on-chain activity, which is obviously not enforceable on-chain. We believe that bridging this gap between web2 and web3, specifically in the scope of SAFT agreements, where we have personally seen multi-million dollar checks pulled illegally by VC's, serves a valuable purpose. Enabling a seamless UX, from on-ramping of crypto directly on our site, to gasless meta transactions and an easy to use UX, is something we hoped to achieve. We develop a dynamic ERC-1155 NFT token standard for representing "signed" states of users for a common legal document. For SAFT agreements in particular, there is an important money movement piece involved, so we integrate with SuperFluid to enable streaming of assets after a certain period. Coupled with our thorough smart contract development, we put together a slick full stack NextJS application, building off the metamask SDK, SAFE's on-ramping, and deployed to several L2's and test networks.

For the UI, we used NextJS to take advantage of both client and server side rendering, and dynamic file system routing. We built our web3 authentication using metamask's SDK, and incorporated SAFE's on-ramp kit for allowing users to on-ramp USDC, if they don't already have. Even further, we incorporate Uniswap v3 protocols to allow users to natively supply a token other than USDC, and we'll execute a swap transaction to USDC (a more easily understood asset, generally should not be volatile compared to other assets). Our smart contracts are built off ERC 1155 standards, where we develop dynamic NFT's referencing the multi-owner contracts and their corresponding signing statuses for a given SAFT/NDA contract. This allows us to pair with the frontend to display to users which states their SAFT/NDA contracts are in, and which actions they are able to take. We built on SuperFluid's vesting scheduler to enable the money-movement component of our contract, where we essentially hold USDC in escrow until an agreed upon date (token unlock), then stream the tokenized equity directly to a user at a given flow rate. We built in Biconomy's meta transactions to sponsor gas for users, which can sometimes be a large deterrent for users. The tokenID is enforceable on-chain, by using a hashed version of important metadata surrounding a contract (such as user's name, company name, document title, etc...), which is stored off-chain for safety.