Primary Team ID: 17
Secondary Team ID: 34
Table of Contents
You might have heard about a number of cases where the private keys of the users get compromised leading them to lose all their funds. Multi-sig functionality aims to remove these kinds of security breaches. Multi-sig Wallets refer to smart contract wallets having multiple owners and a number of threshold signatures required to execute a transaction. With multisig the users can add an additional layer of security since the attacker can not initiate any transaction from the smart contract account, without the required number of signatures. In this snap, we have applied the Gnosis Safe‘s implementation of multi-sig wallet.
The following flow diagram shows our implementation of multi-sig wallet using metamask snap:
A multi-sig wallet consists of multiple auths and a minimum number of the auths need to sign the transaction to execute it. We aim to ease the use of multisigs for users, by providing them the following features:
- A user can easily have their multisig wallet generated, the owners and set the threshold.
- Our snap runs a cron-job tracking the generated multisig wallet, and keeps track of its owners and the current threshold and updates a storage with it.
- Now whenever any owner of the multisig wallet initiates/proposes a transaction by signing it, the cron-job running on each individual snap checks if the signature is intended for their multisig wallet. If the user is one of the owner of the multisig wallet, a pop-up will appear on metamask asking for their signature showing them all relevant details.
- As a signature is sent the global signature array is updated and the current_threshold increased.
- Now as the current threshold reaches threshold-1, the last user signs the transaction, and along with that execuutes the transaction.
- In this way, the user doesn't need to keep track of the safe-wallets manually, for every transaction intended for his safe-wallet, he'll get the notifications and any dapp can easily integrate the multi-sig functionality providing security to their users.
This snap brings in an additional layer of security to metamask. Losing the private key of the account should not be the reason for anyone lossing all assets hence this feature provides the much needed layer that saves users even after lossing the key. The snap utilises a time-based one-time password (TOTP) which is a temporary passcode generated by an algorithm that uses the current time of day as one of its authentication factors. The user gets this one time password (TOTP) on his favorite Authenticator mobile app on initiating a transaction. A secret is generated using a one-way function and is passed on to generate the TOTP. This TOTP is same accross all the authenticator apps and the user can use any authenticator mobile application of his choice to genrate the TOTP. The transaction can only be signed upon providing the correct TOTP. On each transaction initiation, the snap prompts up the user to enter the TOTP using the snap_dialogue which is then verified using some algorithms. If the code is verified, the user can sign the transaction. However, the transaction would not be proceeded if the code fails verification.
A malicious dapp can misguide users with its front end. For example, a buy button can withdraw all funds. In such a situation, the transaction snap will give a summary of the exact details of what the transaction will do with the user’s funds. As the name suggests, it shows the entire transaction summary of the upcoming transaction before signing the actual transaction in simple understandable language. This snap provides the user with an AI generated summary for the transaction they are currently performing. This snap provides the contract source code and the function the user is interacting with OpenAI's GPT engine, that generates an user-friendly insight for the ongoing transaction.
Smart Contract wallets are the wallets that control funds through code unlike Private Key as is the case with Externally Owned Accounts (EOAs) and provide a number of functionalities in a wrapper. The snap uses a factory contract to generate a smart contract account for each EOA with functions like whitelisting contracts, multiple authorities etc. The architecture we chose for the smart contract accounts is an upgradable one wherein any new functionality can be added easily depending on the choice of the master owner or the auths and any functionality can be easily removed. Some of the modules that we have added to the contract are - Role based multiple auths, Whitelisting smart contracts, MEV resistant swapping of tokens. MEV Resistant Swap - This feature allows the user to perform token swaps, using a aggregator consisting of various dexes such as Uniswap V2, Paraswap, 1Inch and ZerEx. The swaps are MEV resistant, as we are calculating the output amount off-chain and comparing it with the expected amount and incase the amount we are recieving is less than that of the calculated one, the transaction reverts and prevents the user from being front-runned.
- Batch Transaction - If the user wants to execute many transactions but does not have enough gas fees to do so. Then batch transaction comes in where the user can batch/compile many transactions into one and execute all by paying the gas fees for just one transaction. A perfect example of this is transaferring ethers or erc20 tokens to different addresses in a single click, let's say a payroll, leveraging which includes supplying, borrowing and then again supplying. All these transactions are done as a single batched transaction which helps users to save gas fees.
- Multiple auths - The owner becomes the master owner and can add multiple auths to handle his transactions using a role based system. Also, if an auth looses his rights, the other auths have the power to help him regain it.
- Whitelisting - The smart contract wallet allows user to whitelist specific contracts, for specific functionalities. This feature saves users' funds from any contract that might be trying to steal them .
This snap enables the user to simulate the initiated transaction (using Tenderly's API) before signing. By simulation, a user can actually see the results of the transaction without sending them on-chain. This creates an environment where in case the transaction is going to fail, the user gets an idea beforehand about the failure and the errors that the transaction may encounter. If the transaction is going to succeed, the user gets a track of the final results.
Many of the crypto users have their funds in their wallet and recieve their payment in crypto. There can be cases when the user wishes to stake a part of their salary or funds in a periodic manner. Using this snap, we bring in this user convenience, a user can set the protocol, percentage of his funds, he/she want to stake periodically, the period of which is also set by the user. As soon as the user's address receives the payroll, after the set duration, there will be a metamask notification showing the same and will ask for approval of the transaction of the percantage set of assets from his/her account .
The periodic notification will be sent using metamask cron-job so that users dont have to keep a track of the incoming assets and staking them manualy to the DEXs .
This snap allows the user to fetch the smart contracts which have been approved by him for dealing with his ERC20 tokens. Any time the user can see the tokens, the spender and the allowance provided to them. This saves users from interacting with any pirated site (linked to a contract) that he/she might have interacted by unknowingly. This snap also allows users to revoke approval to any spender smart contract that was approved earlier.
There are scenarios when users want to look for someone else's address positions on snap to get an idea of which and how much assets are being holded by that address. This snap allows the user to view the position of any other user’s address in DeFi protocols like AAVE, Compound etc. In future, we plan to add a virtual playground for users which allows them to play around with someone else's postions in a forked environment.
___
- As snap is relatively newer tech so it was a bit difficult to find the resources for debugging while developing. However people were helpful enough on their discord channel to help us keep building .
- We utilised the latest build of metamask from the
develop
branch. There were no docs around that so we had faced some challenges, trying out things with hit-and-trial most of the time or back-tracing the releases. - Since snap was a new feature for our entire team to work with, and it is still in its development stage we faced issues with running our snaps, with them crashing multiple times, or getting temrinated in mid of our testing.
- Some functionalities of snaps like cron-job or manage state were a bit tricky to deal with due to the limited functionalities it offers in this stage, like we couldn't find the ways to stop a cron-job, or how to store efficiently in a manage state.
- As we have built a number of snaps so it was challenging to integrate all the snaps into one and make it all in one snap .
- Install Metamask flask extension version 10.24.x from the metamask-extensions Github repository.
- Add it to your browser.
- For Firefox enter
about:debugging#addons
and load the extension there. - For Chrome activate the developer mode and add the unzipped package of the extension.
- Clone the repository using
git clone
. - Make sure that you have Node.js version 16.x installed.
- Install all the dependencies:
yarn
- Start the localhost server:
yarn start
- Install all the dependencies:
yarn
- Start the localhost server:
yarn start
- Ensure that you have python version 3.9.x.
- Create a virtual environment:
virtualenv sssenv
Activate it:
source sssenv/bin/activate
- Install all the dependencies:
pip install -r requirements.txt
- Copy the
example.env
to.env
and then set yourAPI_KEY
andPORT
. - Run the server:
python decompile.py
Go to http://localhost:8080 to see the test app.