How Money Can Wait: Escrow, Execution Proof, and Conditional Settlement
Once an agent's identity and authority have been bounded, the next problem is deciding when money should move. This chapter examines conditional settlement: locking funds before work begins, collecting evidence while the agent acts, and releasing or refunding value only after a defined verification condition is met. The goal is not to claim that a cryptographic proof makes an outcome automatically good. It is to show what escrow and execution evidence can establish, where the proof boundary ends, and why the required rigor should depend on the stakes.
The ordinary payment sequence is optimistic. The payer authorizes a transfer, the rail confirms it, and the service is expected to follow. That sequence is efficient when the service is simple, the counterparty is trusted, or the cost of failure is small. It is a poor fit for a workflow in which an autonomous agent selects the service, coordinates the work, and may be difficult to hold accountable after funds have been released.
From locked funds to an execution proof
Escrow changes the initial condition. Instead of sending the provider its fee immediately, the system locks the funds in an account or contract associated with the obligation. The money is reserved, but the provider cannot receive it until the release condition is satisfied. If the task fails or times out, the same mechanism can support a refund or an escalation path.
That intermediate state is valuable because it gives the system time to observe execution. It does not settle the dispute by itself. Escrow only creates a place where the financial consequence can wait while the system checks whether the authorized task occurred. The release rule still has to name the evidence that counts and the obligation to which it belongs.
TessPay's proposed Verify-then-Pay architecture calls that evidence bundle a Proof of Task Execution, or PoTE. In the proposed flow, the service agent emits execution metadata and proof artifacts while it works. A verification service collects those artifacts, checks them against a proof set defined for the task, and assembles a PoTE. A Merkle root—a compact cryptographic commitment to the bundle—is anchored so that later checks can establish whether the referenced evidence has changed. The escrow releases funds only when the verification predicate accepts the required proof set.
Several different artifacts contribute different kinds of assurance. A TLSNotary receipt can provide cryptographic evidence about a specified HTTPS interaction. It can help show what request and response passed between the agent and an external service. A trusted execution environment, or TEE, can produce an attestation about the environment in which a workload ran. It addresses a different question: whether the claimed workload ran inside an attested, isolated environment. The A-JWT in TessPay's proposal carries authorization and an integrity binding for the executing agent, linking the action to a scoped identity and its defining configuration. The Merkle root then commits the assembled set of artifacts to an immutable reference.
These pieces should not be treated as interchangeable. A TLSNotary receipt is evidence about an interaction. A TEE attestation is evidence about a runtime environment. An A-JWT binding is evidence about authorization and agent integrity as defined by the proposal.