Settlement · July 27, 2026 · 7 min read
The mechanism is ancient: a neutral third party holds funds until conditions are met, then releases them to the seller or returns them to the buyer. Roman law called it depositum. English common law called it escrow. In 2026, the logic is identical. What changes is the third party.
On-chain escrow replaces the lawyer, the title company, or the Alibaba Alipay hold with a smart contract. The contract receives funds, verifies that conditions were met — typically a signal from a trusted oracle or a direct API call — and either releases to the seller or refunds to the buyer. No disputes, no phone calls, no wire delays. The settlement is final when the block confirms.
This is straightforward in a whitepaper. It is considerably less straightforward when real counterparties are sending real funds through it at random hours, and the contract needs to handle partial delivery, service failures, timeout expiry, and edge cases that no test suite anticipated.
Our first escrow contract deployed to Base in early 2026. The architecture was minimal by design: a single contract that accepted deposits from a buyer wallet, held the funds in contract storage, and released them to the provider upon receiving a settlement signal. If the service did not complete within a configurable timeout, the contract returned the funds to the buyer.
v1 worked. It processed real transactions and settled them correctly. It also revealed three problems that were not obvious until the contract was handling production traffic.
1. No partial settlement. The v1 contract operated in binary mode: either the job completed and the full amount released, or the timeout expired and the full amount refunded. In practice, services sometimes delivered 80% of the requested work before a failure — a transcription that processed 45 of 60 seconds, a data fetch that returned 4 of 5 requested fields. The binary model forced the buyer to lose the entire payment on failure, even though they received most of the value. Conversely, the provider received nothing for work that was mostly done.
2. Monolithic contract. Everything — deposits, holds, releases, refunds, timeouts — lived in one contract address. When we needed to change the refund logic or add a new settlement condition, we had to redeploy the entire contract and migrate any in-flight jobs. A contract with open escrows cannot simply be replaced.
3. No output integrity proof. v1 relied on the server's own assertion that the job was complete. The contract checked whether the server called settle(), not whether the output was correct or complete. For a data endpoint returning a JSON payload, this is acceptable — the buyer can verify the payload. For metered services like voice transcription, where the buyer cannot observe the processing pipeline, a trust gap exists between the server's claim and the buyer's receipt.
The v2 redesign addressed all three problems through two contracts instead of one.
The escrow contract handles fund custody. It accepts deposits, tracks job state, and manages release and refund logic. The critical change: the settle function now accepts a refundRatio parameter. When the service delivers partial output, the server sends a settlement signal with the percentage of the job that was completed. The contract releases the corresponding portion to the provider and refunds the remainder to the buyer. A 60% completion means 60% to the provider, 40% back to the buyer.
The hook contract is new. It acts as a policy layer that the escrow contract calls before executing any state change. The hook can enforce rules — minimum deposit amounts, rate limits per buyer, maximum job duration, prohibited token addresses — without modifying the escrow contract itself. Policy changes deploy to the hook; custody logic stays in the escrow. This separation means we can update business rules without touching the contract that holds funds.
Instead of introducing an oracle to verify job completion — which adds cost, latency, and a new trust dependency — v2 ties the settlement proof to the output itself. After each session, the server hashes the delivered output payload using SHA-256 and includes that hash in the structured receipt sent to the buyer. The Hedera Consensus Service anchor (described in our x402 article) commits the same hash to an immutable on-chain ledger.
The escrow contract does not verify the hash directly — that would require the contract to receive the payload, which is impractical for variable-length data. Instead, the verification is post-settlement: if the buyer disputes the service quality, they have three independent proofs — the receipt hash, the HCS anchor, and the on-chain settlement transaction — to make their case. The combination of pre-settlement policy enforcement (via the hook) and post-settlement auditability (via the hash anchor) covers the trust gap without requiring a real-time oracle.
Starting with v1 was the right call. The problems we encountered — partial settlement, monolithic architecture, output verification — were not design flaws; they were discoveries that only production traffic could surface. A longer design phase would not have revealed them. We would have shipped the same bugs with a more expensive spec.
The one decision we would change: we would have deployed the hook pattern from the start. The cost of splitting the contract into custody and policy layers was low — a few days of development and testing — and the benefit was immediate. Every subsequent feature request — rate limits, refund caps, token restrictions — went into the hook instead of requiring an escrow migration. The monolithic-to-modular migration was the most valuable single architectural change in the project.
Our escrow contracts exist because we needed them for our own x402 payment flow. They are also publicly deployable: any two parties that want on-chain hold-and-release settlement can use the same contracts with their own wallets and parameters. The escrow does not care whether the transaction is for an API call, a freelance deliverable, or a cross-border trade. The logic is general.
Franklin Templeton's $3–5 trillion tokenization forecast rests on infrastructure like this: programmable settlement rails that handle the custody, policy, and proof layers that institutional counterparties require. An escrow contract is not the glamorous end of that stack. It is the load-bearing wall.
Both contracts are live on Base and auditable on Basescan. Settlement integration documentation is available at agents.ai-rook.com.