Agentic Payments

x402 HTTP Purchase

Machine-to-machine payments via HTTP 402 status code. Agent discovers price, pays in USDC, receives resource — no human in the loop. Coinbase Smart Wallet on Base; Cloudflare Worker compliance middleware at the edge.

Vendors

Coinbase · Cloudflare · CDP AgentKit · Base

Compliance center

HTTP 402 triggers atomic payment at Transport; Cloudflare Worker runs OFAC + AML + capability checks before settlement fires

agentichttp-402usdccoinbasecloudflarebasemachine-to-machineworkers
Filter by shape:
|
A1 · AGENTICAgentic x402 purchase·5 stations(3 compliance, 2 infra)·coinbase · cloudflare
S1INTENTS2IDENTITYS3DISCOVERYS4S5TRANSPORTS6S7S8FINALITY01Smart Wallet02Sanctions03Allowlist04Transfer05Receipt
3+5 shape system
GatePre-condition — blocks if it failsMonitorConcurrent — observes without haltingObligationPost-settlement — reports after the factsolid = codedashed = policy
How to read this diagram
Each station on the rail represents a compliance or infrastructure event in the Agentic x402 purchase path. Hover any station to inspect it. The shape tells you what kind of event it is. The ring tells you how it's enforced.
Gate Monitor Obligation| Ingress Crossing Transform Settlement Venue
This path at a glance
5 stations across 5 of 8 segments. 3 are compliance checkpoints, 2 are infrastructure.
4 code-enforced1 policy-enforced
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKBASE
L5 APPLICATIONCoinbase Smart Wallet platform (CDP SDK / AgentKit) — agent identity + delegation provisioning
L4 ACCOUNTAgent session key ↔ scoped spending envelope (ERC-4337 UserOperation signer)

Step 1 · Agent Wallet (Coinbase Smart Wallet on Base)Policy-Enforced

"The authenticated bank-app login — identity established, spending authority scoped by delegation token before any transaction instruction is composed."

A Coinbase Smart Wallet (ERC-4337) on Base, provisioned via the Coinbase CDP SDK or AgentKit, with session keys scoped to the current agent task. The agent's identity binds to a resolvable DID (did:pkh:eip155:8453 for self-custody agents, did:web for ACK-ID-attested agents); the spending envelope is encoded in the session key itself as a typed ERC-4337 UserOperation signer whose scope is enforced by the account contract.

Builder: `createSmartWallet({ delegation, spendLimit, allowedTargets })` through AgentKit; pair with Cloudflare Worker session-key issuance if you want the delegation signed at the edge rather than by a centralized key service.

Compliance officer: KYA checkpoint KYA-1 (Identity) fires here — the agent's DID must resolve to an identifiable human or organizational principal before any HTTP 402 response is honored. The wallet-provisioning step is the attachment point for the principal entity's customer identification program and transaction-monitoring obligations.

Honesty marker: GENIUS §6 AML/BSA obligations attach to the principal, not the agent itself. The principal's BSA program is inherited by the agent for the duration of the delegation — agents are not standalone BSA-regulated entities, which means the compliance posture of any agent is exactly the compliance posture of the principal that delegated to it. Wallet provisioning is therefore the structural attachment point for the institution's CIP and transaction-monitoring obligations.
Counterparty
Self (agent holds scoped keys via Coinbase Smart Wallet)
Latency
Instant · wallet provision is off-chain
Finality
N/A — no payment yet
Vendors
Coinbase Smart Wallet (ERC-4337) · Coinbase CDP SDK / AgentKit · Cloudflare Workers (session-key issuance pattern) · did:pkh / did:web (DID resolution)
Chain
Base (Coinbase (sole sequencer operator at launch; decentralization on roadmap))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKBASE
L3 EXECUTIONCloudflare Worker compliance middleware — Chainalysis OFAC oracle (KV-cached) + AML pattern analyzer (D1-backed)
◆ Enforcement Line — code-enforced at this layer

Step 2 · Compliance Middleware — Sanctions + AMLCode-EnforcedINGESTDETECTALERT

"The SWIFT gpi sanctions-screening leg — no value moves until the list check returns pass — plus the card-network fraud engine's velocity and structuring heuristics running in parallel on the same authorization."

A Cloudflare Worker intercepts the HTTP 402 response before the payment fires and runs the compliance pipeline at the edge. The OFAC gate fires against the Chainalysis sanctions oracle at 0x40C5...8fb on Base — results cached in Workers KV with a 1-hour TTL to keep the hot path under 100ms. Simultaneously, a transaction-pattern analyzer queries the agent's transaction history from D1 and checks for structuring, round-tripping, and smurfing patterns against GENIUS §104(d) monitoring heuristics.

