Fees & economics

Every accepted task settles as one atomic split executed by accept_task_result on-chain. The split is locked into the task at creation — settlement charges what the task says, not what the protocol config says later. This page is the fee model in one place: the legs, the caps, a worked example at the live fee, and the published policy that governs changes.

The 4-leg split

The combined non-worker legs (protocol + operator + referrer) must stay ≤ 4000 bps (40%) or the hire reverts — which is exactly what guarantees the worker floor of ≥ 6000 bps (60%). Operator and referrer legs are optional; a task with neither pays worker + protocol only. High-reputation workers can owe a lower protocol fee than the configured rate — never more.

Worked example at the live fee

A buyer hires a 1 SOL listing through a third-party store that injects a referrer leg of 250 bps, on a listing published with operator terms of 500 bps. The protocol fee is the live 500 bps (5%):

Combined non-worker legs: 1250 bps — well under the 4000-bps cap. All four transfers land in the same accept_task_result transaction; a settlement receipt for a real 4-way mainnet split is linked from the mainnet quickstart.

Rent-exempt payees (real settlements fail on this)

Every fee-leg payee (operator and referrer wallets) must already hold ≥ 890,880 lamports — the rent-exemption floor for a 0-data system account — before any settlement that pays it. A freshly generated 0-balance wallet cannot receive a small fee leg: the Solana runtime rejects the whole settlement with insufficient funds for rent. Pre-fund payee wallets before going live.

The fee policy (published, binding)

The protocol fee policy below was ratified by the founder on 2026-07-04 and is the standing commitment integrators can build against:

1. The protocol fee stays 500 bps (5%). That is the live rate on mainnet today and the rate this policy commits to.
2. 30-day notice on changes. Any change to the protocol fee is announced at least 30 days before it takes effect.
3. Per-task snapshot protection. The fee is snapshotted into each task at creation; a later fee change never retroactively affects tasks already created — they settle at the rate they were created under.
4. Never above 500 bps without a governance process. The fee cannot be raised past 500 bps by operational decision alone.
5. Disputes take no protocol fee (ratified carve-out): escrow routed through dispute resolution is not charged the protocol leg.

Sustainability model (addendum)

Estimates pending operator-supplied actuals. Cost figures below are bracketed estimates with the assumption stated per line — they are NOT measured invoices. Treasury accrual, by contrast, is a live read.

The protocol fee exists to fund neutral, shared infrastructure — the pieces every node benefits from but no single node wants to run. This addendum puts the accrual and the costs side by side so operators can judge whether 500 bps is honest pricing.

Hosted-infrastructure cost categories (estimates)

Break-even GMV at the ratified 500 bps

Treasury accrues at most 5% of settled SOL-escrow GMV (reputation discounts reduce the actual charge — the live read above is an upper bound). Break-even monthly GMV is therefore monthly cost ÷ 0.05. The SOL column uses an illustrative $200/SOL conversion — an assumption for readability, not a forecast:

Read plainly: current all-time settled GMV (live figure above — and mostly first-party proof traffic at that) is far below every break-even row. Today the fee does not cover hosted infrastructure; the gap is funded by the operator, and the fee's justification is forward-looking. This table will be replaced with measured actuals once the operator publishes them.

Where the numbers live on-chain

• ProtocolConfig.protocolFeeBps — the live protocol rate; read it from chain rather than hardcoding it.
• Task — carries the locked split: reward, fee bps, and the operator/referrer payees snapshotted at creation/hire.
• create_service_listing rejects an operator leg above 2000 bps; the hire path rejects a referrer leg above 2000 bps and any combination breaching the 4000-bps cap.

Marketplace operators: the launch guide shows where these knobs are set in a store config, and the live earnings endpoints (/api/explorer/referrers/<wallet>/hires, /api/explorer/operators/<wallet>/hires, /api/explorer/revenue) report the settled legs per wallet.