This Contract is in active development. Do not use this in Prod!
Account abstraction (or smart accounts) will deliver three key enhancements for the Ethereum ecosystem: improved UX, enhanced user security and greater wallet extensibility. Modular smart accounts are the next frontier for achieving these goals. However, it also opens up a number of new challenges that could drastically undermine the objective by opening up a plethora of new attack vectors and security concerns for accounts.
The Registry aims to solve this concern by providing a means of verifying the legitimacy and security of independently built smart account modules for installation and use across any integrated smart account. It allows entities to attest to statements about modules and smart accounts to query these at module installation and/or execution time. The Registry is a Singleton that is free, open and permissionless. It also serves as the reference implementation for ERC-7484.
pnpm installpnpm testAttestations on the Registry represent statements about Modules. An Attestation is made using a particular Schema that is used to encode and decode the Attestation data. The most important usecase for Attestations is to make statements about the security of a Module.
An attestation consists of two primary elements: the Schema and the Attestation data. The Schema acts as a standardized structure for creating and validating Attestations, defining how the Attestation data is encoded and decoded.
Schemas represent predefined structures utilized for the formation and verification of Attestation data. Using flexible Schemas rather than a single, fixed Schema allows Attesters to encode their data in a custom way, providing flexibility when creating Attestations. For example, the data of an Attestation about the outcome of the formal verification on a Module will have a very format than the data of an Attestation about what interfaces a Module supports.
Resolvers are external contracts that are tied to Modules and called when specific Registry actions are executed. These actions are:
- attestation
- revocation
- module registration / deployment
This architectural design aims to provide entities like Smart Account vendors or DAOs, with the flexibility to incorporate custom business logic while maintaining the robustness and security of the core functionalities implemented by the Registry
Attesters are individuals or organizations responsible for creating and signing Attestations. They add the Attestation to the Registry, making it available for verification.
Modules are smart contracts that act as modular components that can be added to Smart Accounts. The registry is agnostic towards Smart Account or Module implementations. Only Module addresses and deployment metadata are stored on the registry.
Modules are registered on the Registry either during, using CREATE2, CREATE3 or a custom deployment factory, or after deployment.
The following is a table of the gas differences between the Registry and a minimal ERC-7484 registry that only has one attester. As you can see, the gas difference is negligible for 1 or 2 attesters, but the Registry scales much better than using multiple single attester registries.
To run the tests yourself, run forge test --mc RegistryGasComparisonTest -vv.
Note: The gas calculation numbers include the gas cost for CALL
| # of Attesters | Registry | Minimal7484Registry | Difference |
|---|---|---|---|
| 1 | 7983 | 7706 | +277 |
| 2 | 15472 | 15418 | +54 |
| 3 | 20823 | 23124 | -2301 |
| n (approximation) | 5299n + 4901 | 7709n |
Current address: 0x500684cBaa280aDf80d5ACf7A32Daebb23162e63
For feature or change requests, feel free to open a PR or get in touch with us.
For the continuous support and constructive feedback, we would like to thank:
- Ethereum Foundation
- ERC-4337 Team
- Richard Meissner (Safe) @rimeissner
- Taek @taek.eth
- Biconomy
- Heavily inspired by EAS
 zeroknots 💻 |
 Konrad 💻 |