Builder: `await middleware.screen(agentAddress, merchantAddress, amount)` returns a `ComplianceResult` with pass/fail flags for sanctions (hard gate) and pattern score (soft monitor); the pipeline halts on first hard-gate failure. The Worker reverts with HTTP 451 Unavailable For Legal Reasons if the OFAC gate fails, and logs a monitor event (non-halting) if AML patterns trip a soft threshold. The reference middleware implementation is live at `/integrations/x402` and deployable at $0–5/mo on Cloudflare's free tier — KV + D1 + R2 + Secrets, no servers.

Compliance officer: this step satisfies GENIUS §6 (AML/BSA) and §8 (sanctioned-counterparty screening for cross-jurisdictional flows). Edge-computed compliance with cached oracle reads keeps the agentic-payment latency budget intact while preserving the gate's enforcement properties.

Honesty marker: The Chainalysis oracle returns a boolean on-chain, not attestation detail — dispute resolution requires off-chain escalation through Chainalysis's enterprise-channel processes. AML pattern detection is heuristic, not definitive; monitor events become SAR candidates only after human review by the principal's compliance program. The Worker is the enforcement point but not the adjudication point.
Counterparty
Chainalysis OFAC oracle + Cloudflare Worker middleware
Latency
<1s · atomic with the settlement call (KV-cached)
Finality
Pre-condition gate — blocks the x402 response completion
Vendors
Cloudflare Workers (edge compliance middleware) · Chainalysis OFAC Oracle (Base) · Cloudflare KV (1-hour TTL cache) · Cloudflare D1 (transaction history store)
Chain
Base (Coinbase (sole sequencer operator at launch; decentralization on roadmap))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKBASE
L4 ACCOUNTAgent session key ↔ on-chain delegation state (ACK-ID-attested capability envelope)
L3 EXECUTIONCapability policy engine + ACK-ID delegation verifier (Cloudflare Worker + on-chain gate)
◆ Enforcement Line — code-enforced at this layer

Step 3 · Authorization (ACK-ID Delegation + Capability Envelope)Code-EnforcedINGESTDETECTALERT

"The corporate authorization matrix check — the purchasing agent proves it holds the delegated authority, within category and amount and window, to commit the principal's funds to this specific counterparty."

Before the USDC transfer fires, the Cloudflare Worker verifies that the agent is operating within its capability envelope. The ACK-ID delegation chain is resolved — the agent's session key must derive from a valid principal credential, and the target merchant must be within the delegation's permitted-counterparty set. The capability envelope (part of KYA-2 Authorization) enforces per-transaction limits, daily caps, permitted merchant categories (encoded as MCCs or ACK Rulebook category hashes), and temporal bounds.

Builder: `capabilityCheck({ agent, target, amount, timestamp })` returns `{ allowed: bool, reason?: string }` — the Worker reverts with 403 Forbidden if the agent is out of scope. The envelope is also evaluable off-chain in the Worker itself for latency-sensitive paths; the on-chain check remains the authoritative gate.

Compliance officer: this is the code-enforced KYA-2 (Authorization) checkpoint — delegation verification and capability-envelope evaluation are a single authorization decision. C5 Licensing attaches where the agent operates on behalf of a licensed entity (MTL, NYDFS BitLicense, OCC National Trust charter); the envelope must encode the licensee's permitted product scope and geographic restrictions.

Honesty marker: GENIUS §6 attribution to the principal depends on this step passing. A payment that bypasses the capability envelope cannot be cleanly attributed to the principal's BSA program — the principal's compliance posture only extends to in-envelope agent activity. Out-of-envelope transactions create attribution ambiguity that compliance programs need to resolve case-by-case, which is an unsolved structural surface in agentic commerce as of early 2026.
Counterparty
ACK-ID delegation verifier + capability policy engine
Latency
<500ms · on-chain + Worker evaluation
Finality
Pre-condition gate — blocks if scope exceeded or delegation stale
Vendors
Catena Labs ACK-ID (delegation verifier) · ACK Rulebook (capability policy schema) · Cloudflare Workers (off-chain envelope evaluation)
Chain
Base (Coinbase (sole sequencer operator at launch; decentralization on roadmap))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKBASE
L3 EXECUTIONUSDC ERC-20 contract — EIP-3009 transferWithAuthorization atomic settlement
L2 CONSENSUSBase consensus — single-block confirmation for amounts under institutional thresholds
L1 NETWORKBase network — L2 settlement anchored to Ethereum L1
◆ Enforcement Line — code-enforced at this layer

Step 4 · Atomic x402 Settlement on BaseCode-Enforced

"The beneficiary's credit-to-account event — authorization obtained, list checks passed, funds credit irrevocably to the merchant inside the settlement window."

