ERC-8001: Agent Coordination Framework

Abstract

---

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.

Motivation

---

Agents in DeFi/MEV 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.

Specification

---

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:

Status Codes

Implementations MUST use the canonical enum defined above:

• 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

Overview

This ERC specifies:

• A canonicalised EIP-712 domain for agent coordination,
• Typed data structures (AgentIntent, CoordinationPayload, AcceptanceAttestation),
• Deterministic hashing rules,
• A standard interface (IAgentCoordination),
• Lifecycle semantics (propose → accept → execute/cancel),
• Error surface and status codes.

EIP-712 Domain

Implementations MUST use the following EIP-712 domain:

Implementations SHOULD expose the domain via ERC-5267.

Primary Types

Typed Data Hashes

Computation (normative):

Clarifications (normative):

• getIntentHash(intent) MUST return intentStructHash (struct hash), not the full digest.
• AcceptanceAttestation.intentHash MUST be that struct hash.
• Each acceptance is signed over its own EIP-712 digest that includes this field.
• participants MUST be strictly ascending by uint160(address) and deduplicated.

Interface

Implementations MUST expose the following interface and events.

Semantics

• proposeCoordination: Rejects: invalid signatures, expired intents, non-monotonic nonces, malformed participants

  Accepts valid EIP-712 signed intents and:

  • Emits CoordinationProposed
  • Makes intent queryable as Proposed
  • Enforces nonce monotonicity for agentId

• acceptCoordination: Rejects: non-existent intents, expired intents, non-participants, duplicate acceptances, invalid signatures

  Accepts valid attestations and:

  • Emits CoordinationAccepted
  • Adds participant to acceptedBy in status
  • Returns true when all required acceptances present

• executeCoordination: Rejects: non-ready intents, expired intents or acceptances, payload mismatches

  Executes when all participants accepted and unexpired:

  • Emits CoordinationExecuted with result
  • Status becomes Executed
  • Returns success and execution result

• cancelCoordination: Proposer MAY cancel before execution; anyone MAY cancel after expiry

  • Emits CoordinationCancelled
  • Status becomes Cancelled

• getCoordinationStatus MUST return one of: None, Proposed, Ready, Executed, Cancelled, Expired

Nonces

ERC-8001 defines a single intent nonce per agent: agentNonces[agentId]. Acceptance nonces are OPTIONAL in ERC-8001. If implemented, they MUST be strictly monotonic per agent.

Errors

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):

• Expired intent
• Bad signature
• Non-participant
• Duplicate acceptance
• Acceptance expired at execute
• Payload hash mismatch

Rationale

---

• Sorted participant lists remove hash malleability and allow off-chain deduplication.
• Separation of intent and acceptance allows off-chain collation and a single on-chain check.
• Keeping ERC-8001 single-chain avoids coupling to bridge semantics and keeps the primitive audit-friendly.
• Wallet friendliness: EIP-712 arrays let signers see actual participant addresses.

Backwards Compatibility

---

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.

Reference Implementation

---

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.

Security Considerations

---

• Replay: EIP-712 domain binding and monotonic nonces prevent cross-contract replay.
• Malleability: Low-s enforcement and 64/65-byte signature support are required.
• Equivocation: A participant can sign conflicting intents. Mitigate with module-level slashing or reputation.
• Liveness: Enforce TTL on both intent and acceptances. Executors should ensure enough time remains.
• MEV: If coordinationData reveals strategy, use a Privacy module with commit-reveal or encryption.

Copyright

---

Copyright and related rights waived via CC0.