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
IERC6900Modulewith lifecycle methods likeonInstallandonUninstall. - 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.