ERC-6900 primary sources — 2026-05-07

Project status in this pass

  • No standalone ERC-6900 whitepaper or litepaper surfaced.
  • The clearest current source of truth was the draft ERC itself, supplemented by the official docs site and the reference implementation README.
  • The sources consistently frame ERC-6900 as a richer module-and-account standardization effort for smart accounts, not as a single-wallet design.

Primary-source snapshots

1) Canonical ERC page

  • URL: https://eips.ethereum.org/EIPS/eip-6900
  • Key excerpt/signals:
    • The abstract says ERC-6900 standardizes smart contract accounts and account modules, emphasizing secure permissioning and maximal interoperability.
    • It says the modular approach splits account functionality into three categories implemented in external contracts.
    • The draft is explicitly ERC-4337-compliant.
  • Why it mattered:
    • This is the clearest source-level evidence that ERC-6900 belongs in the corpus as module-interoperability infrastructure for wallet authority.

2) Raw ERC text / motivation

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-6900.md
  • Key excerpt/signals:
    • The motivation says smart-account features such as session keys, subscriptions, spending limits, and role-based access control are currently fragmented across incompatible implementations.
    • It says module developers otherwise face platform lock-in or duplicated support work.
    • It frames the standard as coordination between account developers and module developers.
  • Why it mattered:
    • These passages show the actual economic point of the standard: reduce extension-surface lock-in and make the wallet/module boundary more portable.

3) Raw ERC text / module model and interfaces

  • URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-6900.md
  • Key excerpt/signals:
    • The standard defines three modular function families: validation, execution, and hooks.
    • It requires modular accounts to implement account-management and execution interfaces, and modules to implement IERC6900Module with lifecycle methods like onInstall and onUninstall.
    • It includes execute, executeBatch, executeWithRuntimeValidation, validation installation flows, manifests, and account/module identifiers.
  • Why it mattered:
    • This is the strongest evidence that ERC-6900 is more than a naming convention: it is a full plugin ABI and lifecycle standard for smart-account authority.

4) ERC-6900 documentation site

  • URL: https://erc6900.io/
  • Key excerpt/signals:
    • The docs say ERC-6900 is laying the groundwork for permissionless innovation in modular smart accounts.
    • They say the standard exists to address fragmentation and platform-specific implementations.
    • They define two explicit goals: standardizing modules for smart accounts and standardizing how compliant accounts interact with those modules.
  • Why it mattered:
    • The docs reinforce the interpretation that ERC-6900 is attempting to create an ecosystem-wide market for portable modules, not just describe one account implementation.

5) Reference implementation README

  • URL: https://raw.githubusercontent.com/erc6900/reference-implementation/main/README.md
  • Key excerpt/signals:
    • The README says the implementation prioritizes clarity over optimization and that the contracts generally are not audited and should not be used in production.
    • It includes reference accounts, an account factory, validation modules, allowlist and spending-limit permission modules, and token-receiver support.
    • It points contributors toward an active standards discussion surface.
  • Why it mattered:
    • This source makes the module market concrete: the intended ecosystem includes portable permission modules, validation modules, and account variants rather than only abstract interfaces.

Working conclusion

ERC-6900 is best cataloged as modular smart-account plugin infrastructure. The decisive evidence in this pass was the draft ERC’s anti-fragmentation motivation, its standardized account/module lifecycle and execution surfaces, the docs site’s explicit push for permissionless modular-account ecosystems, and the reference implementation’s concrete examples of portable policy modules.