Skip to main content
The Quickstart replays a bundled fixture. This is the real thing: an autonomous agent paying a deployed seller on Arc testnet, with its own wallet and its own money, traced as it goes.

​
1. The agent pays

It funds an ephemeral wallet, deposits 1 USDC into the Gateway, then buys from four paid endpoints on a timer. Every payment is real; every hook firing is recorded to a run file the agent owns.
Terminal recording of the buyer agent: funding an ephemeral wallet on Arc testnet, depositing 1 USDC into the Gateway, then paying quote, dataset, compute and agent-task endpoints in sequence.

​
2. haia-trace build assembles the receipts

The agent has already exited. This step reads the evidence it left behind — one Receipt per payment — and could just as well run on another machine.
Terminal recording of haia-trace build --template=x402-buyer: one receipt assembled from four events, challenge, payment and settlement all confirmed, verdict FULL.
Four events, three milestones, one verdict. The trailing line counts an event that belonged to no operation — the adapter’s own attestation that it was attached at all, reported rather than dropped.

​
3. The one that did not close

Across the whole run, 35 receipts. Thirty-four are FULL and one is not:
Terminal recording of haia-trace receipt show: a PARTIAL x402-buyer receipt where challenge and payment are confirmed but settlement is not, with the explanation that the payment was submitted but no settlement response was observed.
This one is the point, and it is worth being precise about what it says. A signed authorization left the agent and nothing came back. Note what the receipt does not carry: there is no exceptions block, because no fault was ever observed — the seller verified and settled the payment, then the connection dropped before the answer reached the buyer. From where the agent stands, a payment that never settled and one that settled silently look identical. So the receipt refuses to decide. It names the milestone that stayed open and says exactly what was and was not seen. completeness and missing are machine-readable, which is what lets an agent stop a chain of spending on its own evidence instead of guessing.
Real wallet, real USDC, real settlement on Arc testnet — the amounts are fractions of a cent, but nothing here is simulated. Only the buyer is instrumented: the seller is a separate deployed service, and its own traces are its own. That is the normal case — you own your side of a payment and nothing else.

​
Run it yourself

examples/x402-agent is the same code path with the money taken out — no chain, no facilitator, no wallet, so it runs offline in seconds:
It fakes the payment, never the trace: the @x402/core client, its hooks, the adapter, the events on disk and the assembler are all the shipped ones.

​
The same adapters in full applications

Two complete apps run the shipped packages against real infrastructure, one per adapter.

​
arc-nanopayments — x402, both sides

arc-nanopayments is gasless USDC nanopayments on Arc, with an autonomous buyer agent, a Next.js seller and a dashboard. It traces both sides of the payment, and attaches to Circle’s @circle-fin/x402-batching rather than @x402/core: the same one-line attach against another SDK’s hooks.

The buyer

agent.mts — the agent attaches to its GatewayClient and records as arc-nanopayments-buyer.

The seller

lib/x402.ts — the paywalled routes attach to the gateway middleware and record as arc-nanopayments-seller.
Its dashboard reads the run files straight back off disk and renders a payment timeline — the recorded events, not assembled Receipts. The app never has to ask anyone for its own evidence.

​
arc-escrow — Circle webhooks, plus the app’s own events

arc-escrow is an escrow-backed work agreement on Arc: deposit, deliverable, evaluation, then release or refund — the operation the shipped escrow-arc template describes. It shows the case one adapter cannot cover alone. Circle’s notifications witness the money; nothing outside the app can witness that an agreement exists or that work was judged, so the app records those itself into the same run directory.

The money half

app/api/webhooks/trace/route.ts — @usehaia/trace-circle verifies, deduplicates and records Circle deliveries.

The obligation half

lib/trace/escrow-events.ts — the app’s own escrow.* events, which no external witness can produce.
Both halves write to the same run directory, and haia-trace build --template escrow-arc folds them into one receipt. No custom template — the shipped one already covers both sources.

​
The hosted view

Everything above is local — files on disk, a CLI reading them back. The same events can also be mirrored to a Haia Control Plane project as they are recorded, so a run is readable from outside the machine that produced it. It is a copy, not a replacement: the local file stays the source of truth, and adding the sink changes nothing in the payment path. Receipts live under Operation Receipts. Each one carries the same verdict the CLI prints — stages in template order with the witness that closed each, the required milestones nothing closed, and the events the template declares as faults:
The Operation Receipts view of the Haia Control Plane: a PARTIAL x402-seller receipt with request and verification confirmed, settlement not confirmed, one missing milestone, and two observed faults.
A live instance carries the runs from both applications above, one workspace each:
A shared demo account on a shared instance — treat anything you send it as public. Mirroring a run is one extra sink on the writer you already have.

​
Next steps

Connect x402

The one-line attach, what gets recorded, and what never does.

Connect Circle

Verify, deduplicate and record webhook v2 deliveries.

What a Receipt is

Stages, evidence, missing, exceptions — the model behind the verdict.

CLI reference

Every command, flag, and the .trace/ layout.