Summary: ERC-7484 is best understood as trust-routing infrastructure for modular smart accounts rather than as a wallet, audit marketplace, or standalone attestation product. Its core move is to standardize how ERC-7579 accounts query security attestations about third-party modules before installing or invoking them. The important categorization clue is that ERC-7484 does not decide which modules are safe; it standardizes the registry and adapter boundary through which accounts inherit outside security judgment. That makes it a control point for how trust gets imported into modular wallet ecosystems.
What it does:
Defines a standard registry interface for checking whether a module has enough valid attestations from trusted attesters
Lets accounts store internal trusted-attester sets plus thresholds via trustAttesters, or query against explicitly supplied external attesters
Requires registries to support attestation revocation and creator verification before accepting attestations
Supports module-type-aware checks so an account can distinguish validation, execution, or other module classes before installation
Requires smart accounts to implement adapter behavior that queries the registry before or during first module use and treats registry reverts as security-relevant
Includes a reference design for an ownerless singleton registry intended to concentrate attestation liquidity across the modular-account ecosystem
Key claims:
The draft ERC says it standardizes both module registries and registry adapters so modular smart accounts can verify module security irrespective of their architecture, which is the clearest sign this belongs in the corpus as interoperability infrastructure
The motivation section says unchecked third-party modules open a wide range of attack vectors for ERC-7579 smart accounts, framing ERC-7484 as the security complement to wallet modularity rather than a generic metadata registry
The core registry interface centers on check(...) calls plus trustAttesters(...), showing the standard is really about thresholded trust delegation into named attesters, not just a list of audited modules
The specification requires registries to allow revocation and to revert when the attestation threshold is not met, which means failure of the trust layer is meant to block module use rather than merely warn about it
The adapter rules say a registry must be queried at least once before or during a module’s first use and that a registry revert is itself a security risk, which makes registry availability part of the account’s effective security model
The rationale argues for an ownerless singleton registry because it increases “attestation liquidity” and module interoperability, which is a strong clue that ERC-7484 creates a potential Schelling point and rent sink around trusted attester sets
The same rationale also highlights the main tradeoff: a singleton improves coordination and propagation speed but concentrates failure risk if an attacker can forge or compromise trusted attestations
The ERC-7579 documentation site frames ERC-7484 as the standard way for smart accounts to verify module security via a module registry, reinforcing that it is an extension layer in the modular-account stack rather than a separate product category
Whitepaper: No standalone ERC-7484 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC, the raw ERC markdown, and the ERC-7579 documentation page for the extension; see ../../whitepapers/erc-7484-primary-sources-2026-05-07.md.