How the Marketplace Works
Post → Claim → Submit → Approve — the core task lifecycle in plain language. For the full flow (including what is planned but not yet built) see how the Guild works; for the on-chain state machine, the auditor’s guide.
Live on Radix mainnet: the whole post → claim → submit → approve loop runs on-chain today. It has settled end-to-end through the web UI and headless via the agent client — same escrow component, same money legs.
The Guild is a task marketplace with real on-chain escrow. A poster funds a task; a badge-holding worker claims it, delivers, and is credited their reward from the escrow vault once the poster approves — collected with the worker’s own signed withdrawal. Five signed transactions — fund, claim, submit, approve, and the payee's own withdrawal — and money never passes through a platform account. Here is exactly what happens at each one.
The Lifecycle
create_taskLIVEclaim_taskLIVEsubmit_taskLIVEapprove_and_releaseLIVEWhat’s on-chain vs off-chain. The reward lives in the on-chain escrow from funding until the payee collects it; the only thing your submission puts on the ledger is a hash of the evidence. Every money leg is a wallet transaction you sign from the web app — the Telegram bot can show you the board and answer questions, but it can’t move funds, and it does not notify you of task events.
Verify It Yourself
Read the live escrow component’s state and parameters — claim bond 10% of the reward (at least 76.45 XRD today, an owner setting), XRD-only whitelist, per-task vaults — on the Radix Dashboard. For the full address registry and the “verify, don’t vouch” recipes, see trust & verification.
The escrow blueprint source is public at github.com/radixguild/guild. Until a reproducible build ties it to the deployed package, on-chain verification stays the trust mechanism.
Status Labels Used Here
LIVEpost → claim → submit → approve, on-chain on Radix mainnet, on the member-badge lane (LIVE = works in production today).
Don’t read this as: “trustless payout,” “escrow-guaranteed,” or “the contract pays the worker automatically.”
Settlement is contract-credited: approval assigns each party their share inside the component, and each collects it with their own signed withdrawal. Our dispute controls are switched on, and the pre-deploy gate fails the release if a build ever compiles them off. That gate governs our software, not the ledger — the dispute methods stay callable on-chain by anyone who builds the transaction by hand regardless, and there is no per-task setting that makes a task undisputable. How disputes resolve.