Disputes & Arbitration
DORMANTAccompanies wizard step: none(deliberately not surfaced to pilot users) · Status: DORMANT (code-complete, policy-disabled).
The dispute path exists on-chain and works — and we have switched our own dispute UI off rather than run it with a known drain vector. The public auto-resolve method (below) is the reason, and telling you that reason plainly is the point. The reason it’s off is itself the trust signal.
Being equally plain about the limit of that: switching our UI off governs our software, not the ledger. The dispute methods stay callable on-chain by anyone who builds the transaction by hand. There is no per-task setting that makes a task undisputable — every funded task that reaches Submitted can be disputed by either party to it. What we actually run against that today is a deploy gate, a 30-minute alert, and a board where both sides of every task are still the guild itself.
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 today. None of it has ever been used — because the fallback method is callable by anyone, so at pilot scale we keep the surface small: our own dispute controls are off, every live task still has the guild on both sides of it, and we cap what any single task is worth.
raise_disputeresolve_disputeauto_resolve_disputeThe default ruling is SplitEvenly (a 50/50 split), 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.
auto_resolve_dispute is public and has no auth: once the 72h window passes, any account can call it. And like every settlement path in the current blueprint, it returns the funds to the caller’s manifest rather than depositing directly to the poster and worker (this is the known limitation we track as BUG-7). Put together, a third party could call it after the window and route both the reward and the insurance to themselves.
A 0% platform fee does not mitigate this — it is a routing property of the blueprint, and the fix is a blueprint change (deposit via an AccountLocker), which is audit-gated future work.
Until that lands, what stands between the method and a pot is three things, and we would rather name them than overstate them. One, a build gate: the dispute UI is compiled off, and the pre-deploy check fails the release if a build ever has it on — so it cannot ship by accident. Two, detection: a watch-only keeper and an escrow drift watcher alert a human within 30 minutes if any task appears in the Disputed state. Three, scope: every live task still has the guild on both sides, and we cap what a single task is worth so that the worst case stays small.
That is a blocking gate plus detection plus a small blast radius. It is nota guarantee that nothing can enter the Disputed state — the on-chain methods do not care what our UI does — and the third item is a fact about today’s board rather than something the code enforces. When the board opens to counterparties who are not us, that item stops holding, which is why the blueprint fix gates it.
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 (Wave C) — the escrow blueprint is private until then. No repo link here yet by design.
Our dispute UI is compiled OFF (NEXT_PUBLIC_FEATURE_DISPUTES default false), and the pre-deploy launch gate hard-fails if a build ever has it switched on — so we cannot ship it by accident. Turning it on for real is gated on a re-audited blueprint fix, not a config toggle. This governs OUR software: the on-chain methods stay callable by a hand-built manifest regardless.
On the ledger: the arbiter badge (supply 1), the three dispute methods, the 72h window, and the SplitEvenly default. Live and verifiable — and reachable by anyone who builds the manifest themselves, not just by us. No task has ever entered Disputed on mainnet.
Full trust story: verify, don’t vouch and the auditor’s guide. Questions or anything that looks off: say it on Telegram.