The x402 payment fires atomically on Base. The agent signs an EIP-3009 `transferWithAuthorization` typed-data message committing to the amount, merchant address, and a single-use nonce; the merchant's contract relays the signed message to USDC's ERC-20 contract, which transfers the funds in a single settlement call. The full stack below the enforcement line (L1 Network, L2 Consensus, L3 Execution) processes the transfer in one Base block (~2s).

Builder: the Worker returns the signed authorization in the `X-Payment` HTTP header; the merchant's resource server calls `ERC20.transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, v, r, s)` and serves the paid resource once the transfer mines. Base settlement finality is strong at one block for amounts under institutional thresholds; Coinbase recommends two-block confirmation for x402 flows above $10K.

Compliance officer: GENIUS §4 reserve-backing obligations apply to the USDC in transit — Circle must maintain 1:1 reserves in USD or short-term Treasuries for every token transferred. Recordkeeping (C11) attaches to the block's transaction hash, which becomes the anchoring reference for the downstream receipt.

Honesty marker: No account relationship is created between agent and merchant. The HTTP 402 flow is intentionally headless, which simplifies the merchant's compliance footprint (no customer data to protect under C14) but also means no relationship-based continuity for repeat Travel Rule screening. Each x402 transaction is a discrete event from the merchant's perspective; the agent's identity continuity sits at the principal level via the ACK-ID delegation chain, not at the merchant-relationship level.
Counterparty
Merchant resource contract (x402 endpoint on Base)
Latency
~2s · single Base block
Finality
Final on Base block confirmation (two-block recommended above $10K)
Vendors
USDC (Circle) · EIP-3009 transferWithAuthorization · Base (Coinbase L2) · x402 protocol (HTTP 402 response convention)
Chain
Base (Coinbase (sole sequencer operator at launch; decentralization on roadmap))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKBASE
L5 APPLICATIONCloudflare R2 receipt store + public `GET /receipts/:id` verifier endpoint
L4 ACCOUNTW3C Verifiable Credential receipt (X402Receipt) — agent DID + merchant DID + tx hash binding
◆ Enforcement Line — code-enforced at this layer

Step 5 · Verifiable Receipt + Audit Trail (Cloudflare R2)Code-EnforcedINGESTDETECTALERT

"The merchant's daily settlement file plus the bank's Reg E recordkeeping bundle — one artifact for the counterparty, one for the examiner, cryptographically linked to the underlying transfer."

The Cloudflare Worker issues a W3C Verifiable Credential receipt (type `X402Receipt` or `ACKReceipt`) binding the agent's DID, the merchant's DID, the amount, the Base transaction hash, and the compliance screening results from Step 2. The VC is signed with the Worker's receipt-signing key (held as a Cloudflare Secret binding), written to Cloudflare R2 under a key derived from the transaction hash, and the R2 object key is indexed in Workers KV as the audit-log entry.

Builder: a public `GET /receipts/:id` endpoint returns the VC for independent verification — any third party can cryptographically verify the receipt's issuer, non-revocation, and claims without access to Cloudflare infrastructure. Receipts are indexed by tx-hash and queryable via the public verifier endpoint; see `src/workers/x402-middleware.ts` for the canonical schema and the KV/D1/R2 binding declarations.

Compliance officer: satisfies C7 (Travel Rule originator/beneficiary data if the transfer crossed $3,000), C11 (recordkeeping under GENIUS §6 and §4(c) books-and-records), and C12 (independent audit trail for the monthly reserve attestation under §4(b)). The verifiable receipt is the artifact an examiner subpoenas — cryptographically linked to the on-chain transfer, independently verifiable, stored in durable object storage.

Honesty marker: R2 is durable object storage, not a regulated recordkeeping service. Jurisdictions with WORM-storage requirements (FINRA Rule 4511, SEC 17a-4(f)) require additional compliance-grade storage layered on top of the R2 receipts. Cloudflare R2 plus the public verifier endpoint provides cryptographic auditability, but does not by itself satisfy regulator requirements for write-once-read-many evidentiary preservation.
Counterparty
Cloudflare R2 receipt store + public verifier endpoint
Latency
<1s · receipt write is non-blocking after settlement
Finality
Final · receipt issued and indexed for audit
Vendors
Cloudflare R2 (durable object storage) · Cloudflare KV (audit log index) · W3C Verifiable Credentials (X402Receipt schema) · Cloudflare Workers (receipt signing — Secret binding)
Chain
Base (Coinbase (sole sequencer operator at launch; decentralization on roadmap))

Resolved 5 steps across 1 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.

Coverage notes: 5 disclosed gap(s).

TOOL 01 · 8-STAGE STP SEQUENCE

x402 Payment Journey

