Initial Thoughts

• When considering wallets, how do users engage with different wallets within the ecosystem? In my currentl hypothesis, I have identified the need to separate wallet applications from wallet visualizers. My Zerion wallet is simply my MetaMask visualized on a larger scale, although Zerion does have the capability of creating a new wallet on their platform.
  • Metamask, Phantom, and Argent are actual wallet apps.
  • Rainbow, Zerion, and Obvious serve more as wallet visualizers and social platforms for wallets. They allow the user to import existing wallets and follow/browse other wallets as well.
  • All these wallets have similar features but have named them differently - this ends up confusing the stadard web3 user
    • Ex: Zerion and Rainbow call the action “create a new wallet” whereas metamask calls it “create a new account” - this raises the question of what is a wallet vs what is an account? When do you use one over the other?

Personal Problems (Probably problems other users have as well):

• I have too many wallets with multiple accounts within each (Argent, MetaMask, Phantom, Kepplr, etc.), and it is difficult to remember and keep track of everything. I also don’t know when to create a new account vs new wallet
  • Use one wallet per chain.
  • It is difficult to visualize everything from different chains in one place.
• I do not have a proper method of storing my seed phrases.
• When connecting to a dApp, I always connect with the most accessible wallet I have, which is my MetaMask. However, sometimes I will connect to a dApp using my Rainbow wallet and forget which wallet I connected with earlier.
  • As a result, I am becoming more concerned about the security of my MetaMask wallet because I do not actively strategize which wallet to use for which dApp. This is similar to choosing which credit card to use for maximum rewards (dining credit, travel credit).
    • Just as our commerce brands issue native credit cards (Target Credit Card, Amazon Credit Card, etc.), dApps should do the same in the format of sub-wallets. One separate native account for each dApp that is branched under a wallet identity.
      • This leads me to diversify my funds and assets to my other wallets, which I never use for any dApps and treat like cold storage.
• I want a one-stop wallet solution where I can create multiple sub-accounts for each dApp with different passkeys, but I do not want to actively manage these passkeys. I do not want more than 2-3 steps when creating a new wallet, interacting with a new dApp, or managing all my wallets.

Vitalik stated the follwing in his recent blog post

If you send a transaction at the same time as when many others are sending transactions and the base fee is spiking up, you risk the base fee going too high and your transaction not getting accepted. Even worse, wallet UIs suck at showing this. There are no big red flashing alerts, and very little clear indication of what you're supposed to do to solve this problem.

• Most wallets hide a lot of crucial information from the user, wallets need to be more transparent (think user first)

Who is this product for?

• This product is for native web3 users who interact with dApps on at least a daily basis.
  • They understand the need for a smart wallet and will be more than happy to use something that manages all their accounts.
  • When building such an application, however, we must keep in mind that the user should not feel burdened to manage everything on their own. How can we streamline passkey storage, account suggestion, etc?
• We must onboard new/beginner web3 users early to help them understand proper wallet and security etiquette. However, if we were to have them use this smart wallet, they might be confused.
  • How can we make the smart wallet easy to use for newcomers?

Questions:

• Earlier, I was thinking about the concept of wallet aliases. Have one wallet and create an alias for each dApp you interact with. This is basically the concept of account abstraction. I want to understand if zero knowledge can be used here to mask certain interactions when using these alias wallet addresses.
  • Example: I have my main address as ishika.eth. When I connect to Uniswap, my ishika.eth wallet will make an alias address as, let's say, 123 (think of it as a burner wallet). Any transaction I make on Uniswap should publicly show as an interaction with address 123, but behind the scenes, address 123 would forward the transaction to ishika.eth.
  • Use a ZK-based compliance oracle where You can verify wallet without linking user ID to wallet address
• How can we make the smart wallet easy to use for newcomers?