Summary: ERC-6900 is best cataloged as a module-system standard for smart accounts rather than as a wallet product or a single account implementation. Its core move is to standardize how modular accounts install, uninstall, inspect, and route execution through external modules covering validation, execution, and hooks, so features like session keys, spend limits, and policy logic can become portable building blocks instead of wallet-specific one-offs. The important categorization clue is that ERC-6900 tries to standardize the full account-module relationship — including manifests, lifecycle hooks, runtime validation, and inspection surfaces — which makes it more like a rich plugin ABI for wallet authority than a minimal interface shim.
What it does:
Standardizes modular smart-contract accounts that comply with ERC-4337 while also supporting direct calls from EOAs and contracts
Splits account extensibility into validation functions, execution functions, and hooks, with modules able to implement one or more of those roles
Defines install and uninstall flows for execution and validation modules, plus manifests describing selectors, hooks, and interface exposure
Standardizes execution surfaces such as execute, executeBatch, and executeWithRuntimeValidation
Requires ERC-1271 support and defines how runtime validation, user-operation validation, and signature validation modules fit into the account lifecycle
Exposes optional account-view interfaces so onchain observers can inspect installed modules, validation flags, selectors, and hook configuration
Key claims:
The draft ERC says it standardizes smart contract accounts and account modules with secure permissioning and maximal interoperability between compliant accounts and modules, which is the clearest reason to classify it as module-interoperability infrastructure
The motivation explicitly says current smart-account features such as session keys, subscriptions, spending limits, and role-based access control are fragmented across native account implementations and proprietary module systems
The ERC says users should gain portability while module developers avoid platform lock-in or duplicated support work, which frames the standard as a market-structure attempt to keep wallet vendors from fully owning the extension surface
The specification standardizes not just interfaces but module manifests, lifecycle hooks, runtime validation routing, and inspection APIs, making ERC-6900 a much richer plugin system than a simple account wrapper
The official ERC-6900 docs say the standard is laying groundwork for permissionless innovation in modular smart accounts and explicitly position it as an ecosystem-wide account/module interaction standard
The docs point to a dedicated reference implementation, showing that ERC-6900 is not just a paper proposal but an actively coordinated implementation effort
The reference implementation README says the contracts prioritize clarity over optimization and are generally not audited, which is useful because it shows the current state is still closer to standard-shaping infrastructure than production-safe canon
That same README includes allowlist and spending-limit hook modules, a single-signer validation module, and token-receiver execution support, which makes the intended module market tangible rather than theoretical
Ethereum.org’s EIP-7702 guidance explicitly points dapps toward ERC-6900 as one of the standardized wallet interfaces through which 7702-enabled capabilities should surface, which is a strong adoption signal beyond the draft ERC itself
Whitepaper: No standalone ERC-6900 whitepaper or litepaper surfaced in this pass. The clearest sources were the draft ERC, the official documentation site, and the reference implementation README; see ../../whitepapers/erc-6900-primary-sources-2026-05-07.md.
Reusable lens: if a wallet sells smart wallet flexibility, the real question is still who can install, inspect, approve, or quietly default modules after first setup.