Discussion thread for ethereum/ERCs#1979 (ERC-8403, Account Authority Lifecycle).
This proposal defines a shared lifecycle for the authorities that authorize a native account-abstraction account: how an authority (a signing key, or a predicate such as a lock or a limit) is added, rotated, and revoked. An authority is a leaf in a per-account committed tree whose root the account publishes referenceably; a transaction carries a membership proof and names the root it proves against, and the account verifies it in its own authorization step and withholds authorization on failure. Add is a leaf insertion, rotate a replacement, revoke a removal, each a new committed root. It adds no transaction type, opcode, or consensus rule.
The point I would most like feedback on: the lifecycle is stated over a committed root and a membership proof, not over one model’s opcodes, so it binds to more than one account-abstraction family as a peer of each. The PR gives a normative binding to EIP-8141 frame transactions and an informative binding to the EIP-8130 keystore family. That is what lets one transaction type serve both a code-is-authority account and a keystore-backed account without branching on the model or reading a foreign keystore during validation: both reduce to proving the acting authority under the account’s named root.
The EIP-8130 mapping is close to free: an actor’s (actorId, config) is already (authority_id, predicate), and authorize/revoke batches are already add/rotate/revoke. The one primitive that family does not yet publish is a referenceable current-state root over the actor set; its Stateless Accounts proposal already names a compact “proof of chain” as a later, unspecified addition, and this standard’s committed-root binding is that piece for authority state. Because the birth actor set is already committed by sorted leaves, publishing the current set over the same leaves is additive.
Two conformance tiers make the one trade-off explicit: Tier 1 (root-bound, no mutable reads, mempool-cheap, revocation bounded by the recency window) and Tier 2 (one monotonic read, next-block revocation). Both keep invalidation account-bounded.
Feedback I would value:
- The EIP-8130 binding is informative pending a published current-state root — is “the missing primitive is a published root” the right framing, or should it be a joint spec item?
- Leaf encoding: RECOMMENDED
keccak256(authority_id || predicate) with account-defined tree shape — strong enough, or should the tree shape be normative?
- Carried capabilities (a sponsor proven under its own root) and prompt revocation via Tier 2 — is the cross-account binding rule tight enough?
Complementary to ERC-8286 (module/validation-flow surface): this fixes the authority-datum lifecycle underneath. Spec and preamble in the PR.
Small update to the spec (pushed to the PR): I added an “Authority-set availability and recovery” section after a good question on what happens to the leaf data if a wallet is uninstalled, a vendor shuts down, or a device is wiped — the on-chain root stays valid, but a hiding commitment can’t rebuild its own leaves.
The framing I landed on: recovery isn’t a mechanism to add, it’s a premise to drop. The authority set is public state, not the wallet’s private record. So an account SHOULD keep its authority tree in enumerable on-chain state with the root a deterministic function of it; recovery is then just reading current state from any node, rebuilding the canonical tree, and checking the root matches. The wallet’s copy is a cache — losing it is a re-read, not a loss. It inherits state availability (what every full node keeps), with no separate backup, event replay, or checkpoint.
This stays off the hot path: validation is still a stateless proof against a named root; the state read is an infrequent, account-initiated recovery step. An account MAY instead publish only the root and keep leaves off-chain for privacy or to minimize state, taking responsibility for their availability — and there an event-log record of leaf preimages is the reconstruct-from-history fallback.
Would love views on whether the enumerable-state default should be a SHOULD or left fully to the account.
From a wallet user’s perspective, I’d prefer the recoverable on-chain option to be the recommended default. Losing a device, uninstalling a wallet, or a wallet provider shutting down should not risk losing access to important account information. Ideally, another wallet could rebuild it automatically and clearly confirm that everything matches the account.
Thanks, this is helpful, and hearing it from the wallet side is the part that matters. The enumerable on-chain option as the recommended recovery default seems like the right call to me too, so that a lost device or a vendor shutting down is closer to a re-read from any node than a loss. Still framing it as a SHOULD rather than locking it, but I lean that way.
The “another wallet could rebuild it automatically and clearly confirm everything matches” part is worth being precise about, since it asks for a bit more than the root check alone. To rebuild without the original wallet, a second wallet would need three things from chain: the leaf set, the leaf encoding, and the tree shape that combines them into the published root. The first two are already pinned (enumerable state, recommended keccak256(authority_id || predicate)). The tree shape is currently left account-defined, and that looks like the gap: with an arbitrary shape a foreign wallet can recover the leaves but may not be able to re-derive the root to confirm the match you are after.
The direction I would be cautious about is mandating a single tree shape, since the standard is deliberately stated over a committed root and a membership proof rather than one model’s structure, and a fixed shape might stop it binding to different account families as a peer of each. A discoverable recovery scheme feels like the better fit to explore: the account names which reconstruction it uses (encoding, shape, ordering), and a wallet dispatches on that. Standard schemes would give portable cross-wallet recovery, a custom shape stays allowed but the account would own its portability. I want to think this through more before proposing anything concrete.
One thing I find interesting is that this seems to land on the same open piece as the keystore binding: portable recovery might be a concrete reason that family benefits from publishing a referenceable current-state root over its actor set, rather than only an in-wallet convenience. So my rough inclination is recovery as an opt-in property with a discoverable scheme, but I would not want to commit to a shape here before more input. Does a small set of standard schemes plus a deterministic root-match sound roughly like what would work on the wallet side?
Yes, from a wallet-user and product perspective, that sounds like the right direction. A small set of recognized recovery methods could help another wallet rebuild and verify the account, while still allowing custom setups when needed. The important part for users is that a wallet can clearly show whether recovery is fully portable, only partly supported, or still depends on the original provider.