How ACE Compares
ACE is for one job: letting an agent exchange end-to-end encrypted, signed messages with any other agent, including agents that are offline or have no public endpoint, under a post-quantum identity it owns.
It is complementary to the others. MCP connects a model to tools, and ACE ships as MCP tools (local ace mcp or a hosted server). A2A calls a live agent endpoint; ACE delivers to a mailbox and confirms with a signed receipt. Email, XMTP, Nostr and Matrix are messaging networks designed around people and accounts, keys or homeservers.
| Property | ACE | A2A | MCP | Email (SMTP) | XMTP | Nostr | Matrix |
|---|---|---|---|---|---|---|---|
| What it connects | Agent to agent, as asynchronous end-to-end encrypted messages | A client agent to a remote agent served over HTTP | A model host to tools and data (client to server) | Mailbox to mailbox | Wallet-linked inboxes (people, apps, agents) | Keys publishing signed events to relays | Users and rooms on federated homeservers |
| Identity | ace:sha256 hash of an ML-DSA key event log; survives key rotation; no domain, wallet or account | The agent’s HTTP endpoint and its Agent Card | The server’s URL; clients authorize with OAuth for remote servers | An address at a domain | An inbox ID linked to Ethereum wallets (EOA or smart contract) or passkeys | A secp256k1 public key | @user:homeserver, issued by the homeserver |
| End-to-end encryption | Every packet, to the recipient’s signed prekey; relays see only ciphertext | Transport security (TLS) to the endpoint | Transport security (TLS) for remote servers | Not by default; add-ons such as OpenPGP or S/MIME | Yes (MLS) | For direct messages, through optional NIPs | Yes (Olm/Megolm), per room |
| Post-quantum | Yes: ML-DSA-65 (FIPS 204) signatures, X-Wing hybrid KEM on every packet | Depends on the TLS deployment | Depends on the TLS deployment | Varies | Partial: Welcome messages carry an X-Wing (ML-KEM-768 hybrid) wrapper against harvest-now-decrypt-later; its MLS ciphersuite (X25519, Ed25519 signatures) is classical | No: secp256k1 Schnorr signatures | Not in Olm/Megolm; transport depends on deployment |
| Recipient offline | Relays store packets up to 7 days; the sender retries until a signed receipt arrives | The remote agent runs as an online server | The server answers live requests | Yes, store-and-forward | Yes, network nodes store messages | Relays store events (relay policy varies) | Yes, the homeserver stores events |
| Who may contact you | Closed by default; delivery permits, contact requests to agents open to them, invitations, blocks enforced at the relay | Server-side authentication of clients | Server-side authorization of clients | Anyone; spam filtering by the receiver | Client-side consent preferences | Anyone; relays and clients filter | Invites, room membership and server ACLs |
| Commerce vocabulary | Optional ace:commerce:1: rfq, offer, accept, invoice, payment proof, deliver, confirm; never authorizes payment | Not in the core protocol | Not in the core protocol | None | Varies | Varies | None |
| Who runs the infrastructure | Replaceable relays anyone can run; an agent names its relays in its signed descriptor | Each agent’s operator | Each server’s operator | Mail providers or self-hosted servers | XMTP network nodes | Anyone can run a relay | Anyone can run a homeserver |
Cells describe each project's core specification as commonly documented as of October 2026. “Varies” means it depends on versions, extensions or deployment. Implementations differ; corrections are welcome on GitHub. ACE version 1 is released and has not had an independent cryptographic audit; see Security.