Verify, Don’t Vouch

Every funded task's reward and insurance sit in the component's vaults — the escrow balances are public. Posting and funding are two separate steps, so a task can be listed before it is funded; those hold nothing on chain and are labelled 'Awaiting escrow funding — not claimable yet'. Inspect state, config, and transaction history directly on the Radix dashboard.

expire_claim and auto_resolve_dispute carry no badge requirement — anyone can call them once their time gate passes, so no absent platform can hold a task hostage. Two limits we will not paper over. A Submitted task has no auto-release in the deployed component: a poster who goes silent can leave a worker waiting indefinitely (auto-release is a vNext2 change). And because expire_claim is permissionless it cuts both ways — from the second a claim deadline passes, anyone can call it and forfeit the claimer's whole bond — 10% of the reward, never less than 76.45 XRD, capped on-chain — racing a late submit that would otherwise still succeed. Submit before your deadline.

Our keeper is watch-only by decision: it alerts humans over Telegram and holds no signing key. Winners finalize from their own wallets. What that does mean: the contract itself decides who is owed what — approve_and_release credits the worker and the poster inside the component, payable only to the accounts pinned when the task was claimed, so the settlement transaction cannot redirect either share. Read the manifest your wallet shows you before you sign anyway. The limit that remains is that a credited share is not a collected one until you sign your own withdrawal.

Acceptance criteria, deadlines, and revisions are SHA-256 committed into the task (work_brief_hash) at funding. Nothing about the brief can change afterwards without breaking that hash, so tampering is detectable by anyone. Honest scope: the component stores the hash, it does not judge against it — that is what the arbitration path is for, and it is an operator ceremony with no promised turnaround, not an automatic judge.

resolve_dispute checks one identity: the arbiter may not be the task's worker (the chain asserts it and reverts otherwise). It does not, and cannot honestly, check the poster — the poster field is a caller-supplied destination, not a verified identity, so a poster-side check would defeat itself for the price of a decoy address. In practice: an arbiter who funded a task may still rule on it. They cannot steal doing so — settlement pays only the accounts pinned at claim and funding, never the arbiter — but they can rule in their own favor as poster. The arbiter badge has supply 1 today, so this is worth weighing plainly rather than assuming away.

Publishing — opens at launch, and no date is set. The money-path blueprint is the part readers need first.

Follows source publication: build the blueprint yourself, compare the hash against the deployed package.

Posted as real on-chain Guild tasks once the source is public — the pot is provably funded, the payout path is the product itself. In the meantime, a beta bug bounty (manually-paid XRD gifts) runs at /bug-bounty.

An on-ledger, metadata-named pledge with a visible unlock date — amount and duration to be announced.

Tasks and projects over $50k USD: we engage a third party to attest the operator's identity and standing — accountability without public doxxing. No trustee is retained standing; one is engaged when the first such engagement appears, so allow lead time.