Since announcing the Trillion Dollar Security project, we have surveyed the ecosystem to understand which improvements are highest priority to every layer of the Ethereum stack and community.
Now it is time to begin the next phase of this initiative: acting on the highest priority issues we face.
For this first wave of actions, we will mostly focus on UX issues. Our research showed these to be the most urgent issues facing both individual and institutional users of Ethereum and Ethereum-based applications.
During this first wave we will kick off a range of work targeting crucial areas in UX security. The work we begin today is a combination of high leverage short-term actions and long-term projects that we expect will continue for years. We intend to regularly launch new waves of projects, tackling different priority security domains over time. As these projects gain momentum over the next few weeks and months, we will turn our attention to the next wave of priorities targeting other domains.
As always, we are eager to support and collaborate with others working to further improve Ethereum’s security and make Ethereum safer for billions of users and trillions of dollars of on-chain capital. Reach out to us at trilliondollarsecurity@ethereum.org.
1. Coordinating a “Minimum Security Standard” for Ethereum wallets and supporting Walletbeat
Wallet UX is where security begins for all users of Ethereum. If users cannot safely manage keys, sign transactions, and interact with on-chain applications then they cannot use Ethereum safely.
We believe the Ethereum ecosystem should develop and adopt a minimum security standard for wallets, which can serve as a trusted and legitimate reference point for which wallets are safe for ordinary users of Ethereum. We believe this standard should require features like:
Transparent transactionsCompromise-resistant interfacesPrivacy-supporting architectureStandards for wallet behaviour, e.g. approval management, key handling, frontend verification+ more
We are inspired by the success of L2BEAT in educating users and making the security and decentralization properties of L2s transparent to the ecosystem.
We believe a Minimum Security Standard for wallets could help address two different sides of this problem. First, giving ordinary users a reliable guide to choosing only those wallets that meet this standard means that a greater share of Ethereum users will have access to the features they need to have a secure on-chain experience. To do this effectively, the standard must be a very high bar and it must regularly be raised as new security features are developed by the ecosystem or new threats are found. Second, the standard will encourage wallet teams to prioritize important features to remain compliant.
To help develop and promote such a standard, we are excited to be providing a grant to Walletbeat, who have been working towards a similar vision. Walletbeat will be both a contributor to this community standard and an organization that can help do the hard work of measuring wallets against the standard and making information easily accessible to users.
Stay tuned for more information about work on this standard and how to contribute.
2. Unblocking the “tech tree” to solve blind signing
One of the most significant issues facing UX security is blind signing. Users are often expected to sign transactions without the ability to understand what those transactions will do.
Through discussions with ecosystem advisors and our stewards, we have identified a few ways we can help unblock the “tech tree” that will enable more wallets to deploy features to address this problem.
Unblocking transaction decoding
One solution to the blind signing problem is for wallets to decode the raw transaction data, and translate it into a human-readable description of what the transaction will do. Instead of seeing a long string of code, a user might see information like “Transferring 1,000 of token ABC to recipient 0x123”.
One challenge for wallet teams is that this kind of feature requires a comprehensive dataset of function signatures, which requires access to databases of verified contracts, many of which are closed source and require expensive licenses to use.
Over the last few years, the Verifier Alliance (VERA) has been quietly working to address this, and today has built a database of more than eight million contracts. Through our research it became clear that many teams were unaware of the resources VERA offers, and over the next weeks and months we will be promoting their work to ensure that wallet teams are aware of these open source resources, and exploring other ways to maximize the impact of their work.
Secondly, we’re beginning some R&D projects that we believe might unlock new methods for transaction transparency in wallets.
Standards that would encourage applications to add code to their contracts which makes it easier for wallets to interpret transactions.Revisiting past proposals to address this problem which were not prioritized by the ecosystem at the time, like ERC 4430, EIP 7730, EIP 719, and exploring how to continue the work of the Human Readable Transactions Group.
Wallets can even go a step further and actually simulate the results of a transaction in an EVM environment against Ethereum’s current state. This simulation would then return a message like “this X will result in you sending 1 ETH from X to Y, and receiving 1 NFT from collection Y.”
If wallets could reliably categorise the level of trust in contracts with which users are interacting, this would go even further towards solving this problem.
Some wallets offer these features today, but we want to make it easier for more wallets to do so and for all transaction simulation features to be reliable and high quality.
We have also begun multiple R&D projects to explore whether in-protocol improvements on things like opt-in transaction assertions and additional security features would further increase the security of users.
3. Making it easier for developers to avoid deploying vulnerable code
Having an open-source database of smart contract vulnerabilities, which can be used as a reference by IDEs and other developer tooling, is something we believe could help reduce compromised contracts. These tools could scan pre-deployed contracts against the open-source database before deploying the code onchain, allowing developers to more easily detect vulnerabilities in their application before they deploy it.
While not strictly a UX project, we believe this is a high leverage undertaking where the EF is in a unique position to help coordinate a widely used database, and we invite anyone who would like to help, such as audit competition platforms, auditors, white hats, or others, to help contribute their findings.
Once we have a large-scale open-source database in place, the next step is to advocate for tool developers to build features that take advantage of this.
Here’s what the ecosystem can help with:
Ultra simple non-tech wallet
A very common piece of feedback during our survey phase has been that the existing wallets are targeting the tech crowd. There appears to be a high demand for wallets for non-technical users across the world which provide features that practically ensure a secure environment by building guard rails that still allow users to have the on-chain experience. Survey respondents mentioned things such as easy transactions to friends and businesses (not having to type a public key), easy payments for goods and services, built-in basic swapping, and the ability to restore your wallet. If you have ideas on how to address these issues then please reach out.
Enterprise focused wallets
Enterprises have mentioned the importance of privacy, censorship resistance (including external services being used by the wallet to interact with the network), and compliance requirements for key management. If you have ideas on how to address this then please reach out.
