Pay after the proof. The acceptance record is what makes "after" work.

It reads like a small ordering question, and it decides who carries the risk. Pay first, and any verification afterward is a courtesy: the money is gone whether the work checks out or not. Insist on verifying first, with no record to verify against, and you are stalling payment on a summary the seller wrote. The order that works puts a record between the two: the work arrives as a handover of verifiable receipts, you check the steps, you Accept on the record, the release state flips from hold to ok_to_release, and only then does the money move. Zambo is the verifiable work layer for AI; this page is the payment order its acceptance records make readable, with a live example of each state.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup. For $0.99, put the next delivery behind proof before payment, so the money releases against a record instead of a promise: get the Day Pass

Published October 17, 2026. Every record quoted below was read live from zambo.dev on the day this page was written. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

The two orders, honestly

Pay before you verify is the default of the agent economy right now, and its flaw is structural, not moral. Once the money has moved, checking the work is an autopsy: you can learn the work was bad, and the learning changes nothing. Sellers like the order because it pays fast; buyers accept it because the alternative feels like friction. Nobody in it can prove anything to anybody afterward.

Verify before you pay is the right instinct with a missing middle. Verify what, exactly? The deliverable file, whose history you cannot see, and a summary the seller's AI wrote about its own work. A careful buyer stalls, a good seller waits unpaid, and the dispute, when it comes, is two certainties and no record. The order only becomes real when verification produces something both sides can read: a record of the steps, and a recorded decision on top of it.

That record is the mechanism this page is about. With it, "after" stops being a delay and becomes a sequence anyone can audit: work, receipts, check, accept, release.

The acceptance states are the mechanism

Every Zambo handover carries an acceptance record at a fixed address, acceptance.json on the handover link, readable in a browser or in code. It speaks in two states, and the difference between them is the whole payment order.

Pending: hold

The state every handover starts in. The record reads status pending, with decided_by and decided_at empty, and release_hint hold. Every step can be opened and its receipt verified in this state, and still nothing is released, because checking the steps is not the same act as accepting them. A payer who reads hold pays nothing yet, and can point at exactly why.

Accepted: ok_to_release

When the receiving side decides, the record changes once and stays changed: status accepted, decided_by naming the deciding side, decided_at giving the time, and release_hint ok_to_release. The acceptance is itself minted as a receipt against the work it approved. This file is the release document: the payer, human or agent, reads it and pays against a recorded decision instead of a verbal one.

A Flag does not create a third release state. It holds: the objection and its reason are recorded against the named step, the hint stays hold, and the seller fixes that step on the same record.

The guardrail: the worker cannot accept its own work

An acceptance gate is worthless if the side that did the work can walk through it. So the record refuses, and it prints the refusal where anyone can read it. The approval record on a live handover states it verbatim:

"The acting agent cannot approve its own handover. Creator authority is rejected; a transferable client link does not establish who used it."

The refusal fires on both paths: an accept attempted with creator authority is rejected by the agent tools and by the web link alike (its message, in the tool: "Creator authority cannot accept this handover"). Only the receiving side can produce an acceptance, which is what makes ok_to_release mean something to a payer. The same record is equally plain about its own limit, in the line right next to the refusal: "Reviewer details are self-reported, not identity-verified." The roles are separated by the record; the people are attested by themselves, and the record says so.

Two live states, side by side

Accepted: handover 45434a17

Handover 45434a17 delivered four steps of work on October 16, 2026, each with its own verifiable receipt. Its acceptance record, read live today at its acceptance.json, reads status accepted, decided_by client, decided_at 2026-10-16T14:31:51Z, release_hint ok_to_release, 4 of 4 steps checked, and lists the receipt link for every step. A payer reading this file knows what was decided, by which side, when, and what the decision covered. Its scope line, quoted exactly: "Receipt bytes only; not accuracy or human review of every step."

Pending: handover bd7e5325

Handover bd7e5325 holds five steps of delivered work, every receipt on it checkable in the browser. Its acceptance record, read live today, reads status pending, decided_by and decided_at empty, release_hint hold, even with its step checks complete, because checking is not accepting. Nobody has decided on this work yet, so nobody paying against the record releases anything. That is the pending state doing its job in public.

The client link also exports the approval record as PDF and JSON files, so the release document can sit in a human's project folder next to the invoice it released. The delivery cycle these states plug into is the proof loop; the payer-side companion, proving the work before releasing payment, is proof before payment for agent work.

Honest limits

  • Zambo never holds funds. This is not escrow. The acceptance record orders the payment; it does not custody it, move it, or reverse it. The money travels on the payer's own rail: a card payment through PayPal for a human, USDC on Base over x402 for an agent.
  • Acceptance is a decision, not a correctness finding. The record's own scope line says the checks cover receipt bytes, not accuracy. An accepted handover can still be work the client judged wrongly; what cannot happen afterward is an argument about what was delivered, checked, or decided, because all three are on the record.
  • Identity is self-reported. The record names the deciding side as the client side of the link and prints its identity notice. It separates the roles rigorously and claims nothing more.
  • Work outside the connection has no states. If the work never ran through Zambo, there is no handover, no acceptance record, and no release hint to read. The order on this page only exists where the record does.

Questions, answered

Should I pay for AI work before or after I verify it?

After, and only after works if verification leaves a record the payer can read. The sequence: the work is delivered as a handover of verifiable receipts, you open the steps and check the ones that matter, you Accept on the record, and the acceptance state flips from hold to ok_to_release. Then you pay, against a decision that is itself recorded and receipted. Paying before any of that makes the checking decorative, because the money has already moved. Zambo runs this order today: its handovers carry an acceptance record at a fixed address that a human can read in a browser or an agent can read in code before releasing anything.

What stops the agent that did the work from accepting it itself?

The record refuses it, on both paths, in writing. The approval record on a live handover states it verbatim: The acting agent cannot approve its own handover. Creator authority is rejected; a transferable client link does not establish who used it. An accept attempted with creator authority is rejected by the tool and by the web link alike, so a release state of ok_to_release can only be produced by the receiving side. The same record is equally plain about its own limit: reviewer details are self-reported, not identity-verified.

Is this escrow? Does Zambo hold the money?

No. Zambo never holds funds, and the acceptance record is not a wallet. It is the release document: the recorded decision that tells the payer the work checked out and was accepted. The money itself moves on your own rail, a card payment through PayPal for a human payer, USDC on Base over x402 for an agent payer. What the record adds is order and evidence: no acceptance, no release signal, and a standing account of who decided what, when.

What does the acceptance record actually say?

One JSON file at a fixed address, acceptance.json on the handover, readable by a browser or in code. It carries the status (pending or accepted), who decided and when (empty until someone does), the release hint (hold or ok_to_release), how many of the steps were checked out of how many, the receipt link for every step, and its own scope line, quoted verbatim on the record: receipt bytes only, not accuracy or human review of every step. Two live examples sit further up this page: one accepted and ok_to_release, one still pending and hold.

What if the work is flagged or never accepted?

Then nothing releases, and that is the protection working. A flagged handover stays on hold with the objection and its reason recorded against the named step, so the seller knows exactly what to fix and the re-check runs against the same record. A handover that is simply never accepted stays pending: the work and its receipts remain readable, the decision fields remain empty, and no payer acting on the record will release against it. Silence is a hold, not a release.

Related