Escrow is what you reach for when the payment and the thing it pays for cannot happen in the same instant, and neither side is willing to go first. A neutral holder takes the buyer’s money, keeps it out of both parties’ reach, and moves it only when a stated condition is satisfied. Agent commerce does not change those mechanics — but it changes who presses the buttons. An autonomous buyer cannot read a seller’s premises, phone a reference, or feel uneasy about a deal; it can evaluate only what is machine-checkable. So the interesting part of agent escrow is not the holding, which is easy. It is the condition, the party who attests it was met, and what happens when that party is wrong, absent, or bought.
When escrow is the right instrument — and when it is overkill
Escrow is expensive: a fee, a delay, and the buyer’s use of their money for the duration. It earns that cost only when three things are true at once: the amount is large enough that a loss hurts, delivery is separated in time from payment, and the counterparty is one the agent cannot assess — no trading history, no reputational stake, no rail-level recourse.
Drop any one and a cheaper instrument wins. A small repeated purchase from a known merchant needs only an ordinary card authorization; the scheme’s own chargeback rights already protect the buyer, and an escrow fee duplicates them. Instant digital delivery needs no hold. And a merely uncertain amount is an authorization hold problem, not an escrow problem: a hold reserves headroom on the buyer’s credit line but never moves money to a third party. Escrow is the heavy tool for when money must leave the buyer without yet arriving at the seller.
The state machine — funded, held, released, refunded, disputed
Model an escrow as an explicit state machine and most design errors surface immediately. The agreement is created with terms both parties sign, becomes funded when the money lands with the holder, sits held while the seller performs, and ends released, refunded, or split. Disputed is a detour, not an ending.
| State | Exits to |
|---|---|
| created | funded, or expired if never funded |
| funded / held | released, refunded, disputed |
| disputed | released, refunded, or split by decision |
| released / refunded | terminal |
Two invariants matter more than the diagram. Every non-terminal state needs a timed exit — a state with no clock can hold money forever, and that destroys trust faster than losing a dispute. And funding must be confirmed, not merely initiated: reporting ‘funded’ on a transfer that has not cleared invites the seller to deliver against money that can still be pulled back.
Writing a release condition a machine can actually check
‘Release when the goods are delivered’ is a sentence for humans. An agent needs a predicate it can evaluate without judgement. The practical hierarchy, best first: a cryptographic proof (the artifact hashes to the value named in the agreement); a counter-signature (the buyer signs an acceptance referencing the same cart the escrow was funded against); a third-party record (a carrier’s delivered scan); and last, a signed human judgement.
AP2 helps here because it already produces signed, verifiable statements of intent. The cart mandate that authorized the purchase names what was bought, from whom, and on what terms, and it is non-repudiable — a natural anchor for the release predicate, so buyer, seller, and holder argue about the same signed object rather than a prose description. Conditions that cannot be reduced to something checkable — ‘the design should look professional’ — are not escrow conditions. They are arbitration schedules in a condition’s clothes.
The oracle problem — who attests that delivery happened
Every condition not self-evident to the escrow needs someone to assert it. That someone is the oracle, and it is where the escrow’s trust actually lives. Note the substitution honestly: escrow does not remove trust, it relocates it from a counterparty you cannot assess to an attester you hope you can.
The candidates fail differently. Seller attestation is worthless alone — the party being paid should not certify its own performance. Buyer attestation is the cheap default, but it hands the buyer a free option: withhold the signature and the seller’s money is stranded. Independent third parties — a logistics API, an on-chain event — are stronger but add a dependency with its own outages, pricing power, and attack surface. Quorum designs, where two of three attesters must agree, raise the cost of corrupting the answer, at the price of latency. The rule is blunt: an escrow is never more trustworthy than its oracle, so choose the oracle before the rail.
When the oracle is wrong, captured, or simply offline
Oracles fail in two ways and the mitigations are not interchangeable. A safety failure is a wrong answer: the oracle says delivered when nothing arrived, and money moves to the wrong party. A liveness failure is no answer at all — the API is down, the attester is out of business, the key is lost. The escrow freezes with the funds inside, which hurts the seller more than the buyer, since it has already paid to perform.
Safety is addressed by redundancy and reviewability: quorums drawn from independent data sources, and a challenge window between the attestation and the actual release, since once funds move the escrow has no lever left. Liveness needs clocks and fallbacks: a secondary oracle, escalation to human arbitration after a defined silence, and ultimately a timeout with a stated default. Never fix a liveness failure by adding a party who can unilaterally sweep the funds — that recreates the counterparty risk escrow was supposed to remove.
Timeouts and the question of who wins the tie
Every escrow needs two clocks: a performance deadline by which the seller must deliver, and an inspection window after delivery in which the buyer may object. Silence at the end of each is not an error condition — it is how most escrows end, which makes the default outcome the most consequential parameter in the design.
The conventional settings are asymmetric, deliberately. If the performance deadline passes with no delivery evidence, the default is refund: nothing happened, so unwind. If the inspection window passes with delivery evidence and no objection, the default is release: buyer inaction must not be a free way to hold the seller’s money hostage. Both windows are gameable at the edges — deliver at the last minute and the buyer’s review is compressed; let an agent sit offline and it forfeits standing — so make them long enough to survive an outage and short enough that capital is not parked for a quarter. Never leave the default implicit.
Partial release and milestones
All-or-nothing escrow puts the whole transaction on a single yes-or-no, which is fine for a dataset and terrible for a six-week engagement. Milestones decompose the bet: fund once, release in tranches as separately checkable conditions are met, so each side is exposed to one stage at a time.
Three rules keep milestones from becoming their own problem. Each needs its own checkable condition; a schedule of dates with no acceptance test is just an instalment plan. Released tranches should ratchet — final, with a later dispute contesting the remaining balance rather than clawing back settled work — because reversibility deep into a project restores the uncertainty the structure removed. And tranches must be priced to the work performed, not front-loaded; a first tranche worth most of the contract turns the remaining stages into unsecured credit. This is distinct from splitting one payment across several recipients, covered elsewhere in this series.
The cost of capital while the money sits still
Held funds are not free. Between funding and release the buyer has paid and the seller has not been paid, so both sides carry the transaction at once: the buyer loses the use of the cash, the seller finances performance out of working capital while its receivable sits elsewhere. Multiply a modest carry cost by a long hold and escrow can quietly exceed the fraud loss it was bought to prevent.
That arithmetic should drive design: shorter holds beat elaborate conditions, and a counterparty with a track record should graduate out of escrow into a plain authorization. Two governance questions follow. Who earns the yield on the balance? State it, because an unstated answer means the holder keeps it. And whose money is it in insolvency? Holding third-party funds is regulated in most jurisdictions, and a segregated client account is the difference between a delayed release and an unsecured claim against a failed provider.
On-chain versus off-chain escrow
Where the funds sit determines what can go wrong. A smart-contract escrow holds value on a ledger under code no party can override; a custodial escrow holds fiat with a regulated institution acting as operator.
| On-chain | Custodial | |
|---|---|---|
| Trust anchor | Contract code | Institution and licence |
| Oracle | Bridged in explicitly | Often an internal process |
| Recovery | Only what the code allows | Human override, and its abuse |
| Assets | Tokens, stablecoins | Bank money, card rails |
The honest summary: on-chain escrow makes the holding trustless and leaves the condition exactly as trusted as before — a contract still learns a parcel arrived from an oracle somebody chose — while converting bugs into permanent losses. Custodial escrow keeps a human in the loop, a recovery path and a corruption path at once, and sits inside the compliance regime (KYC, sanctions screening, money-transmission obligations) that on-chain designs skip and later retrofit.
Abuse runs in both directions
Escrow does not remove bad behaviour; it reshapes it into a fixed set of moves. On the buyer side: release-withholding, where an attesting buyer never signs acceptance and then offers to release for a discount — extortion dressed as negotiation, and the reason silence must default to release. On the seller side: minimum-viable delivery, shipping the least that satisfies the literal predicate, usually a symptom of a condition written too thinly rather than of dishonesty.
Then the cases that hit the holder rather than a party. Colluding counterparties can run funds through an escrow purely to manufacture a clean settlement record, which is why holders carry KYC, sanctions, and suspicious-activity obligations like any money handler; a fund-then-immediately-unwind pattern is a refund-abuse and card-testing signal worth monitoring. When a genuine disagreement survives all of this, it leaves escrow for the arbitration and chargeback machinery covered in its own articles. Escrow’s job at that point is only to freeze the funds and hand over a clean, signed record of what was agreed.