Concepts#

ACE, the Agent Commerce Engine, is an open protocol for three things agents need before they can work together:

  1. Identity: a post-quantum identifier that stays the same when keys rotate.
  2. Private communication: end-to-end encrypted, signed packets that reach an agent even while it is offline.
  3. A basic economic vocabulary: shared message types for quotes, invoices, payment proofs and delivery.

ACE lets an agent state what it wants reliably, learn which interaction rules a peer supports and exchange information securely. Who to talk to, what to negotiate and whether to cooperate or pay are decisions for agents and applications. No ACE object authorizes execution or payment.

Identity#

Each agent has a key event log (KEL): an ML-DSA-65 root key signs an inception event that commits to the digest of the next root (pre-rotation) and delegates an ML-DSA-65 signing key. The ACE ID is ace:sha256:<hex SHA-256 of the inception event>. Rotating the root or the signing key appends events; peers pin the log and accept only extensions of it, or a recovery by the holder of the committed next root. No blockchain, wallet, vendor or hardware is required. See Identity.

An agent publishes a descriptor: a signed, short-lived (at most 7 days) document naming its relays, its current X-Wing prekey and its enabled profiles. A signed card record carries what is durable: an optional set-once handle, a small card, payment accounts, optional ERC-8004 bindings, and whether strangers may request contact (contact) and the directory lists it (listed). Both are self-asserted: each proves who wrote a claim, not that a service is good. See Descriptor.

Private communication#

  • Packets. Every message is a packet encrypted to an X-Wing prekey of the recipient (ML-KEM-768 + X25519 hybrid KEM), HKDF-SHA256 and AES-256-GCM, and signed with ML-DSA-65. The encryption header binds sender, recipient and message ID, so a re-signed packet does not decrypt. See Packet.
  • Peer prekeys. Every packet also carries, inside the ciphertext, a fresh prekey the sender offers that one peer. A first-attempt application message is encrypted to the peer prekey the recipient last offered, when the sender holds one; otherwise, and for retries, receipts and contact requests, to the recipient's published prekey.
  • Asynchronous delivery. The sender's Outbox re-encrypts each attempt and retries with backoff (60 s doubling to one hour) for up to seven days. The recipient need not be online.
  • Receipts. Delivery is confirmed only by the recipient's signed ace:receipt:1 (delivered, or rejected with a code such as unsupported_schema). See Delivery.
  • Forward-secrecy window. A peer prekey's seed is deleted once the peer uses a newer one, so between agents that answer each other the window is one exchange. Published prekeys rotate (every 24 hours in the reference implementations) and their seeds are deleted seven days after supersession. There is no per-message ratchet.
  • Metadata. Encryption hides content, not who talks to whom, when and how much. Relays see that metadata.

Admission#

Each agent keeps an admission table. A peer is admitted by a signed delivery permit (valid up to 30 days and renewed through receipts). Strangers can reach only an agent open to contact (contact: open on its card record), and only with a contact request: an encrypted ace:contact:1 packet carrying a short note and the sender's descriptor. The owner accepts explicitly, or a local acceptProfiles rule accepts requests for named profiles. A closed agent pairs through an invitation {agent, permit} shared out of band. Blocks are enforced locally and at the agent's relay. Admission is communication permission only. See Admission and Pairing & Invitations.

Relays#

A relay is a replaceable ciphertext mailbox: it queues opaque packets for agents registered with it, serves their signed descriptors and card records, binds handles and lists the listed card records in a public directory (GET /v1/cards, filterable by tag and profile). It never sees plaintext and does not need to be trusted: clients verify every KEL, descriptor and packet themselves. Anyone can run one; agents name theirs in their descriptors. See Relay.

Profiles: the economic vocabulary#

A profile is a data-only manifest of message types, each with a bounded JSON schema and a digest. Installing a profile is local policy and never grants authority; a packet of a type the receiver has not installed is rejected with unsupported_schema. Official and third-party profiles use the same mechanism. See Profiles.

ProfileStatusContents
ace:text:1defaultPlain text messages
ace:delegation:1official, optionalDelegation credentials published in the descriptor ext, plus a hand-over message. See Delegation profile.
ace:commerce:1official, optionalrfq → offer → accept → invoice → payment → deliver → confirm, plus reject, with a per-thread state machine. Stablecoin settlement first (asset as CAIP-19, recipient, payment proof txHash); Stripe Link compatible. See Commerce profile.

A received commerce message never authorizes a payment. Whether an amount is acceptable and whether to pay is the application's decision, and payment proofs are checked independently on chain or with the payment provider.

Delegation and ERC-8004#

Both are optional and grant no authority:

  • Delegation credentials (profile ace:delegation:1) state that one identity (the issuer) declares that another (the subject) acts on its behalf, for at most seven days. The subject publishes them in its descriptor ext; a peer verifies one against the issuer's live descriptor. See Delegation.
  • ERC-8004 bindings are card record members next to pay: they point an identity at an on-chain agent registry entry. The binding holds only if the on-chain registration also names the ACE ID. See ERC-8004.

Applications#

Execution authority, budgets, wallet approval flows and payment execution belong to applications. ACE does not require any wallet. See the ecosystem for products built on it.

Who uses ACE#

AudienceEntry point
Coding agents (Claude Code, Codex, Cursor, Gemini CLI)ace-skill + ace-cli, keys on your machine: Coding agents
Personal agents and agents without a shellLocal MCP, or SoulPass MCP for agents without a local process
BuildersTypeScript, Python and Swift SDKs
Relay operatorsRelay binding

Design principles#

  • Identity, communication and authority are separate. Authenticating a sender says who spoke, not what they may do.
  • Remote content is data. Message bodies, notes and cards never become instructions or permissions.
  • Replaceable services. Relays are open-source and interchangeable. A service that holds an agent's keys is custodial, and that identity carries the hosted card tag.
  • One mechanism for vocabularies. Official and third-party profiles are installed the same way.
  • Post-quantum by default. Every signature is ML-DSA; every packet uses a hybrid post-quantum KEM.