In the spirit of the "Making Ethereum alignment legible" @vbuterin blog post, I am looking to create an "L2Beat for wallets" website.
I have posted a tentative list on Ethereum Magicians and on Farcaster but I figure I could ask for feedback here as well: What do you think a hypothetical ideal Ethereum wallet should be like?
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 analyse whether they meet these attributes, as a means to put some soft pressure on them to implement these. Similar deal as L2Beat's security assessment of L2s.
I am looking to collect desirable attributes from wallet software, rather than specific implementations that can accomplish those attributes. To illustrate the distinction:
- It's not about "is it MIT licensed?", it's more about "does it use a free and open-source license?"
- It's not about "does it support self-sequencing on Optimism mainnet?", it's more about "Of the L2s it supports, does it support trustlessly withdrawing the user's assets?"
SecurityA 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?
PrivacyA 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-sovereigntyA 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.
TransparencyA 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.
User experienceA 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 adherenceA 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?
