Wallets were originally created with an emphasis on buying tokens for speculation rather than for practical use cases. However, as crypto becomes more user-friendly, new use cases for them will emerge, making it easier to transmit them to end-users.
The era of rewarding users for taking risks associated with wallet operations is coming to an end. While wallets continue to be the primary means of interacting with the blockchain, we b elieve there is plenty of room for improvement and starting to abstract the financial aspect of wallets to be more ubiquitous to other verticals.
Evolution of Wallets
- Writing down private keys and using public keys to receive bitcoins.
- From custodial wallets to self-custody wallets.
- Self-custody wallets gave access to decentralized apps.
Take the Axie Infinity example: it has plenty of flaws and awful UX, but it has become the biggest play-to-earn game, taking many in the crypto and gaming space by surprise. While the UX was definitely a roadblock, the fact that it was (i) fun and (ii) productive was enough reason for a whole generation to learn about crypto and get onboarded.
The primary issue with crypto lies not in its user experience, but in its lack of utility. While this may seem counterintuitive, it presents an opportunity to bring blockchain technology up to par with other industries where current methods fall short, such as marketplaces, communities, and games.
By taking the premise that everyone will have multiple addresses, addressing its most challenging aspects will allow individuals to experiment and create new verticals and user behaviours that were previously unimaginable with blockchain technology.
Wallets as an Abstraction Layer
Similarly to how we access different websites on the internet today, we do not want the added complexity of using different wallets for different purposes. While wallets are set to gain popularity as an abstraction layer that will accrue the most value (read fat wallet thesis).
We believe wallets should act like Google Accounts, enabling access to new applications (like Google Suite as comparison) that provide new value for end-users.
You are probably already familiar with MetaMask, an External Owned Account (EOA). EOA consists of a cryptographic pair of keys: public and private keys that manage account activities.
The next evolution of EOAs are contract accounts (CAs). CAs don't have a private key. They are smart contracts that are governed by the code's logic within them. Each new iteration adds a new opportunity for wallets to increase the size of the market by serving new use cases (From hardware wallets, to chrome extensions, to mobile apps, to multisigs, executable NFTs, and more).
| Externally Owned Account | Smart Contract Account | |
|---|---|---|
| Creation | Created with an on-chain address linked to a private key. No fees required. | Requires the deployment of a smart contract on-chain. Fees are applicable. |
| Control | Managed with private keys. | Governed by the underlying smart contract code. |
| Functionality | Enables direct transfer of assets and interaction with dApps and other smart contracts. | Highly programmable due to the flexibility of smart contract and account abstraction. |
| Transaction Fees | Mandatory balance in ETH is required for transactions. | Can leverage gas-saving mechanisms. Fee payment possible in stablecoins or other tokens (depending on integrated networks). |
| Security | Security depends on the user's private key management. | More sophisticated with options for 2FA or Hybrid (multisig) security. |
| Recovery | Account recovery is typically not possible. | Supports account recovery options such as social recovery. |
The Future of Wallets
Understanding both types of wallets allows us to see their advantages and limitations and move one step closer to today's innovation in the space, represented by both the concept of Account Abstraction (AA) and Multi-Party Computational (MPC).
On one hand,account abstraction (AA) which requires the use of smart contract wallets (SCW), ranges from simply enhancing blockchain usability to unlocking an entirely new realm of functionality that could catalyze widespread adoption. Mostly represented by ERC4337, can be used for covering user gas costs or allowing users to pay fees in another token, partial/MEV reimbursement with alternative mempools.
On the other hand, MPC uses EOAs and off-chain programmability before you get to the signature part, so users do not need to deploy new addresses on any chain. Furthermore, MPC policies and their signature schemes can be private.
While MPC and SCW have some overlap in use cases, both have their own benefits. For example, a scenario where one uses an MPC signing scheme to control a smart contract wallet.
The key takeaway is that code determines the action of contract accounts, whereas users manage EOAs. This is significant because smart contracts have the ability to execute anything that can be programmed, like offering pop-upless player experience.
If you have more questions/ideas/queries, join our Developer Discord and let us know there. Furthermore, you can follow us on Twitter for our updates as we keep shipping.