ERC-8403: Account Authority Lifecycle

ERCs
1

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:

  1. 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?
  2. Leaf encoding: RECOMMENDED keccak256(authority_id || predicate) with account-defined tree shape — strong enough, or should the tree shape be normative?
  3. 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.

1 Like
2

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.

1 Like
3

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.

1 Like
4

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?

1 Like
5

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.

1 Like
6

I ran one more portability check against the reference PoC, and I think it closes the remaining recovery question without forcing a single tree shape or account model.

The PoC itself exposes the boundary. In the Python model, the leaf is H(authority_id || predicate) while cls exists outside the leaf. In the Solidity verifier, leafOf() commits authorityId, kind, cls, expiry, and data, and changeSet() makes cls outcome-relevant because an ACT authority cannot amend the authority set.

So root reconstruction by itself is still a weaker property than portable authority reconstruction. A foreign wallet can reproduce a committed set correctly while some input capable of changing an add/rotate/revoke decision remains outside the semantics it reconstructed.

I would make the recovery rule exact: a recovery scheme that claims portability MUST define every outcome-relevant input used to interpret an authority record, in addition to the leaf encoding, tree shape, and ordering. Anything outside that scheme is custom/opaque. A foreign wallet may still verify the root, but it MUST NOT claim semantic portability for an interpretation it cannot reproduce.

The conformance test then becomes simple: given the same committed authority record, the same recovery/interpretation scheme, and the same relevant evaluation context, two conforming implementations must not disagree on whether that authority permits the same lifecycle transition. Same root + same record + same scheme, but opposite answers to the same add/rotate/revoke question means the scheme is not portable.

This does not require standardizing ACT/AMEND, a universal predicate vocabulary, or one Merkle structure. It only keeps “I reconstructed the commitment” from silently becoming the stronger claim “I reconstructed what this authority means.” Standard schemes can provide that stronger guarantee; custom schemes remain valid and own their portability.

The Solidity PoC is already moving in this direction by committing the fields it actually interprets. I would make that invariant explicit in the spec and call the recovery boundary closed.

1 Like
7

good point. the class was outside the leaf in the model but inside leafOf in solidity. fixed that, added a conformance check for it, and put the portability rule in the spec as a MUST.

1 Like
8

one shared tx type is off the table after the split, but the authority record and how you change it can still be shared.

opened two small things, one per eip. 8141 (Update EIP-8141: optional sender-keyed authority read for a shared authorization step by AnkushinDaniil · Pull Request #12340 · ethereum/EIPs · GitHub): let a VERIFY frame read a sender-keyed authority record from an enshrined keystore, optional param, default empty so nothing changes unless a chain turns it on. 8130 (Update EIP-8130: optional model-neutral change digest for portable actor changes by AnkushinDaniil · Pull Request #12341 · ethereum/EIPs · GitHub): an optional model-neutral change digest so one signed key change carries across models and chains. both additive, both keep each model’s own validation.

the read path already runs against the real 8130 keystore in the poc: GitHub - AnkushinDaniil/erc-8403-poc: reference model + foundry verifier for erc-8403 (account authority lifecycle). real bytecode in a live eip-8141 verify frame on nethermind, 37 attack cases. · GitHub

these come out of the lifecycle in Add ERC: Account Authority Lifecycle by AnkushinDaniil · Pull Request #1979 · ethereum/ERCs · GitHub

1 Like
9

Hey. How does the portable change digest handle a configuration returning to an earlier value?

Suppose an authority changes from config A to config B using a signed portable change. It later changes back to config A. Could the original A → B signature become valid again?

Is this prevented by each model’s native replay protection? Or would the portable authorization itself need a nonce or authority epoch?

A fresh outer transaction could carry the old signature. It would be useful to clarify what makes that signature permanently consumed while preserving portability across models and chains.

10

good catch. native nonces don’t seem enough on their own here.

one option that might work without touching the digest shape: field 5 is the full packed actor-config word, and its 4 reserved bytes could hold a per-actor counter the keystore bumps on every accepted change and keeps through revoke and expiry. an old signature then names an old count, so it can’t be current twice. no new field, no chainId pinning, and the native nonce keeps doing transaction ordering.

does that hold from your side, or is there a case it misses?

11

correction to the above: the counter in the actor-config word isn’t enough by itself. those bytes are storage, they don’t go under the signature, so an old grant still passes. the expected count has to be a signed field in the change. and it only matters for the unsequenced (JIT) case, sequenced changes are already covered by the change counter.