Wallets don’t need security on day 1, onboarding needn’t be so hard. Here, I present a wallet design that is easy for users to onboard and secure enough when deemed appropriate.
When the user has 0 funds in their wallet, it is OK to have lower security. But a not-so-secure wallet doesn’t scale. How can users have a wallet who’s security adapts to assets in custody?
After researching over 30 wallet apps/extensions - I feel confident that there’s not going to be one wallet to rule them all in the near future.
Every developer serious about their Dapp’s user experience will build their own (disposable) wallet.
The apps should create a private key for the user and manage the transactions using the said private key under the hood. Even better if the app uses a relayer to make sure the end user needn’t have to have crypto to pay gas before they make their first transaction (meta-transactions).
Each app that creates a new wallet for it’s users may or may not be secure. If you are building a web app, you might consider creating a wallet for the user in-browser. Meaning, you just store the wallet’s private key in a localstorage
.
This is a major security risk. But it is OK when the user has just signed up, doesn’t have any funds to lose. The purpose of this wallet is to get started and eventually dispose the wallet.
When the above disposable wallet is created by the app, it should also deploy a smart contract wallet with the newly created in-browser disposable wallet as its designated signatory.
All that this smart contract does is forwards the calls. In other words, all it does is changes the msg.sender
;
This smart contract wallet has 3 modes that gives it progressive security.
The app that provides this disposable wallet along with progressive security should educate the users at the right time to upgrade their security. E.g. move to metamask when you have $100 worth of assets; move to multi sig when you have $10,000 assets etc.
msg.sender
as user identification