Economic Flows

Lioth coordinates human work through campaigns funded by requesters. Economic flows are anchored to finalized accepted outputs under PHK, while network-phase policy can tune access, timing, and release behavior around that canonical truth.

Reward Model

Campaigns specify a payout amount per accepted task. Contributors receive rewards only when their work reaches finalized acceptance under PHK. A deployment-phase base reward can be combined with:

• a quality-tier multiplier; and
• an operational multiplier where enabled by the active network phase.

This means finalized performance and runtime access policy can both affect effective payout, while PHK finality remains the canonical source of truth for whether a task is accepted or rejected.

Accepted-Output Framing and Campaign Spend

The protocol can frame requester spend around target accepted outputs rather than raw task attempts. Under that model, requester economics stay aligned with finalized accepted capacity: retries and rejection churn are absorbed by the campaign's committed rules rather than becoming a requester-side truth override.

Budget Allocation

Campaigns define total budgets and payout rules. The full protocol design supports escrow line items for work budget, validator budget, audit reserve, dispute reserve, dataset assembly, and protocol fees.

Implementation note: Current live requester launch scope, accepted-output behavior, delivery states, and settlement states are documented in App Status. Current parameter defaults are documented in Protocol Defaults.

Simple Quoting Model

A requester can estimate all-in budget from a target payout per accepted output with:

• N_accept = number of accepted outputs desired
• p = payout per accepted output
• WB = work-budget share
• retry_buffer_pct = tier retry buffer inside WB

Then:

• WB_total = N_accept * p * (1 + retry_buffer_pct)
• TOTAL_budget ~= WB_total / WB_share

Remaining line items can be allocated by tier split (VB/AR/DR/DA/Protocol Fee) in the broader protocol design.

Initial Operational Targets (Not Guarantees)

Each tier has target ranges to guide configuration and reporting:

• Q0: target median finality < 30 minutes
• Q1: target median finality < 6 hours
• Q2: target median finality < 24 hours
• Q3: target median finality < 72 hours

Targets are measured and reported in campaign tier reports and remain governance-adjustable.

Settlement Rules

Per task, settlement follows canonical PHK outcome first and operational release policy second:

• if accepted, the task becomes eligible for contributor reward release under the campaign/runtime rules;
• if rejected and not overturned, no contributor payout is due for that task;
• if audit/arbitration changes the result, settlement follows the finalized PHK result, not the preliminary one.

Operational release policy may impose additional holds or delays after acceptance, but it does not change the canonical PHK outcome.

Validator Incentives

Validators are rewarded for diligence and correctness, not for throughput:

• validator review remains tied to finalized outcomes;
• validator performance compounds through R_valid; and
• repeated disagreement against finalized outcomes can reduce validator reputation and routing readiness.

The broader protocol design includes explicit validator-budget and heldback-reward mechanics. Deployment phases can implement these mechanics in narrower or broader form, but the invariant remains that validator rewards and standing follow finalized outcomes rather than operator preference.

Audits, Bounties, and Slashing Flows (Due Process Only)

Audits are funded from campaign-level reserves in the broader protocol design and run under tier-defined triggers. If an audit overturns an outcome or confirms fraud/negligence, auditors can receive audit rewards and confirmed violators can face penalties.

Slashing applies only after due process:

• contributor slashing requires confirmed misconduct under campaign/network rules;
• validator slashing requires proven collusion or negligent validation patterns; and
• provisional integrity posture alone is not enough to slash.

Network phases can deploy these tools incrementally, but confirmed penalties always require finalized enforcement rather than suspicion alone.

Protocol Fees and Treasury Sustainability

Protocol fees fund security, maintenance, ecosystem incentives, and long-term sustainability. They can be a percent of campaign budget and/or fixed per-task fee. Treasury allocation is governed by the DAO after governance activation.

Dataset Reuse Royalties (HVD Distribution Economics)

For dataset campaigns, initial campaign funding covers artifact creation and delivery. The broader protocol design supports ongoing reuse via distribution revenue splits across:

• contributors whose outputs are included;
• validators/auditors who finalized included outputs;
• curators where applicable; and
• the protocol treasury.

Royalty splits are explicit parameters of the dataset artifact and are committed by hash so consumers can verify attached economics without revealing the underlying content.

Requester Progression and Launch Policy

Implementations may phase requester launch capacity through accepted-output progression, launch credits, tier ceilings, or other operational gating during bootstrap. These controls are deployment policy, not immutable protocol guarantees.

Appendix - Parameter Registry (Genesis Defaults)

This appendix defines the genesis defaults for protocol parameters referenced by campaign specifications and PHK receipts. Parameters are versioned and governance-upgradable. Campaigns commit a reference to the active Parameter Registry version, and its root hash, at creation time so disputes and audits can unambiguously reference the exact parameters in force.

Registry Header

• params_version: genesis_v1
• params_effective_time: [GENESIS_TIMESTAMP]
• params_root_hash: [ROOT_HASH_OF_THIS_TABLE]
• governance updates must publish a new params_version and params_root_hash