Draft ERC defining a modular plugin architecture for ERC-4337 smart-contract accounts (account interface + plugin manifest + execution / validation / hook function types). Originally championed by Alchemy; in 2024 most of the AA ecosystem (Safe, ZeroDev, Biconomy, Rhinestone) consolidated on the simpler ERC-7579, leaving ERC-6900 as a richer-but-heavier alternative. Status: Draft.
- 01Alchemy Modular Account v2 deployments
- 02smart accounts needing plugin manifests + standardized hooks
- 03audit-friendly plugin permissioning
- pnpm add @alchemy/aa-accounts @alchemy/aa-core
- # reference impl: https://github.com/erc6900/reference-implementation
Build on ERC-6900 when you need richer plugin manifests than ERC-7579 offers. Account exposes `installPlugin(plugin, manifestHash, pluginInstallData, dependencies)`, `uninstallPlugin(plugin, config, pluginUninstallData)`, `executeFromPlugin(bytes calldata)`, `executeFromPluginExternal(address target, uint256 value, bytes calldata data)`. Each plugin declares a manifest enumerating `executionFunctions`, `validationFunctions` (userOpValidation + runtimeValidation), `preExecutionHooks`, `postExecutionHooks`, and dependencies on other plugins. Use Alchemy's Modular Account v2 (the canonical 6900 implementation) and the @alchemy/aa-accounts SDK. Compare with ERC-7579 — pick 6900 only when you need the formal manifest + dependency graph; pick 7579 (most of the ecosystem) for simpler validator/executor/fallback/hook module types and broader cross-vendor compatibility.
- ⚑ERC-6900 vs ERC-7579: SAME problem space, INCOMPATIBLE module ABIs. A 7579 validator will NOT install on a 6900 account and vice versa. Pick one per account; modules must be ported, not reused.
- ⚑Status is Draft and the spec went through major revisions (v0.7 → v0.8) that broke manifest layout — old plugins do not install on new accounts. Pin a spec version in your account's deployer.
- ⚑Manifest hash MUST match the plugin's on-chain `pluginManifest()` byte-for-byte at install time — any change (even reordering function selectors) requires uninstall + reinstall, which can leave the account in a partial state if a hook reverts.
- ⚑Plugin dependencies form a DAG — uninstalling a plugin that another plugin depends on reverts. There is no automatic cascade; integrators must topologically order uninstalls.
- ⚑`executeFromPluginExternal` lets a plugin call ARBITRARY external contracts on behalf of the account. The manifest's `permittedExternalCalls` allowlist is the ONLY guard — a permissive manifest is equivalent to giving the plugin full account authority. Audit every plugin's manifest before install.
- ⚑Bundler validation rules (ERC-7562) restrict storage access during validation — complex 6900 validation plugins frequently violate the rules and get silently dropped from the alt-mempool. Test against your target bundler's tracer before shipping.