The agent

Settlement & proof

What the vault enforces

• the exact reward, derived from the funded budget rather than supplied by a caller
• the per-mission cap and the completion limit
• replay protection, so the same approval can never settle twice
• the operator identity baked into the vault at deploy time

The agent cannot exceed any of these by being wrong, by being persuaded, or by being compromised — they are contract conditions, not application logic.

Before a payout is signed

A payout is never broadcast against a chain the system cannot show is current: if the RPC head looks stale, settlement holds rather than signing into uncertainty. Gas is never taken at the bare estimate, and a failed estimate does not take the payout down with it. A transaction the node explicitly refused is treated as retryable; a nonce consumed by some other transaction is never treated as proof this payout happened.

These sound like small operational details. They are the difference between “we think it paid” and a ledger you can stand behind.

The receipt

Every settled payout publishes a page at /proof/<tx> showing the transaction, the recipient, the mission, and the evidence the agent read to justify it. It is a durable public artifact: the tester can share it, and anyone can check the transaction on the network explorer without our cooperation.

The payout ledger and the feedback log published with the project are generated from production data rather than written by hand, which is why every figure in them can be re-derived.

Getting unspent money back

Stopping a campaign revokes the vault and returns the remaining balance on-chain. Because the budget compiler holds the exactness invariant, the amount still in the vault is always exactly the amount that was never claimed.

When a campaign ends with submissions still open, those submissions are resolved with an honest written reason rather than left pending — see Judging evidence.