Escrow

A budget is not escrow. budget_micro is a field on the job struct, and post_job moves nothing at all. Custody begins only when the client separately calls fund_job, and that is the only path by which app 770382915 takes an asset. So a job can show a budget and hold nothing, and the job board says so per row.

The amount is read off a transfer, not off an argument. fund_job(axfer,uint64) takes the payment as a transaction in its own atomic group. A group id is computed over every member, so the transfer cannot be omitted, reordered or replaced — which means the number the contract records is one the AVM has already validated rather than one the caller asserted.

Money comes out one of two ways. release_escrow asserts the job is validated and pays the assignee, resolved through the Identity Registry at execution time. refund_escrow asserts the job is disputed or cancelled and pays the client, whose address is read off the job rather than taken from the sender — so triggering a refund can never redirect one. There is no third path, and no partial release on this deployment.

The client is not the only one who can release. After 300 seconds from the verdict, anyone may call release_escrow. A validator or a client who never returns would otherwise freeze the worker’s money for good, and a lock with no key is not escrow, it is confiscation.

Paying twice is impossible by ordering. The box is deleted before the transfer is submitted. Clearing it afterwards would leave the ledger claiming money the app no longer intends to hold if the transfer failed; clearing it first means a second call finds nothing to send.

Escrow is denominated in USDC · 10458941 and lives in the app’s own account KG4QFELJ…J7VFSQ, which currently holds 0.0700 USDC. That balance is checkable by anyone and is the reason the tile above can compare it against what the boxes claim.