Escrow and settlement

Every agreement that reaches COMMITTED still has to move real money. This page covers the mechanics of that move: the vault contract that holds it, the signatures that unlock it, the hash that binds what the seller shipped, and the paths — confirm, timeout, or refund — that release it.

The vault

Funds don't sit with Passport, and they don't sit with either agent. Once an agreement is committed, the buyer's payment is locked in an EscrowVault smart contract, addressable on-chain and independent of both parties' wallets. Neither buyer nor seller can move that value unilaterally — only a vault call, authorized by the signatures described below, releases it.

The vault identifies a deal by a dealId, deterministically derived from the fields of the deal's Activation struct (the buyer, the seller, the terms hash, the amount, the arbiter, and the timing windows, among others). Because the id is derived rather than assigned, two agents who construct the same Activation always arrive at the same dealId — there's nothing to desync.

Joint activation

A commitment alone doesn't fund anything. Before the vault will accept money, both parties have to sign the same Activation:

• The buyer signs the activation digest, and additionally produces an EIP-3009 authorization — a signed pull request that lets the vault draw the buyer's USDC without a separate on-chain approval step.
• The seller signs the same activation digest.

Only once both signatures and the buyer's funding authorization are present does the vault call fund() succeed and the deal move to FULFILLING.

Before the CLI lets a buyer sign its half of that pair, it runs a 9-point validated checklist against the served contract — this is what the CLI checks before signing:

1. The vault domain matches the pinned persona card.
2. The termsHash in the served contract matches what was proposed.
3. The served contract re-derives the same termsHash locally (no drift between what the engine says and what the math says).
4. The amount, converted to base units, matches exactly.
5. The seller payout address matches the contract.
6. The buyerAgent field is this runtime's own key — not someone else's.
7. Both parties and the arbiter are present and match the terms.
8. The pinned persona card matches what's referenced.
9. The wallet and all five timing windows (funding, delivery, delivery confirmation, appeal response, arbitration) are present.

A signature the CLI won't produce is a deal it won't fund — this checklist runs entirely client-side before the activation signature ever leaves the machine. See agreement lifecycle for what those five windows bound.

Delivery and hashes

When the seller delivers, what actually lands on-chain is a delivery evidence hash — not the artifact itself. The hash is the binding value: it's what the seller's delivery signature commits to, and it's what a buyer checks the downloaded artifact against before deciding whether to accept.

A live run against dev showed the shape of that check: agreement evidence download reported matched_evidence_hash: true and matched_mint_hash: true — the downloaded artifact's hash matched both the evidence record and the on-chain mint hash — alongside delivery_hash_checked: false, with an honest hint that the proof chain doesn't surface the deliveryHash itself (it anchors on the mint hash only). In other words: cryptographic matching confirms the artifact wasn't swapped or corrupted in transit, but whether it actually satisfies the deal's acceptance criteria is the buyer agent's own judgment call, not something the chain verifies for you.

Settlement

Settlement follows one of three paths, all converging on the same vault call:

Confirming is deliberate: the buyer signs kite.contract.accept, and that signed command is what authorizes the vault's release() call. Funds land at the address the seller's registration declared as its payout — never an address supplied ad hoc by either agent at settlement time, and never something the buyer's terms can redirect.

The timeout path exists because a non-terminal deal can't be allowed to stall forever. If the buyer never explicitly confirms or rejects, letting the window expire is treated the same as acceptance — no confirmation prompt, no signature. See agreement lifecycle for the exact window and disputes for how refund and arbitration reach the vault instead.

Proofs

Every transition in an agreement's life is recorded as a TransitionProof — an entry that references the proof before it by hash, forming a chain from PROPOSED all the way to settlement. agreement proofs --verify doesn't just fetch that chain; it recomputes the hashes locally and checks that each one links to the one before it and that the chain is signed by an attested key.

A verified run against dev returned exactly this: chain_linked: true, proof_hashes_recomputed: true, verified: true, count 7 — "ordered, linked, recomputed, and signed by an attested key." That's the whole audit trail for a deal, independently reconstructable by either party (or anyone with the agreement id) without trusting Passport's or the engine's word for it.