ERC-8001 defines a minimal, single-chain primitive for multi-party agent coordination. An initiator posts an intent and each participant provides a verifiable acceptance attestation. Once the required set of acceptances is present and fresh, the intent is executable. The standard specifies typed data, lifecycle, mandatory events, and verification rules compatible with EIP-712, ERC-1271, EIP-2098, and EIP-5267.
ERC-8001 omits privacy, reputation, threshold policies, bonding, and cross-chain semantics. Those are expected as optional modules that reference this specification.
Agents in DeFi/MEV/Web3 Gaming and Agentic Commerce often need to act together without a trusted coordinator. Existing intent standards (e.g., ERC-7521, ERC-7683) define single-initiator flows and do not specify multi-party agreement.
ERC-8001 specifies the smallest on-chain primitive for that gap: an initiator's EIP-712 intent plus per-participant EIP-712/EIP-1271 acceptances. The intent becomes executable only when the required set of acceptances is present and unexpired. Canonical (sorted-unique) participant lists and standard typed data provide replay safety and wallet compatibility. Privacy, thresholds, bonding, and cross-chain are left to modules.
The keywords “MUST”, “SHOULD”, and “MAY” are to be interpreted as described in RFC 2119 and RFC 8174.
Implementations MUST expose the following canonical status codes for getCoordinationStatus:
Implementations MUST use the canonical enum defined below:
None = default zero state (intent not found)
Proposed = intent proposed, not all acceptances yet
Ready = all participants have accepted, intent executable
Executed = intent successfully executed
Cancelled = intent explicitly cancelled
Expired = intent expired before execution
This ERC specifies:
AgentIntent, CoordinationPayload, AcceptanceAttestation),IAgentCoordination),Implementations MUST use the following EIP-712 domain:
Implementations SHOULD expose the domain via ERC-5267.
Computation (normative):
Clarifications (normative):
getIntentHash(intent) MUST return intentStructHash (struct hash), not the full digest.AcceptanceAttestation.intentHash MUST be that struct hash.participants MUST be strictly ascending by uint160(address) and deduplicated.Implementations MUST expose the following interface and events.
The functions defined in this specification MUST exhibit the following externally observable behaviours.
This standard does NOT prescribe storage layout, execution model, or internal mechanisms.
proposeCoordinationproposeCoordination MUST revert if:
AgentIntent under the ERC-8001 EIP-712 domain;intent.expiry ≤ block.timestamp;intent.nonce is not strictly greater than getAgentNonce(intent.agentId);participants is not strictly ascending and unique;intent.agentId is not included in the participants list.If valid:
CoordinationProposed MUST be emitted;getCoordinationStatus MUST report Proposed;getAgentNonce(intent.agentId) MUST equal the supplied nonce;getRequiredAcceptances(intentHash) MUST equal the number of participants.acceptCoordinationacceptCoordination MUST revert if:
attestation.expiry <= block.timestamp.If valid:
CoordinationAccepted MUST be emitted;acceptedBy list returned by getCoordinationStatus;true;Ready.Otherwise the function MUST return false.
executeCoordinationexecuteCoordination MUST revert if:
Ready state;intent.expiry <= block.timestamp;payloadHash.If valid:
executionData;(success, result);CoordinationExecuted MUST be emitted;getCoordinationStatus MUST report Executed.cancelCoordinationOn success:
CoordinationCancelled MUST be emitted;Cancelled.getCoordinationStatusgetCoordinationStatus(intentHash) MUST return:
None if the intent does not exist;Proposed if not all participants have accepted and the intent has not expired;Ready if all participants have accepted and expiries have not elapsed;Executed if execution has occurred;Cancelled if cancellation has occurred;Expired if the intent has expired and was not executed or cancelled.getAgentNonce(agent) MUST increase for every valid new intent.proposeCoordination MUST reject nonces not strictly greater than the stored nonce.Implementations SHOULD revert with descriptive custom errors (or equivalent revert strings) for the following baseline conditions, and MAY define additional errors for domain-specific modules (e.g. slashing, reputation, or privacy conditions):
ERC-8001 introduces a new interface. It is compatible with EOA and contract wallets via ECDSA and ERC-1271. It does not modify existing standards.
A permissive reference implementation is provided in contracts/AgentCoordination.sol. It uses a minimal ECDSA helper and supports ERC-1271 signers. It enforces participant canonicalisation, intent nonces, acceptance freshness, and all-participants policy.
coordinationData reveals strategy, use a Privacy module with commit-reveal or encryption.Copyright and related rights waived via CC0.