In the spirit of the “Making Ethereum alignment legible” @vbuterin blog post, I am looking to create an “L2Beat for wallets” website.
The goal is to compile a list of desirable attributes that a wallet should have, and then to analyze the landscape of currently-existing wallet software and analyze whether they meet these attributes.
Prior art: WalletBeat dot fyi (cannot directly link to it due to Discourse permissions) exists. It currently focuses on very practical features (“Do you support mobile? Can you switch chain to SOME_PARTICULAR_L2?”). I am looking to extend it.
In this post, I am looking to collect desirable attributes from wallet software, rather than specific implementations that can accomplish those attributes. To illustrate the distinction:
| Attribute | Specific implementation |
|---|---|
| Does it use a free and open-source license? | MIT-licensed |
| Can it send a transaction without third parties? | Support broadcasting via own node |
| Does it cryptographically verify the chain state? | Uses Helios as a light client |
| Is the wallet’s monetization strategy transparent? | Charges user-visible fee on swaps |
| Can it withdraw the user’s assets from L2s trustlessly? | Supports self-sequencing on SOME_PARTICULAR_L2 |
Note: In some of the attributes below, some specific implementations that could satisfy this attribute are listed in case where this would otherwise not be obvious.
List of desirable wallet attributes
Here is the list I have come up with so far. I welcome feedback on this.
The list is broken down in broad categories that roughly correspond to “Ethereum values”, in no particular order:
Standards adherence: A wallet should adhere to Ethereum standards. This means it should implement well-accepted EIPs and ERCs, and interoperate well with the Ethereum ecosystem.
Security: A wallet should be secure. This means it should protect the user’s assets.
Privacy: A wallet should be private. This means it should not leak the user’s private information without consent.
Self-sovereignty: A wallet should be self-sovereign. This means the wallet’s features should work reliably without making assumptions about the honesty or availability or third parties.
User experience: A wallet should provide a good user experience. This means it should make the obvious thing easy, and make it more difficult to shoot oneself in the foot.
Transparency: A wallet should be transparent. This means the way it functions should be publicly scrutable.
Security
A wallet should be secure. This means it should protect the user’s assets from thefts, hacks, scams, and other risks.
- Chain verification: Does the wallet bundle a light client to verify L1 state?
- Transaction simulation: Can the wallet simulate transactions and show the effect of a user’s transaction prior to being signed?
- Scam alerts: Does the wallet alert the user about potentially fraudulent transactions they are about to sign?
- Verified backup: Does the wallet verify that the user understands and has backed up the factors used to sign transactions?
- Account recovery: Can users recover their account if they forget one of the factors used to sign transactions?
- Audits: Has the source code recently been audited?
Privacy
A wallet should be private. This means it should not leak the user’s private information without consent, and should offer to interact with the Ethereum protocol as privately as possible.
- Private sending: Does the wallet support sending funds privately?
- Examples: Built-in support for stealth addresses or Privacy Pools.
- Private receiving: Does the wallet support receiving funds privately?
- Examples: Built-in support for stealth addresses or Privacy Pools.
- Private spending: Does the wallet leak information when spending privately-received funds? (Not desirable)
- Examples: Stealth address labeling, anonymous broadcasting of Privacy Pools transactions.
- IP address leak: Can a third party learn associations between IP addresses and Ethereum addresses? (Not desirable)
- Identifying user information: Does the wallet transmit user information to third parties? (Not desirable)
- Example: Some wallets may collect their users’ email address.
- Multi-address correlation: When configured with multiple Ethereum addresses, can a third party learn that these addresses collectively belong to the same person? (Not desirable)
Self-sovereignty
A wallet should be self-sovereign. This means the wallet’s features should work reliably without making assumptions about the honesty or availability or third parties.
- Self-hosted node: Can users use their own Ethereum node for L1 interactions?
- Transaction censorship: Can users self-broadcast a transaction without being blocked by a third party?
- L2 withdrawals: Can users withdraw their funds from L2s trustlessly?
- Trustless frontends: Can users use popular dapps trustlessly?
- Examples: Built-in IPFS support, ENS domain name resolution, ERC-6860 frontend support.
Transparency
A wallet should be transparent. This means the way it functions and it is developed should be publicly scrutable.
- Source visibility: Is the source code visible to the public?
- Open-source licensing: Is the source code licensed under an open-source license?
- Funding transparency: Is the wallet transparent about its monetization strategy, if any?
- Examples: VC funding disclosures, token allocation transparency, user-visible swap/onramp fees.
(Note: The above does not include “audits”, because that is already covered under Security.)
User experience
A wallet should provide a good user experience. This means it should make the obvious thing easy, and make it more difficult to shoot oneself in the foot.
- Chain auto-switching: Does the wallet automatically switch to the correct chain necessary to do so?
- Chain abstraction: Does the wallet assist the user in (transparently) bridging assets (either L1-to-L2, L2-to-L1, or L2-to-L2)?
- Address resolution: Does the wallet resolve named addresses when sending assets?
- Examples: ENS domain name resolution when sending funds.
- Non-native gas payments: Can users pay transaction fees in assets other than the chain’s native gas token?
- Permission revoking: Does the wallet assist in monitoring and revoking token permissions?
Standards adherence
A wallet should adhere to Ethereum standards. This means it should implement well-accepted EIPs and ERCs, and interoperate well with the Ethereum ecosystem.
- Browser integration standards: Does the wallet support EIP-1193, EIP-2700, EIP-6963? (For browser-based wallets only)
- EOA compatibility: Does the wallet support EOAs?
- Account abstraction: Does the wallet support insert-your-favorite-AA-ERC-here wallets?
- Address standards: Does the wallet support ERC-3770 addresses?
- Login standards: Does the wallet support ERC-4361 (Sign-In with Ethereum)?
- Token standards: Does the wallet support and display ERC-20, ERC-721, and ERC-1155 tokens?