Auditor’s Guide

One Scrypto component (guild-marketplace-escrow, Radix mainnet) enforces a six-state task lifecycle. The app (Next.js + Postgres) is a mirror and a convenience — the ledger is the source of truth, and a reconciler heals the database from chain events, never the reverse.

Open ──claim──▶ Claimed ──submit──▶ Submitted ──approve──▶ Released   (terminal)
  │                │                    │
  cancel        expire/cancel        dispute ──resolve/auto──▶ Released | Refunded (terminal)
  ▼                ▼
Refunded (terminal)

Auth pattern worth auditing, and settlement is the part to read twice — it is two-phase. approve_and_release, auto_resolve_dispute and the cancel paths move no money outward: they drain the escrow vaults into per-party entitlements held inside the component. Three methods do return a Bucket to their caller, and none of them can reach a task's reward: resolve_dispute returns the arbiter's fee (taken from the insurance, capped per task by max_arbiter_fee_pct, callable only with the arbiter badge), expire_claim returns a bounty of expire_bounty_pct of the forfeited claim bond to whoever calls it once the claim deadline and its grace window (expire_grace_secs) have passed, and the OWNER-only withdraw_forfeited_bonds returns the rest of forfeited bonds. Entitlements leave only through withdraw_worker / withdraw_poster and the public push_entitlement, and each deposits from inside the component into an account pinned earlier — the worker's at claim_task, the poster's at create_task — because deposit_both_lanes calls try_deposit_or_abort on that stored address. The caller never names that destination, so those three being callable by the payee or by anyone moves no value to whoever calls them. That pin is the property worth attacking: the worker badge and the task receipt are both transferable bearer instruments (neither resource calls withdraw_roles!, so both inherit the SDK default withdrawer=AllowAll), so stealing one lets you CALL the withdrawal — and the money still lands in the pinned account. Public-mint governs forging a credential, transferability governs stealing one, and the payee pin is what makes the second one not pay. On receipts, the two differ: the claim receipt is one-shot and burned at submit_task, but the task receipt is NOT burned at approval — under pull it is a persistent entitlement key presented as a Proof, retired explicitly via burn_task_receipt once both poster lanes read zero and the task is terminal. Recurring acts use Proofs; safety releases (expire_claim, auto_resolve_dispute, release_after_review_timeout) are PUBLIC and time-gated. push_entitlement takes no Proof and no destination: anyone may call it to deliver a settled entitlement to its pin, so a lost or unnoticed credential does not strand the money (it still aborts if the pinned account refuses the deposit), and a hostile caller only pays the network fee to pay a stranger their own funds. One consequence worth auditing: deposit_both_lanes coerces the payee to an Account on every path that pays out, push_entitlement included, so a component (a funding pool, say) cannot yet be a payee.

If you have a better mechanism for any of these: post it as a task. That is not a slogan; it is the product working on itself.