← Zero-Knowledge on L1·Agent economyPrototype · TN10

Kaspa Agent Commerce

AI agents are about to transact at scale — and they need money, verified facts, private settlement, and coordination. Kaspa already has all four. This is the missing piece: a pay-per-request settlement layer where the payment itself is a smart object — escrowed, bound to one request, released by a receipt or refunded on timeout — settled sub-second on L1.

Try the live demo →How an agent pays

How an agent pays, in one round-trip

It speaks HTTP 402 — the same shape as x402/AP2 — so existing agent tooling can pay on Kaspa with no changes.

1 · 402

The agent hits a service and gets HTTP 402 Payment Required: price, payee, and an invoice bound to this exact request.

2 · Escrow

The agent opens a k402 escrow — funds locked to that invoice. Provably reserved, refundable to the agent if the service never delivers.

3 · Serve

The agent re-requests with a receipt (a signature over the invoice). The service verifies the escrow + receipt on-chain, then serves the resource.

4 · Claim

The service claims the payment with the receipt — settled on Kaspa in under a second. Or, after the deadline, the agent refunds.

Not x402 on a faster chain — the payment is programmable

Plain x402 on an L2

is a bare transfer: pay first, hope the service delivers, wait seconds-to-minutes for the L2 to confirm. The payment carries no logic.

k402 on Kaspa

the payment is a covenant: escrow + proof-of-delivery + timeout-refund, enforced by consensus, bound to one request, settled sub-second at ~10 blocks/sec. For high-value calls the receipt is swapped for an oracle / ZK proof of delivery.

Live on Kaspa L1

The first pay-per-request settlement — an agent opened an escrow, the service verified + served, then claimed.

Agent opens the escrow

funds locked to the request · 491aeed9…3495 ↗

Service claims the payment

released by the agent's receipt · e5dbcefe…925f ↗

Built on the four primitives already live on Kaspa — kUSD (a stable unit), the proof-carrying oracle (verified facts), the shielded pool (private settlement), and the intendo (coordination). Agent commerce is the layer that ties them together.

doneLive on TN10: the full x402 loop — 402 → escrow → serve → claim — with real agents paying real services, sub-second.

liveA self-driving cast of agents pays the marketplace on a schedule (the feed above is real on-chain settlements).

liveMandates (the AP2 piece): the agent spends under a delegated on-chain budget — a per-call cap enforced by consensus, revocable by the user anytime — drawing down live above.

liveMulti-agent group-buy: agents pool funds to jointly buy a service none pays for alone — all-or-nothing at the price (the intendo pattern), settling to a k402 service. Composes kUSD pricing + shielded privacy on top.

noteTrust model, honestly: receipt-with-request is pay-first (fine for low-value, high-frequency calls; the timeout-refund protects the agent). For high-value / delivery-sensitive calls, the receipt becomes an oracle/ZK proof of delivery.

Testnet-10 only · unaudited prototype · not for real value. The settlement rail for machine-speed commerce: exactly the fee-dense, high-frequency demand a fast L1 is built to carry.

Try the live demo →The coordination market →