Governance of on-chain agent identity under ERC-8004

ERC-8004 establishes a standard for on-chain agent identity. It does not prescribe how human principals authorise those agents, how authorisations expire, or how revocation propagates. This draft proposes a companion standard — a governance layer atop ERC-8004 — that specifies mandate issuance, scope expression, expiry, and revocation semantics. We release the draft for comment by the ERC-8004 working group.

1. What ERC-8004 specifies and what it doesn't

ERC-8004 specifies a standard for expressing that a given on-chain identity is an autonomous agent rather than a natural person or a legal entity. It provides metadata fields (name, principal, capabilities) and a registration mechanism. It does not specify how a human principal grants the agent specific authority to take specific actions.

In practice, production deployments have invented ad-hoc authorisation schemes atop ERC-8004. These schemes are mutually incompatible, and the incompatibility is the single largest source of friction in cross-operator agent interoperability.

2. The mandate primitive

We propose a mandate primitive: a signed statement from a human principal that authorises a specific agent identity to take a specific set of actions, subject to a scope (what the agent may do), an expiry (when the authorisation lapses), and a revocation rule (how and by whom the mandate can be withdrawn).

Mandates are signed off-chain for gas efficiency but anchored on-chain via their hashes. A mandate registry contract exposes the current validity of any mandate by hash, and agents present mandate proofs alongside every action they take.

3. Revocation is the hard problem

Issuing mandates is straightforward. Revoking them in a way that propagates to all relying parties before the agent can act under the revoked mandate is not. We propose a time-bounded gossip model: revocations are broadcast via a revocation registry with a two-block finality window, and relying parties are required to consult the registry within that window.

This does not achieve instantaneous revocation but achieves production-acceptable finality for most use cases. For use cases requiring stricter revocation (notably custody-signed force-transfer overrides), we propose a synchronous revocation channel as an optional extension.