Interactive 8-stage STP visualization showing the x402 HTTP payment lifecycle from wallet connection through atomic settlement on Base — the signature view of the Coinbase × Cloudflare pipeline.

X402 PAYMENT JOURNEYIntentIdentityDiscoveryNegotiationTransportAuthorizationFacilitationFinality
TOOL 02 · 5 WALLETS × 5 LAYERS

Wallet Compliance Depth (Coinbase Smart Wallet focus)

Compare smart wallet compliance depth across Coinbase Smart Wallet, MetaMask, Rabby, Safe, and Ledger — the Step 1 artifact showing which wallets can hold an ACK-ID-attested session key and carry a delegated spending envelope to the edge.

L5ApplicationL4MiddlewareL3ExecutionL2ConsensusL1Network▲ STATE TRANSITION▲ Above the STATE TRANSITION line: policy-enforced (off-chain). ▼ At or below: code-enforced (EVM bytecode).Self-Custody EOAWallet UIL5Coinbase Smart WalletYOUR WALLETPasskey UIOFAC / KYTERC-4337L3MPC WalletKYC GateMPC ThresholdL4Hosted / CustodialIdentityGas SponsorL4Agent WalletAgentKitSpend PolicySession KeysL3Code-enforcedPolicy-enforced
TOOL 03 · ON-CHAIN OFAC SDN QUERY

Chainalysis Sanctions Oracle (Cloudflare Worker call)

Query the Chainalysis OFAC sanctions oracle at 0x40C5...8fb — the code-enforced gate the Cloudflare Worker runs at Step 2, cached in Workers KV with 1h TTL to keep the hot path under 100ms.

Chainalysis
TOOL 04 · 5-CHECK POLICY EVALUATOR

ACK-ID Capability Envelope

Evaluate the Step 3 capability envelope: per-transaction limits, daily caps, permitted merchant categories, temporal bounds, and delegation depth — the code-enforced KYA-3 gate that blocks out-of-scope agent payments.

$0 — $100,000
$0 — $500,000
TRANSACTION REJECTED
Per-Transaction Limit
amount <= $5,000
$3,500
Daily Limit
(used + amount) <= $25,000
$12,000 (8,500 used)
Asset Permitted
asset in [USDC, USDT]
USDC
Action Permitted
action in [transfer]
transfer
Temporal Bound
2026-03-01 to 2026-06-01
2026-06-02
Vendors: Coinbase AgentKit, Catena Labs ACK Rulebook
TOOL 05 · 3 RAILS × 5 LAYERS

Settlement Stack (Base L2 vs Ethereum L1)

Step 4 settlement-side compliance depth across off-chain ledger, Base L2, and Ethereum L1 — showing where value crosses the enforcement line and why Base is the canonical x402 settlement target.

L5ApplicationL4MiddlewareL3ExecutionL2ConsensusL1Network▲ STATE TRANSITION▲ Above: policy-enforced (off-chain). ▼ At or below: code-enforced (EVM bytecode, unbypassable).Off-chain LedgerAPI ReceiptPSP LedgerL4Base Settlement RailSETTLED VIAHTTP 200 + PDFCoinbase CDPUSDC EIP-3009Base OP-StackEthereum DAL1Ethereum L1 DirectHTTP 200ERC-20 transferEOA txEthereum PoSL2Code-enforcedPolicy-enforced
TOOL 06 · 4-STEP VERIFICATION PIPELINE

VC Receipt Verifier (R2-backed)

Verify the Step 5 Verifiable Credential receipt issued by the Cloudflare Worker — signature check, issuer validation, revocation check, and claims evaluation. The audit artifact an examiner can subpoena and verify independently.

Sample ACK Receipt (VC format)

{
"@context": [
"https://www.w3.org/2018/credentials/v1"
]
,
"type": [
"VerifiableCredential",
"ACKReceipt"
]
,
"issuer": "did:web:receipts.acme-psp.com",
"issuanceDate": "2026-04-01T14:32:18Z",
"credentialSubject": {
"payer": "did:web:agent.acme-corp.com",
"payee": "did:web:vendor.eu-payments.fr",
"amount": "3500.00",
"currency": "USDC",
"settlementNetwork": "Base",
"requestToken": "req_7f3a8b2c"
}
,
"proof": {
"type": "Ed25519Signature2020",
"verificationMethod": "did:web:receipts.acme-psp.com#key-1",
"signatureValue": "eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDp3ZWI6cmVjZWlwdHMuYWNtZS1wc3AuY29tI2tleS0xIn0"
}

};
1

Signature Validation

Gate
2

Issuer Trust Check

Gate
3

Revocation Check

Monitor
4

Claim Verification

Gate

Other Agentic Payments Paths

SETTLEMENT CHAINS