Intelligent Commerce Protocol (ICP)

StateSet’s open protocol for agent-native commerce — intent verbs, signed mandates, verifiable JWS receipts, and ACP/UCP/MCP/A2A compatibility.

Intelligent Commerce Protocol (ICP)

ICP is StateSet’s open protocol for agent-native commerce: one wire contract that lets any autonomous agent discover merchants, quote baskets, authorize payment, complete checkout, track fulfillment, and handle returns — across currencies, jurisdictions, and payment rails, under a verifiable mandate.

The current specification version is 2026-04-21.

Positioning

ACP terminates ChatGPT checkout. UCP provides platform-neutral checkout interop. ICP subsumes both — it is the superset spec a globally-distributed fleet of agents can target as a single, stable contract, with the engine of record sitting inside the handler process.

Protocol	What it covers	What it leaves out
ACP (OpenAI, 2025)	ChatGPT Instant Checkout — session create, update, complete, plus delegated payment vault tokens	Agent identity, mandates, budgets, negotiation, returns, subscriptions, stablecoin payments, global jurisdictions, peer (A2A) commerce
UCP (StateSet, 2026-01)	Platform-neutral checkout interop with discovery, tokenization, OAuth identity linking, AP2 mandates, order webhooks	Negotiation, declarative intent model, verifiable receipts, embedded engine, peer-agent payments, first-class global commerce
MCP (Anthropic)	Agent tool surface	Commerce semantics — MCP tools are untyped for the commerce lifecycle
A2A (Google)	Agent-to-agent task protocol	Commerce semantics

Design principles

• Agent-first — every request carries an identified agent plus a signed mandate. No anonymous writes.
• Intent-based — a small, stable set of verbs rather than merchant-specific CRUD.
• Verifiable — every state-changing response is a compact JWS receipt over the JCS-canonicalized body. Any party can verify it offline.
• Global — multi-currency (fiat and stablecoin), multi-jurisdiction tax, and cross-border fulfillment as first-class concerns.
• Embedded engine — the handler carries the full iCommerce engine in process. No separate database, no control plane, no network hop between protocol and execution.
• Interoperable — one handler exposes ICP natively while speaking ACP, UCP, MCP, and A2A on compatibility paths that route into the same transaction and receipt pipeline.

Intent verbs

Verb	Purpose
intent.search	Discover offers
intent.describe	Describe an offer or merchant
intent.quote	Quote a basket
intent.negotiate	Negotiate terms
intent.revise	Revise a quote
intent.authorize	Authorize payment
intent.buy	Complete a purchase
intent.pay	Pay against an authorization
intent.track	Track fulfillment
intent.confirm_receipt	Confirm delivery
intent.return	Start a return
intent.refund_request	Request a refund
intent.subscribe	Start a subscription
intent.renew	Renew a subscription
intent.pause	Pause a subscription
intent.cancel_subscription	Cancel a subscription
intent.cancel	Cancel an order

Vendor extensions use the intent.ext.<reverse-dns> namespace, e.g. intent.ext.com.stateset.loyalty.redeem.

Architecture

                 ┌──────────────────────────────────────────────────────┐
                 │                    ICP Handler (Rust)                │
   Agents ──┬──▶ │  HTTP  /icp/v1/intents  ──┐                          │
            │    │  gRPC  icp_handler.v1     │                          │
            │    │  SSE   /icp/v1/events    ─┤     ┌──────────────────┐ │
            │    │  MCP   /mcp             ──┼──▶  │   IcpService     │ │
            │    │  A2A   /a2a/v1          ──┘     │  (intent router) │ │
            │    │                                 │   ▸ mandate      │ │
            ├──▶ │  Compat:                        │   ▸ quote        │ │
            │    │  ACP   /checkout_sessions  ───▶ │   ▸ authorize    │ │
            │    │  UCP   /api/checkout-…     ───▶ │   ▸ buy/pay      │ │
            │    │                                 │   ▸ return/track │ │
            │    │                                 └─────────┬────────┘ │
            │    │                                   ┌───────▼────────┐ │
            │    │                                   │ stateset-      │ │
            │    │                                   │  icommerce     │ │
            │    │                                   │ (embedded)     │ │
            │    │                                   │ SQLite / PG    │ │
            │    │                                   └────────────────┘ │
            │    │  Receipts → Ed25519 JWS → /.well-known/icp/jwks.json │
            └────┘                                                       │
                 └──────────────────────────────────────────────────────┘

Receipts

Every state-changing response is a compact JWS receipt signed with Ed25519 over the JCS-canonicalized body. The verification key set is published at:

/.well-known/icp/jwks.json

Because verification needs only the receipt and the JWKS, any party can verify a transaction offline — no call back to the merchant or the handler.

Quickstart

git clone https://github.com/stateset/stateset-icp-handler
cd stateset-icp-handler
cargo build --release

# Local demo: demo API key, relaxed request headers
ICP_ENABLE_DEMO_KEYS=true \
ICP_REQUIRE_VERSION=false \
ICP_REQUIRE_MANDATE=false \
ICP_REQUIRE_REQUEST_ID=false \
ICP_REQUIRE_IDEMPOTENCY_KEY=false \
cargo run --release

# HTTP  → http://0.0.0.0:8082
# gRPC  → 0.0.0.0:50052

The demo flags above disable version negotiation, mandate verification, request ids, and idempotency keys. They exist to make a first local run easy — never enable them on a deployment that accepts real agent traffic. With ICP_REQUIRE_MANDATE=false there is no signed authority behind a write.

Related

• UCP — platform-neutral checkout interop
• ACP — ChatGPT Instant Checkout
• iCommerce — the embedded engine