ERC-7484 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-7484 whitepaper or litepaper surfaced.
• The clearest source of truth was the draft ERC itself, backed by the raw ERC markdown and the ERC-7579 extension documentation page.
• The sources consistently frame ERC-7484 as the trust and attestation layer for modular smart-account modules, not as a wallet product or a simple audit directory.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7484
• Key excerpt/signals:
  • The abstract says the proposal standardizes module registries and registry adapters so modular smart accounts can verify module security.
  • The motivation says unchecked third-party modules create a wide range of attack vectors for ERC-7579 smart accounts.
  • The proposal says accounts should be able to query any compliant module registry irrespective of architecture, execution flow, or security assumptions.
• Why it mattered:
  • This is the clearest evidence that ERC-7484 belongs in the corpus as shared trust-routing infrastructure for modular wallets.

2) Raw ERC markdown

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7484.md
• Key excerpt/signals:
  • The core registry interface revolves around check(...) functions and trustAttesters(uint8 threshold, address[] calldata attesters).
  • The registry must verify attestation creators, allow revocation, and either store attestation data or a reference to it.
  • The registry must revert if the attestation threshold is not met or if provided attesters are not unique and sorted.
• Why it mattered:
  • These details show that ERC-7484 standardizes thresholded trust delegation into named attesters, not merely a passive metadata catalogue.

3) Adapter behavior in the ERC text

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7484.md
• Key excerpt/signals:
  • The adapter must query the registry about a module at least once before or during the transaction in which it is first called.
  • The adapter should revert the transaction flow when the registry reverts.
  • The adapter should also query on module installation and execution.
• Why it mattered:
  • This is the decisive clue that registry availability and revocation behavior become part of the smart account’s effective security boundary.

4) Singleton-registry rationale in the ERC text

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7484.md
• Key excerpt/signals:
  • The rationale argues a singleton registry improves security by concentrating integrations into one source of truth with many security entities attesting.
  • It also argues a singleton increases “attestation liquidity” and module interoperability.
  • The tradeoff section warns that a singleton creates a single point of failure if trusted attestations are compromised.
• Why it mattered:
  • This is the best evidence that ERC-7484 is not just a technical interface: it creates a likely Schelling point for trust concentration and potential rent capture around attester reputation.

5) ERC-7579 extension docs

• URL: https://erc7579.com/extensions/erc7484
• Key excerpt/signals:
  • The docs summarize ERC-7484 as the standard for module registries that let smart accounts verify module security using a registry adapter.
  • They explicitly tie the need for the standard to the risks of unchecked third-party modules in ERC-7579 accounts.
  • They frame the solution as standardizing both registry functionality and adapter behavior.
• Why it mattered:
  • The ecosystem documentation confirms that ERC-7484 is being positioned as a core extension in the modular-account stack, not as an isolated research draft.

Working conclusion

ERC-7484 is best cataloged as the trust-import layer for modular smart accounts. The decisive evidence in this pass was the draft ERC’s thresholded attester model, its required revocation-aware registry behavior, its adapter rules that elevate registry failure into a security event, and its singleton-registry rationale that makes trust concentration and attestation liquidity central design features rather than side effects.