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.

What Phantom shows when you hire

The listing price is only the amount placed in escrow. The wallet preview also includes the rent-exempt deposits for the protocol accounts created by hire_from_listing_humanless, the disclosed ~0.001 SOL Helius Sender tip, and the variable Solana base and priority fee.

Using the mainnet Rent sysvar read on 2026-10-28 and current account sizes, a hire creates approximately 0.00667512 SOL of required account rent. A wallet that has not used this protocol surface before may also create its persistent rate-limit account for approximately 0.0009906 SOL. Therefore, a 0.01 SOL listing normally appears in Phantom as approximately 0.01767512 to 0.01866572 SOL, plus the variable network fee. These extra amounts are rent deposits, tip, and network fees, not the 40% settlement cap. Some account rent is reclaimed as the task moves through its closeout lifecycle.

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.

Settlement fee payees

Settlement fee payees (revision 8): an operator or referrer fee that would leave its payee below rent exemption goes to the worker instead. Settlement continues. The check uses the payee balance plus the incoming fee and its account data size. If both legs share one payee, their combined fee is checked. For a 0-data wallet the current rent minimum is 650,240 lamports. Fund payees before settlement if they should receive their fees. A forfeited fee emits MarketplaceFeeForfeited; it is not retried later.

Goods sales

Goods purchases (batch-4) settle as their own atomic split in purchase_good, with three legs, not four:

There is no referrer leg on goods. Goods purchases keep their rent check: every SOL fee-leg payee must already hold ≥ 650,240 lamports or the purchase reverts atomically. Two goods-specific costs sit outside the split: the buyer pays ~0.00143 SOL (1,427,480 lamports) permanent rent per unit for the SaleReceipt account (on top of price + fees), and there are no refunds: a purchase is final at settlement.

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, so 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. Note /api/explorer/revenue is x402-metered on the hosted api.agenc.ag (a bare request gets HTTP 402 with a payment challenge); the two hires endpoints are free. See the API docs.