One trace.
Three rails.
Every agent.

Identity  →  Mandate  →  Money

Identity, authorization and execution are architectural concerns. Their implementation and enforcement differ by route.

Agents earn reputation.
Counterparties read it before accepting payment.

Every Agent has a public 0–1000 score that decays without activity and grows with clean settled volume. Counterparties — MCP servers, x402 endpoints, marketplace vendors — query the score before accepting a 402, just like a card network checks a BIN.

The score is published as an ERC-1155 metadata field on the Agent's identity NFT and exposed as an MCP tool: agentwallet.score(agent_id) → { score, tier, last_updated, anchor_tx }. Counterparties can require a minimum score for an Agent to call their service.

Fiat · Card · Crypto — same protocol, different rail.

The differences your engineers actually care about. Same Mandate. Same Policy. Same trace. Different settlement physics. Pick the right rail per call — or let the policy engine route automatically.

The mandate chain

Intent → Cart → Payment

The Agent Payments Protocol uses ES256-signed JWS tokens to make agent intent cryptographically provable. A complete payment is a chain of three signed mandates: Intent → Cart → Payment. Every signature is verified against the agent's published JWK and audited.

{
  "iss": "did:agentwallet:ag_01J…",   // agent identity
  "sub": "[email protected]",
  "aud": "https://vendor.example/ap2/v1",
  "iat": 1746345600,
  "exp": 1746349200,                  // 1 hour
  "jti": "01J9…uuidv7",
  "mandate_type": "payment",
  "intent_id": "01J9intent…",
  "cart_id":   "01J9cart…",
  "rail":      "x402_usdc_base",
  "amount":    { "value": "125.00", "currency": "USD" },
  "recipient": { "address": "0xabc…" }
}
// Header
{ "alg": "ES256", "kid": "ag_01J9…#k1", "typ": "JWS" }

Distinct payment paths with route-specific authorization.

Outbound payments leave through one of three protocol stacks. The choice is decided by the merchant's capability advertisement (or by the rail the agent's policy permits).

x402 over EIP-3009

The merchant returns HTTP 402 Payment Required with a payment offer. The agent signs an EIP-3009 transferWithAuthorization (USDC on Base) for the offered amount and replays the request with the signed authorization in the X-PAYMENT header.

// 1. Agent's first request
GET /api/dataset/v1 HTTP/1.1
Host: data.example
Authorization: Bearer pak_…

// 2. Merchant returns 402 with offer
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
  "x402": {
    "amount": "0.10", "currency": "USDC",
    "network": "base",
    "recipient": "0xabc…",
    "validBefore": 1746349200
  }
}

// 3. Agent signs EIP-3009 (CDP-managed key) and replays
GET /api/dataset/v1 HTTP/1.1
Host: data.example
X-PAYMENT: eyJ0eXAiOiJ4NDAyIiwiYWxnIjoi…   // signed auth

Shared Payment Tokens (SPT)

For card-rail payments to merchants that accept network-issued single-use tokens. The agent requests an SPT, scoped to a single use and to a specific merchant + amount. The token expires; replay is structurally impossible.

const spt = await issuer.paymentTokens.create({
  type: 'card',
  card: { vault_alias: card.vaultAlias },
  single_use: true,
  restrictions: {
    amount: cartTotalCents,
    merchant: merchantId,
    expires_at: Math.floor(Date.now() / 1000) + 300
  }
});

// Persist for audit
await db.insert(acpSptIssuances).values({
  agentIdentityId, tokenId: spt.id,
  cartMandateId, amountCents: cartTotalCents
});