> For the complete documentation index, see [llms.txt](https://docs.arcv.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcv.network/6.-protocol-economics-and-tokenomics/6.2-protocol-revenue-engine.md). # 6.2 Protocol Revenue Engine ## Economic policy and implementation boundary ARCV specifies a target protocol take-rate of **10% of gross accepted enterprise settlement value**, allocated equally to the operating treasury and a token buyback budget. This chapter defines the accounting, execution, and reporting requirements for that policy. It does not establish that the fee engine is deployed. The repository's current registry pays the entire fixed reward to the contributor when validateAndDisburse(datasetId) succeeds. It contains no protocol fee deduction, treasury split, DEX execution, or token burn. The enterprise frontend's existing 5% estimate is another implementation mismatch; it does not enforce the 10% policy described here. Activation requires a reviewed contract implementation and matching enterprise quotes, contributor reward disclosures, indexers, and tests. Existing funded campaigns must retain their agreed terms. See [contract architecture](/5.-smart-contracts-and-arc-network-settlement/5.1-contract-architecture.md). ## Revenue recognition and the settlement denominator Gross merchandise value, denoted G, is the native USDC value consumed from enterprise escrow for accepted payable work. It is not the initial deposit, token market capitalization, token sale proceeds, or total value of pending submissions. A campaign can be fully funded while producing no earned protocol revenue. For a task requiring three independent reviews, each accepted paid review contributes its own settlement value. The logical task must not also be counted as an additional payment. Golden Patch bonuses enter G only when separately funded and accepted under the campaign terms. Rejected work, unused escrow, and failed transactions contribute zero realized settlement volume. | Cash flow or record | Enterprise GMV? | Reason | | ------------------------------------------------------ | --------------- | ----------------------------------------------- | | Enterprise deposits campaign escrow | No | Funds remain encumbered by campaign obligations | | Accepted paid review settles | Yes | A defined payable unit consumes escrow | | Accepted, funded Golden Patch bonus settles | Yes | Additional compensation becomes earned | | Failed or reverted settlement | No | No final payment occurred | | Unspent escrow returned to its creator | No | Return of principal is not a service sale | | Treasury wallet transfers to another controlled wallet | No | Internal movement is not revenue | | Network gas expenditure | No | Execution cost is accounted separately | The present contract has no cancellation or refund function; unused balances must not be described as currently reclaimable through a nonexistent refund API. Refund controls belong in a future implementation and its campaign terms. ## The 10% fee and 50/50 waterfall The proposed gross-settlement accounting identity is: ``` G = gross accepted settlement value F = 0.10 × G protocol fee W = G - F = 0.90 × G contributor compensation T = 0.50 × F = 0.05 × G operating treasury allocation B = F - T = 0.05 × G buyback allocation G = W + T + B ``` ``` Enterprise escrow: accepted payable work | v Atomic settlement accounting: G | +-----------+--------------------+ | | v v Contributor entitlement Protocol fee 90% G 10% G | +------------+------------+ | | v v Core treasury Buyback budget 5% G 5% G Native USDC Native USDC | | Compute / storage / Bounded market execution infrastructure | v Token custody reconciliation | v Verified burn or disclosed dead-address transfer ``` Treasury receipts fund validator inference, permanent storage uploads, cache delivery, node infrastructure, monitoring, and development. Allocation to the treasury is revenue; spending it on those services is a separate expense. The buyback share remains a restricted budget until it is executed or changed under an explicitly disclosed prospective policy. ### Gross reward versus promised net reward Campaigns must label whether a displayed reward is gross or net of the fee. A 0.25 USDC gross accepted reward gives 0.225 USDC to the worker before base-unit rounding. A promised 0.25 USDC net reward requires approximately 0.277777777777777777 USDC gross funding under the floor-rounded fee convention below. Adding 10% to a net reward is different: 0.25 × 1.10 = 0.275, and a 10% deduction from that amount leaves 0.2475. The interface must not call that a 0.25 net payout. The same distinction applies to the advertised +0.50 USDC Golden Patch bonus. If the campaign promises that amount net, gross up its allocation rather than reducing it after acceptance. For N input items, K paid reviews per item, gross review reward g, and P accepted patches at gross bonus h: ``` Maximum modeled settlement = N × K × g + P × h Treasury allocation = 5% of realized accepted settlement Buyback allocation = 5% of realized accepted settlement ``` P is bounded by the funded patch policy. A contributor enabling a patch editor does not by itself reserve or earn the bonus. ### Reference allocation scenarios These are arithmetic examples, not historical revenue disclosures. | Accepted settlement, USDC | Contributor net | Protocol fee | Core treasury | Buyback budget | | ------------------------: | --------------: | -----------: | ------------: | -------------: | | 1,000.00 | 900.00 | 100.00 | 50.00 | 50.00 | | 10,000.00 | 9,000.00 | 1,000.00 | 500.00 | 500.00 | | 100,000.00 | 90,000.00 | 10,000.00 | 5,000.00 | 5,000.00 | A 5,000-item campaign with three accepted reviews per item and a 0.25 USDC gross reward generates 3,750 USDC at full completion. Worker compensation is 3,375, treasury allocation 187.50, and buyback allocation 187.50. At 60% completion, realized settlement is 2,250 and the protocol fee is 225. The remaining campaign capacity is not earned revenue. ## Base-unit accounting and rounding Arc native USDC accounting uses 18-decimal native-value units. Calculations must use integers rather than binary floating point. ERC-20 representations can have different conventions; native-value settlement must not inherit a six-decimal assumption from another chain. The following executable reference defines the proposed rounding convention. It floors the fee, allocates half to treasury, and assigns any one-base-unit fee remainder to buybacks. It also finds the smallest gross amount that preserves a promised net payment. ```python from decimal import Decimal SCALE = 10**18 BPS = 10_000 FEE_BPS = 1_000 def waterfall(gross: int) -> dict[str, int]: if type(gross) is not int or gross < 0: raise ValueError("Gross value must be a nonnegative integer") fee = gross * FEE_BPS // BPS treasury = fee // 2 buyback = fee - treasury worker = gross - fee assert worker + treasury + buyback == gross return dict(worker=worker, fee=fee, treasury=treasury, buyback=buyback) def gross_for_net(net: int) -> int: if type(net) is not int or net < 0: raise ValueError("Net value must be a nonnegative integer") low = net high = (net * BPS + BPS - FEE_BPS - 1) // (BPS - FEE_BPS) while low < high: middle = (low + high) // 2 if waterfall(middle)["worker"] >= net: high = middle else: low = middle + 1 return low if __name__ == "__main__": for gross in (0, 1, 9, 10, 19, 20, 3750 * SCALE): result = waterfall(gross) assert result["worker"] + result["treasury"] + result["buyback"] == gross net = SCALE // 4 gross = gross_for_net(net) assert waterfall(gross)["worker"] >= net assert gross == 0 or waterfall(gross - 1)["worker"] < net print("Gross USDC for 0.25 net:", Decimal(gross) / SCALE) print(waterfall(3750 * SCALE)) ``` A future Solidity implementation must bound arithmetic or use a reviewed full-precision multiply/divide operation. Rounding applies per payable settlement, so summing individually rounded fees can differ from applying 10% once to an aggregate. Reports must reconstruct actual transaction amounts, including dust, rather than replacing them with ideal percentages. ## Atomic settlement and independent market execution The desired acceptance transaction atomically records the worker payment and both fee allocations. If it reverts, all associated allocations revert. That requirement does not imply that a DEX swap must execute inside every contributor settlement. Coupling a swap to acceptance introduces dependencies on router availability, pool liquidity, slippage, and token transfer behavior. A decoupled executor can instead consume accrued buyback balances under approved limits. This keeps a failed market trade from blocking otherwise valid worker settlement. It is an architectural recommendation requiring implementation, not a feature of the present registry. A fee release should bind the campaign's rate and beneficiary configuration at creation, impose an immutable or tightly governed maximum rate, and enforce conservation across worker liabilities and fee balances. Administrative changes must not redirect existing accepted-worker claims. Failed native transfers need an explicit retry or claim design; a UI success indicator cannot substitute for an on-chain receipt. ## Programmatic buyback control loop The executor consumes only reconciled buyback funds. It must verify the token, chain, active trading venue, and router against the deployment record described in [fair launch architecture](/6.-protocol-economics-and-tokenomics/6.1-arcv-token-and-fair-launch.md). ``` Accrued settlement allocations | v Reconcile available budget and prior execution IDs | v Validate venue / quote / liquidity / execution limits | +-----+------+ | | limits fail limits pass | | retain USDC v and alert submit bounded swap | successful receipt? / \ no yes | | reconcile v before retry verify token balance delta | v execute removal | v reconcile and publish ``` Each order needs a maximum native USDC spend, minimum token output, freshness limit, execution deadline, per-period ceiling, and explicit gas funding source. A timeout is not proof that a transaction failed: check its receipt and replacement status before resubmitting. Prevent duplicate execution using unique batch references and confirmed spend records. If Q is quoted token output and s is slippage tolerance in basis points, minimum output is floor(Q × (10,000 - s) / 10,000). This constrains execution relative to the quote; it does not establish that the quote itself is fair. Price-impact and manipulation controls are separate requirements. For an illustrative 500 USDC allocation with 5 USDC of costs charged to that allocation and an average realized price of 0.002 USDC per token, acquisition is 247,500 tokens. If costs are instead funded by the operations account, all 500 can fund the order. The expense policy must identify which treatment applies and never subtract the same cost twice. ## Permanent removal: burn versus sink transfer The designated dead address is **0x000000000000000000000000000000000000dEaD**. It is not the all-zero address. A normal ERC-20 transfer to that destination does not necessarily reduce totalSupply. A true supply-reducing burn destroys tokens in the holder's balance and reduces reported supply. A public burn(amount) method generally burns the caller's holdings; it is not a transfer to a dead address followed by a burn of tokens no longer held. The external token's actual ABI, permissions, and bytecode determine whether this operation exists. [OpenZeppelin ERC-20 documentation](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) | Removal mechanism | Required evidence | Accurate reported metric | | ------------------------------ | ---------------------------------------------------- | ------------------------------------- | | Supply-reducing burn | Successful call, balance reduction, supply reduction | Tokens burned; supply reduced | | Ordinary dead-address transfer | Successful transfer, destination balance increase | Tokens transferred to designated sink | | Purchase retained in executor | Receipt and acquired balance | Tokens purchased, not removed | | Pending or failed transaction | Pending or reverted receipt | No completed removal | Do not claim an unverified faze.fun token implements burn. If sink transfers are the only supported removal mechanism, disclose that limitation and keep sink balances distinct from reduced supply. Reconcile receipts, logs, balance changes, and supply at explicit block boundaries; concurrent issuance or other burns must be attributed separately. ## Volume and buyback accounting The public split allocates 90% of accepted settlement to contributors, 5% to treasury, and 5% to buybacks. Deposited escrow and rejected submissions do not themselves create earned revenue. The buyback allocation determines a USDC budget; acquired token quantities depend on execution price, fees, and liquidity. It does not guarantee a price floor or investment return. ## Reconciliation and reporting requirements The accounting ledger must link campaign ID, payable record, settlement transaction, worker amount, fee rate version, treasury amount, and buyback accrual. Execution records add order identifiers, router, quote and minimum output, USDC spent, acquired quantity, costs, and removal evidence. Reorg handling must reverse orphaned records before replaying canonical events. For each reporting period, publish opening restricted buyback funds, new allocations, spending, costs charged to the fund, and closing restricted funds. Report tokens acquired, supply-reducing burns, and sink transfers separately. Internal treasury transfers must not inflate receipts. These records make the revenue policy auditable without implying that the current contract already implements it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.arcv.network/6.-protocol-economics-and-tokenomics/6.2-protocol-revenue-engine.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.