Disputes & Arbitration
LIVEAccompanies wizard step: none (deliberately not an onboarding step — this is a break-glass path) · Status: LIVE (since P3-3, 2026-08-27 — proven on mainnet first).
One limit worth stating plainly: the arbiter may not be the task's worker — the blueprint enforces that, because the worker is pinned on the task when they claim it. It does NOT stop an arbiter who funded a task from ruling on it. That side is not enforced on-chain, because a funder is not recorded on the task, so there is nothing for the contract to compare against. Treat it as a policy we hold ourselves to, not a rule the ledger keeps for you.
We turned our own dispute controls on because leaving them off had become the worse option. The escrow has no auto-release by design, so if a poster goes quiet after a worker submits, disputing is that worker's only on-chain way out — an off UI just hid the affordance while the methods stayed callable by hand regardless. And we did not flip it the day it became technically safe: we flipped it only after proving the whole path end to end on mainnet — prediction written down first, then signed, then matched exactly — because “raising a dispute wins you nothing” is the one guarantee here better proven than asserted.
Being equally plain about what this does not promise: the fallback ruling is a fixed 50/50 split of the reward, not a judged outcome — settle disagreements off-chain first if you can. An arbiter can rule before the window closes, but that is an operator ceremony today, signed from the wallet holding a supply-1 badge, not a button either party clicks — and we promise no turnaround time. What bounds the worst case is a fixed-loss ceiling — half the reward, with the insurance always returning to the poster — and an arbiter who can still act before the window closes. Watchers that would normally page a human within 30 minutes of any task entering Disputed are paused right now; that paging resumes once they are back running.
What This Is
If a poster and worker disagree over delivery, a marketplace needs a way to break the tie. The Guild’s escrow blueprint ships one: a task can be moved into dispute, an arbiter can rule on how the funds split, and if no one rules within a set window the contract falls back to a default split.
All of that is deployed on Radix mainnet, and we ran it ourselves end to end before turning our UI on: on-chain task 3 was deliberately moved into Disputed on 2026-08-23, and its 72h auto-resolve settled on 2026-08-26 — worker and poster both collected, the component ended back at 0, and conservation was exact to the last decimal. See the ledger evidence below. No outside user has been in a dispute here yet; the path was kept to our own accounts until that settlement proved it.
What It Actually Does
raise_disputeresolve_disputeauto_resolve_disputeThe default ruling is SplitEvenly (a 50/50 split of the reward; the poster’s insurance returns to them in full either way), re-verified against the live component via the Gateway. Older drafts said FavorDisputeRaiser — that is wrong for the deployed component; do not rely on it. The auto-resolve window is 72 hours.
How It Resolves
Two ways out of a dispute. A human arbiter can rule it — a supply-of-one badge, run by the operator as a ceremony, with no deadline of its own — and their fee is fixed at zero: arbiter_fee_pct is 0 on every task this app funds, so insurance funds no arbiter. If nobody rules first, auto_resolve_dispute is public and has no auth: once the 72h window passes, any account can call it, and it applies the component's fixed default — a 50/50 split of the reward, with the poster's insurance returning to them whole. Calling it is a nuisance, not a theft: settlement credits the poster and the worker as entitlements payable only to their pinned accounts, so a stranger who calls it pays the network fee and moves no money to themselves. We promise no turnaround time for a ruling to land before the default fires — there is no public SLA, only the 72-hour chain-enforced backstop. And priced against an honest approval, the lapse costs only the worker: they end with half the reward instead of all of it, while the poster is credited the other half plus their whole premium — a worker weighing an unresponsive poster should know that before counting on a dispute to pressure them.
The caller-routed drain this page used to warn about is closed on the deployed blueprint — settlement moved to pull at the 2026-08-17 cutover, so no method hands a bucket to its caller. What remains is the policy shape stated above: raising a dispute costs only the network fee, wins nothing extra, and the worst a poster can lose to a bad-faith dispute is half the reward — the insurance always comes home. The mirror of that is worth stating too: a poster who stonewalls a submitted task into the lapse ends up better off than one who approves, and only the worker carries the loss.
Three things stand behind that, and we would rather name them than overstate them. One, a build gate: the dispute UI can now only be off by a deliberate rebuild — the pre-deploy check fails a release that compiles it off, the mirror of what it used to guard. Two, detection: a watch-only keeper and an escrow drift watcher normally alert a human within 30 minutes of any task entering or leaving the Disputed state — both are paused right now, so treat that alert as not watching until they are back running. Three, revision first: a poster can request changes before either side reaches for a dispute — that request is a record we keep, not a chain event, so treat a silent one as a reason to check in, not proof it never arrived.
That is a blocking gate plus detection plus a fixed-loss ceiling. It is not a promise that no task will ever be disputed — the on-chain methods answer to the caller, not to our UI — and it is not a promise an arbiter rules before the 72-hour default fires: we have committed to no turnaround time, on purpose, and the fixed 50/50 default is what makes that honest rather than reckless.
Proven End to End on Mainnet
On task 3, we wrote down the predicted outcome before signing anything — worker entitled 10, poster entitled 11, a fixed 50/50 split of the reward, zero arbiter fee, the claim bond untouched — and the chain returned exactly that. Worker and poster each collected with their own signed withdrawal; the escrow component and both of the task’s vaults ended at 0, conservation exact to the last decimal. That is the property this page asks you to trust: not our word, the ledger.
All three CommittedSuccess, 2026-08-26 13:53:43Z → 13:59:08Z. One property worth knowing: the 72h window opened at 00:37:54Z and nobody called the public auto-resolve for 13 hours — permissionless and unauthenticated does not mean someone will volunteer the fee for zero reward of their own.
Verify It Yourself
On the component you can read the live dispute window and the dispute_auto_resolve_default (SplitEvenly) directly — that is ground truth, ahead of any doc.
Opens at launch, and no date is set — the escrow blueprint is private until then. No repo link here yet by design.
Don’t Read This As
Full trust story: verify, don’t vouch and the auditor’s guide. Questions or anything that looks off: say it on Telegram.