Lioth Unified Whitepaper

This page is now treated as an archival unified snapshot placeholder, not the source of truth for current semantics.

The maintained source of truth is split across:

• the chaptered whitepaper in this repository for protocol invariants, trust boundaries, and intended architecture;
• App Status for current live bootstrap/testnet behavior; and
• Protocol Defaults for the current defaults alongside the broader parameter envelope.

The chaptered whitepaper sections are:

• Technical Abstract
• Key Terms
• Architecture
• The Protocol Properties
• The Protocol Layers
• Identity Layer: Uniqueness, Reputation & Economic Incentives
• Protocol Security and Anti-Fraud Mechanisms
• Economic Flows
• Definitions and Glossary

If a future unified export is needed, it should be regenerated from the maintained chaptered sections rather than treated as an independent normative document.

Technical Abstract

Lioth Protocol is a decentralized system for distributing structured tasks to humans, verifying outputs through a declared verification workflow, and delivering finalized results through a unified execution + verification + distribution pipeline. Lioth is designed for environments where provenance and quality assurance matter under adversarial incentives (low-effort work, automation, and AI-assisted submissions), and where participants may require privacy by default. Lioth produces two primary output types:

1. Human Verified Outputs (HVO): finalized task results delivered directly to a requester (e.g. microtasks, evaluations, reviews, extraction, research, QA, preference testing).

2. Human Verified Data (HVD): when tasks are designed for aggregation and reuse, validated outputs can be packaged into standardized dataset artifacts with quality reporting, source hashes, and licensing references.

Verification in Lioth is expressed as Proof of Human Knowledge (PHK): a campaign declares its rubric, tier configuration (quorum, audits, dispute/arbitration options), and assistance policy. Finalization produces a PHK Receipt that proves which rules were applied and what outcome was finalized. PHK does not claim "proof of truth" for subjective tasks; it claims that outputs were produced and reviewed under a declared rubric and tier. PHK also does not guarantee "one human, one account"; it targets bounded-risk outcomes through configuration, audits, and economic enforcement.

This whitepaper defines protocol invariants, trust boundaries, and intended architecture. Current live bootstrap/testnet behavior is documented separately in App Status and may evolve during bootstrap without changing the PHK-only finality model defined here.

Lioth supports privacy by design: contributors are not required to reveal identity to start participating in the protocol.

Cohort and specialization requirements can be satisfied through privacy-preserving credentials (e.g. zero-knowledge proofs of attributes) without deanonymization. Blockchain is used narrowly as a control plane for commitments (campaign specifications), receipts (finalization), and optional enforcement events, while sensitive task content, fraud artifacts, and deliverables remain off-chain.

Reader Paths

For current live bootstrap/testnet behavior, see App Status. The whitepaper below focuses on protocol design, invariants, and intended architecture.

Key Terms

What Verified Means in Lioth (PHK)

This section operationalizes the terms used in the Technical Abstract and defines what PHK verification guarantees, and does not guarantee.

A verified output is:

• Rubric-compliant under a declared campaign specification, as determined by validator quorum rules, audits, and dispute/arbitration (if enabled).
• Auditable as a workflow event, because the campaign specification hash and outcome receipts are committed on-chain or anchored through committed finality artifacts.
• Bounded by the campaign's Assistance Policy, which defines whether AI assistance is allowed/disallowed/allowed-with-disclosure (see PHK specification).

Verified does not:

• Guarantee a "one human, one account" statement.
• Claim perfect detection of AI-assisted work. Where assistance is disallowed, Lioth targets bounded-risk outcomes via tier configuration, audits, integrity gating, and economic enforcement rather than claiming absolute proof.
• Claim outputs are "true" in subjective tasks; it claims they are produced and reviewed under the declared rubric and tier.
• Guarantee that payout release, settlement release, or TGE-sensitive eligibility has already been operationally released. Operational release policy can remain separate from canonical PHK truth.

PHK Design Goal

PHK is designed to make repeated low-effort, policy-violating, or synthetic submissions detectable, economically unattractive, and limited in impact, while enabling honest participants to build durable performance records.

Implementation note: Current live runtime access policy, validator readiness lanes, and bootstrap controls are documented in App Status. These controls affect operational access, not PHK truth authority.

Privacy and Cohort Targeting

Lioth is private by design: contributors are not required to reveal real-world identity. When tasks require specific attributes (e.g., region, expertise), Lioth supports zero-knowledge credentials to prove eligibility without exposing identity.

Use Cases

• Verified microtask and human evaluation workflows.
• Expert and group-restricted campaigns.
• Model evaluation datasets (judgment, preference, critique, safety).
• Forecasting datasets and probabilistic decision intelligence.
• Market research datasets and experiments (ranking, trade-offs, messaging tests).

Introduction

The growing problem is synthetic saturation and low-trust task markets.

Modern economies depend on human signals (judgment, preferences, reasoning, domain expertise) to train and evaluate AI systems, guide decisions under uncertainty, and understand human behavior. As synthetic content scales, it becomes harder to distinguish authentic human-origin information from generated or low-effort outputs. This contamination can reduce diversity, introduce recursive artifacts, and degrade the reliability of both datasets and operational workflows.

In parallel, the global demand for human work delivered through microtasks and online labor markets is increasing. Yet many existing task markets were not designed to resist automation at scale or to provide verifiable provenance and quality guarantees. Requesters frequently face issues such as: bot participation, farmed accounts, inconsistent results, and limited enforcement beyond platform policies.

Why Today’s Solutions Are Insufficient

Scraping pipelines offer scale but limited control and provenance. Centralized task markets can coordinate labor, but often struggle to enforce strong quality standards, prevent Sybil behavior, and provide auditability. Buyers and requesters typically cannot verify how outputs were produced, how quality was enforced, or whether work was generated by models especially in high-volume environments where incentives reward speed over correctness.

These gaps create a structural failure: the highest-value human signals are increasingly expensive to obtain, precisely when they are most needed.

Lioth's approach: a human task verification platform with dataset assembly

Lioth approaches the problem as a coordination and verification challenge. The platform enables third parties ("requesters") to publish tasks to eligible groups of contributors, verify results through multi-layer validation, and assemble outputs into reusable datasets when needed. This makes Lioth a general-purpose task platform, comparable in function to microtask platforms, while adding verifiable quality and incentives at the application level.

Lioth's verification is based on quality tiers with increasing validation quorum requirements, designed to make low-effort contributions economically unattractive over time.

From Task Outputs to Reusable Datasets

Not all tasks need to become datasets. However, when tasks are structured for aggregation, Lioth can assemble validated contributions into Human Verified Data (HVD) datasets. These dataset artifacts include basic quality reporting and anonymized contributor identification, enabling their use across model training, evaluation, research, and decision support.

Privacy and Anonymity

Lioth prioritizes contributor privacy: participants are not required to reveal real-world identity. For tasks requiring specific attributes, eligibility can be enforced through reputation, Account Trust/runtime policy, cohort proofs, or other declared routing rules. Contributors are assigned anonymized worker codes to prevent identity linkage across campaigns.

Lioth's objective is to make human work whether delivered as direct task outputs or reusable datasets verifiable and economically sustainable in a world where synthetic content is abundant.

What Is Decentralized

Lioth decentralizes governance and participation, while keeping high-frequency and content-sensitive computation off-chain. The core decentralized functions of the protocol are:

• Permissionless participation: anyone can participate as a contributor, validator, curator, or consumer subject to protocol-defined eligibility rules (reputation, runtime trust/access policy in testnet, optional staking/bonding where enabled, and campaign-specific cohort requirements).
• Governance (DAO): protocol parameters such as staking/bond requirements, role thresholds, campaign modes, task type standards, validation thresholds, and treasury allocations, are governed through on-chain governance after bootstrap (see Governance & Coordination Layer)
• Auditability: key workflow outcomes are recorded on-chain as commitments and receipts, enabling independent verification of rules applied and finalized outcomes, without publishing sensitive content.

What Is Executed Off-Chain

Task routing, integrity risk scoring, dataset packaging, and delivery are performed by automated software agents (“protocol services”) to keep sensitive content off-chain and avoid high costs. These services do not decide truth, they execute deterministic workflows and emit signed events and receipts.

Why Blockchain

Blockchains provide a shared, tamper-resistant record of:

• Campaign configuration commitments (hashes)
• Finalized outcome receipts (accepted, rejected, audit finality)
• Settlement and payout events
• Pseudonymous reputation and slashing outcomes (when applicable)
• Dataset provenance hashes and licensing references

This enables requesters to verify provenance and enforcement history while allowing contributors to remain pseudonymous.

Lioth doesn’t claim that blockchains prove truth of task outputs by themselves. Instead, the protocol uses blockchains to make the execution and verification workflow auditable and to make enforcement (reputation, eligibility, settlement, and slashing where enabled) predictable and verifiable by a third party.

The Vision

Lioth’s vision is to make human work and human cognition a reliable, verifiable, and composable primitive for the digital economy.

As AI systems increasingly generate content and mediate decisions, the value of authentic human signals judgment under uncertainty, context-aware reasoning, taste, trade-offs, and lived experience becomes harder to obtain and easier to counterfeit. Lioth aims to preserve these signals by providing a protocol where human outputs can be produced at scale while remaining verifiable and economically protected from manipulation.

Lioth is designed to support two complementary outcomes:

1. Verified human task outputs delivered directly to requesters (microtasks, evaluations, reviews, research, moderation, QA, and expert work).

2. Human Verified Data (HVD) datasets packaged from validated outputs when tasks are designed for aggregation and reuse.

By separating task execution, verification, packaging, and distribution, Lioth enables a world where human work is not locked inside centralized platforms and where high-quality human data can be reused across training, evaluation, decision support, and research without forcing contributors to reveal identity.

Main Characteristics of the Protocol

1. General-Purpose Decentralized Task Protocol

Lioth enables requesters to distribute tasks and campaigns to cohorts of contributors and receive verified outputs through the Distribution Layer. This supports microtask workflows and higher-skill tasks without relying on a centralized intermediary for truth finalization.

2. Human Verified Outputs Via PHK

Lioth secures quality through Proof of Human Knowledge (PHK), a composable framework that combines validator review, audits, dispute/arbitration paths where enabled, integrity signals, and economic enforcement. PHK finality remains canonical truth: no Foundation operator, protocol service, or admin control rewrites accepted/rejected outcomes.

3. Datasets Are an Optional Packaging Layer

Lioth can package validated outputs into HVD datasets when tasks are structured for aggregation and reuse. Dataset assembly is optional: many campaigns produce HVOs only. Packaging can produce off-chain artifacts, manifests, and delivery references without making dataset mode mandatory for every campaign.

4. Privacy by Default; Cohort Targeting Without Identity

Contributors are not required to reveal real-world identity. When campaigns require specific attributes (region, expertise, role), participants can prove eligibility with zero-knowledge credentials, enabling cohort selection without deanonymization.

5. Defense-In-Depth Integrity Restrictions

Lioth uses multiple independent signals to deter automation and manipulation: task constraints, throughput controls, validator review, audits, clustering/integrity signals, and economic penalties after due process where enabled. Integrity restrictions can reduce routing or validator availability in some implementations, but they are not, by themselves, canonical proof of fraud or collusion.

6. Reputation and Operational Access Can Be Distinct

Lioth keeps protocol performance tracks and runtime access controls separate. Reputation tracks (R_work, R_valid) summarize finalized performance. Bootstrap or testnet implementations may layer a separate operational access score, such as Account Trust, on top of those tracks for caps, validator readiness, launch access, settlement timing, or reward shaping. This keeps protocol truth and runtime access semantics distinct.

7. Bootstrap Validator Availability Without Bootstrap Truth Authority

Bootstrap or testnet deployments may distinguish:

• policy eligibility under the active access rules;
• bootstrap approval, where used, to expand validator supply during cold start; and
• effective runtime readiness after account, safety, and integrity restrictions are all considered.

Bootstrap approval expands validator participation during bootstrap. It does not let an operator decide canonical outcomes.

8. Scalable and Cost-Efficient On-Chain/Off-Chain Separation

Lioth keeps content-heavy and sensitive data off-chain, while storing only critical commitments and receipts on-chain (validation results, finality receipts, provenance hashes, licensing references, and optional enforcement artifacts). This preserves privacy and enables throughput at scale.

9. Auditability and Transparent Quality

Validation rules are explicit. Campaign-level reports can summarize agreement, rejection, audit, duplication, and delivery metrics. Manual bootstrap or safety actions, when present, must be audited so operator intervention is visible without being confused for PHK truth.

10. Flexible Distribution Modes

The Distribution Layer supports multiple delivery paths: public distribution, private enterprise delivery, subscription feeds, and direct API/integration delivery. Lioth does not require outputs to be traded in a marketplace to be useful. Implementations can expose completion and delivery readiness as explicit states rather than treating acceptance alone as sufficient delivery.

11. Long-Term Incentives and Compounding Rewards

Participants are rewarded for quality and durability. Finalized outcomes compound reputation, bootstrap/testnet implementations may layer additional operational access policy on top, and contributors may earn future reuse value when packaged datasets are licensed over time. Bond-heavy participation can be enabled by later governance-controlled phases without changing the PHK trust boundary.

Architecture

The Agents of the System

The protocol coordinates multiple agents and entities, both human and automated, to produce HVOs and HVD datasets.

Requester

A third party (corporation, individual, or AI agent acting for a principal) that funds and specifies work. It creates task or dataset campaigns and receives outputs via the Distribution Layer. It defines schema, acceptance criteria, cohort requirements, privacy mode, quality tier, budget, target accepted outputs, and delivery mode.

Contributor

Humans that resolve tasks, prompts, and questions to generate requested work or datasets. Contributors provide the underlying human judgment, knowledge, preference, or analysis that the protocol is designed to verify.

Validator

Validators review contributor outputs under the declared rubric. They produce the approve/reject decisions that feed PHK finality, and may participate in audits, escalations, or arbitration where enabled. Validators can surface suspicious patterns or integrity concerns, but they do not become truth authorities outside PHK.

Curators

Curators gather knowledge, detect reusable patterns, and generate dataset formats, task specs, or rubrics. They can create reusable templates, task/dataset designs, and recurring structures for protocol demand.

Arbitrator

A specialized validator quorum for disputes and high-risk cases. They handle escalations, disagreement, and dispute resolution where the campaign enables arbitration, and they produce the final arbitration decision state that PHK references.

The Protocol Foundation

The Lioth Protocol Foundation is focused on infrastructure, open-source coordination, and public participation. Its core responsibilities are:

• Maintaining core infrastructure (web app, APIs, SDKs, tooling).
• Coordinating open-source development and security review.
• Managing documentation, research, and public communications.
• Supporting ecosystem growth, partnerships, and integrations.
• Operating reference endpoints and services during bootstrap/testnet, when needed to accelerate growth and keep the network usable.

Bootstrap Authority (Time-Bound)

During bootstrap and testnet, the Foundation may publish initial defaults, operate reference infrastructure, and use audited operational controls required to keep the network usable while participation is still bootstrapping.

Implementation note: Current live bootstrap controls are documented in App Status.

Post-Bootstrap/Testnet

After the protocol transitions to governance, parameter authority moves to the Lioth DAO. The Foundation remains an implementer and coordinator, maintaining reference clients, documentation, research, and ecosystem support.

Non-Interference Guarantee

The Foundation does not participate in data generation and does not control individual task outcomes. It may operate reference infrastructure and publish defaults, but canonical accepted/rejected truth is still produced only by PHK. Bootstrap/testnet operational controls, when present, remain separate from PHK finality and do not rewrite canonical outcomes.

Transition to governance occurs when DAO activation criteria are met after testnet and minimum readiness thresholds are satisfied.

Automated Agents and Protocol Services

The protocol uses off-chain automated software agents to run high-frequency workflows such as routing, integrity scoring, packaging, and delivery while keeping sensitive content and heavy computation off-chain. These agents do not make discretionary human decisions about task truth. Final outcomes are determined by validator review, audits, dispute/arbitration rules, and PHK finality. Protocol services are mandatory workflow functions but are not intended to be a single hosted backend. They can be operated as:

• reference services maintained by the Foundation during bootstrap/testnet; or
• independent Protocol Service Operators (PSOs) running spec-compliant implementations.

PSO Selection, Redundancy and Failover (Normative)

Protocol Service Operators (PSOs) provide spec-compliant implementations of mandatory off-chain services such as orchestration, integrity checks, packaging, and delivery. PSOs do not decide truth outcomes. They provide availability, performance, and interoperability under published rules.

PSO Registry and Discovery

The protocol maintains, on-chain or via verifiable registry commitment, a registry of PSOs including:

• PSO identity (public key) and service types offered;
• supported service specification hashes;
• supported Parameter Registry versions and optional stake/bond if enabled; and
• off-chain endpoint descriptors.

A PSO must emit signed service events that reference the campaign configuration hash and relevant service spec hashes so outputs remain auditable across operators.

Selection Modes

Each campaign declares a Service Policy defining how PSOs are selected for each service type:

• Requester-selected PSOs (default): the requester chooses a primary PSO and one or more backups per service type.
• Protocol-selected PSOs (optional): PSOs are selected deterministically from the eligible PSO set based on published policy, operator eligibility, and verifiable randomness where required.
• Enterprise-hosted mode (confidential/enterprise): the requester or enterprise provides controlled execution environments. The protocol still produces receipts and settlement while service execution occurs inside enterprise infrastructure.

Failover and Reassignment

If a PSO fails to respond within a tier-defined timeout, the client or protocol switches to the next eligible backup PSO, or deterministically reselects from the eligible PSO set under campaign Service Policy. Failover must be recorded as a signed service event referencing the old PSO, new PSO, and workflow identifiers.

Redundancy Requirements

For delivery/storage-sensitive workflows, campaigns may require redundancy:

• encrypted objects (payloads, bundles, manifests) are replicated across multiple PSOs;
• replication factor is tier-defined; and
• delivery receipts reference the artifact/manifest hash so integrity can be checked independently of which PSO served delivery.

This does not claim perfect censorship resistance of off-chain services. It provides auditability, deterministic switching rules, and redundancy under committed parameters.

Task Orchestrator

An automated routing agent with the following tasks:

• validates campaign configuration (eligibility rules, cohort proofs, rate limits, tier configuration);
• assigns tasks to eligible contributors;
• assigns submissions to validators under the current routing policy; and
• emits signed routing events and, where used, references to randomness proofs.

The task orchestrator cannot accept or reject outputs. It only routes work under published rules.

Validation Guard

An automated integrity service that computes fraud and integrity signals (e.g. similarity/duplication indicators, anomaly patterns, timing outliers, or rubric-compliance checks where deterministic). It produces flags, confidence scores, and operational posture for validators and operators. The Validation Guard does not finalize outcomes and is not a source of truth by itself.

Its integrity posture can contribute to routing restrictions, readiness limits, or increased audit pressure, but these remain operational restrictions rather than confirmed fraud findings.

Dataset Assembler

An automated packaging agent that transforms validated outputs into dataset artifacts when a campaign is in dataset mode. It normalizes and formats outputs, enforces schema and versioning, computes dataset-level QA summaries defined by the campaign, and produces:

• a dataset artifact;
• a manifest with counts, provenance references, and hashes; and
• delivery/receipt metadata for requester-facing completion.

Distribution Gateway

An automated delivery agent that manages encryption, access control, entitlement checks for private delivery, subscriptions, delivery logging and receipts, and integration delivery (APIs, feeds) when enabled. The Distribution Gateway delivers outputs but does not change PHK verification outcomes or override validator finality.

Distribution Gateway behavior is constrained by a service specification referenced by hash. Protocol Service Operators emit signed service events, such as delivery receipts, that reference the campaign configuration hash, relevant service spec hashes, and associated workflow identifiers. This allows multiple PSOs to provide delivery services while remaining verifiable and interoperable under the same protocol rules.

Protocol Service Operators and Spec Compliance

Protocol services are constrained by service specifications referenced by hash. PSOs emit signed service events that reference:

• the campaign configuration hash;
• relevant service spec hashes; and
• associated workflow identifiers (tasks, outputs, bundles).

The Protocol Properties

This section defines properties that MUST remain true across implementations, operators, and upgrades. These are intended to prevent ambiguity in trust boundaries and to keep decentralization claims auditable.

• Campaign immutability (per campaign): Once a campaign is created, its configuration is immutable for that campaign: rubric, schema, tier parameters, assistance policy, dispute/arbitration configuration, delivery configuration, service policy, and the referenced Parameter Registry version are committed by hash. Any change requires a new campaign, or a new campaign version explicitly linked to the prior one.
• Finality is produced only by PHK: No protocol service operator, Foundation component, or off-chain agent can finalize outputs. Final outcomes are produced only by PHK rules: validator quorum thresholds, audits, and dispute/arbitration resolution where enabled.
• Any penalties or slashing apply only after PHK finality: Any penalties or slashing apply only after PHK finality.
• Protocol services are constrained executors, not authorities: Task Orchestrator, Validation Guard, Dataset Assembler, and Distribution Gateway are automated off-chain services that execute deterministic workflows. They emit signed service events and receipts referencing campaign/spec hashes. These events support auditability but do not override PHK finality.
• Operational safety overlays are separate from protocol truth: A runtime/operator layer may hold settlement, freeze payout release, quarantine entities, or exclude TGE-sensitive eligibility, but these actions do not mutate canonical accepted/rejected PHK truth.
• Minimal on-chain commitments; sensitive content stays off-chain: On-chain data is limited to commitments, receipts, and references required for auditability and settlement (e.g. campaign config hashes, finality receipts, settlement receipts, provenance hashes, licensing commitments). Prompts, attachments, raw outputs, bundles, manifests, fraud-signal artifacts, and keys remain off-chain. Confidential tiers restrict metadata exposure and verification signals accordingly.
• Governance changes must be explicit, versioned, and time-delayed: Protocol parameter changes and service spec updates must be executed through governance against canonical registries (Parameter Registry and Spec Registry). Changes are versioned and subject to governance timelocks. Campaigns remain auditable by referencing the exact registry version in force at creation time.
• Participation is permissionless; access is rule-based: Participation (contributor/validator/curator roles) is permissionless. Eligibility, caps, and routing priority are determined by transparent, committed rules appropriate to the network phase (tier requirements, reputation, operational access policy, optional bonds where enabled). No single party may rewrite PHK truth by arbitrarily overriding those rules.
• Off-chain routing is auditable; censorship-resistance is bounded: Lioth does not claim perfect censorship resistance for off-chain routing. It provides auditability and enforceable constraints: deterministic selection from eligible sets where required, pairing limits, timeouts, signed failover events, and explicit operator-assignment logs when audited bootstrap actions are used.
• Integrity posture is provisional unless finalized: Cluster confidence, anomaly scores, similarity flags, and other risk signals can drive audits or operational restrictions, but they are not canonical proof of fraud or collusion on their own.
• "Verified" is bounded-risk and policy-scoped: "Verified" means "verified under declared rules with auditable receipts," not "absolute proof of human-only origin" or "objective truth." Where assistance is disallowed, the system aims to bound SAR via tier configuration, audits, integrity controls, and economic enforcement, and reports results through PHK Tier Reports.

The Protocol Layers

Lioth is built as a layered protocol. This structure supports multiple outcome types with the same core workflow: direct human work and optional packaging of validated outputs into HVD datasets. This separation also makes on-chain and off-chain boundaries explicit. While content and computation remain off-chain for privacy and scalability, final outcomes, finality receipts, and delivery references are recorded as auditable artifacts.

Demand and Design Layer

This layer converts demand into structured, executable specifications. It is where requesters and curators define what work needs to be produced, under what rules, and how quality is measured.

For HVO campaigns, the specification includes task schema, validation criteria, privacy mode, cohort target, quality tier, target accepted outputs, delivery mode, and budget semantics.

For HVD dataset campaigns, the specification additionally includes aggregation requirements such as sample size, dataset format, versioning rules, manifest requirements, dataset metrics, and licensing constraints.

Detailed contents such as full prompts, attachments, and procedures are maintained off-chain because they can be sensitive and large. On-chain, the protocol commits only non-sensitive identifiers and hashes so participants can verify source of data, licensing references, and rule versions.

Task Orchestration Layer

This layer turns specifications into active task flows. It routes tasks to eligible contributors, enforces rule-based access, and provides anti-collusion and anti-abuse controls at the assignment stage.

Eligibility and routing can also rely on cohort proofs, campaign-specific constraints, optional stake requirements where enabled, and privacy-preserving credentials.

Implementation note: Current live runtime access policy, validator readiness lanes, integrity restrictions, and audited assignment overrides are documented in App Status. These controls affect routing and availability, not PHK truth.

Verifiable Assignment and Anti-Collusion Constraints

• Task routing and validator selection must be auditable from:

  • the campaign configuration hash;
  • the eligible set, or an eligible set commitment;
  • the routing policy active for the network phase; and
  • any signed assignment or reassignment events.

• For tiers or phases that require it, assignments use a verifiable randomness source (VRF or equivalent). The protocol records enough reference material for third parties to verify that selection was not manually steered.

• Deterministic selection, when required, chooses contributor assignment and validator quorum from the eligible set under committed inputs.

• Assignment algorithms must enforce anti-collusion constraints such as:

  • limits on repeated contributor-validator pairings within a time window;
  • prevention of repeated same-quorum validation clusters; and
  • exclusion or downgrade of validators with disqualifying conflicts, safety restrictions, or workspace-level integrity posture.

• Timeout and reassignment: if a validator does not respond within the configured timeout, the task can be reassigned and the reassignment must be recorded as an auditable workflow event.

• Audited routing overrides, when present during bootstrap/testnet, must be explicitly logged and cannot alter canonical PHK truth.

Orchestration is implemented off-chain because it is high-frequency and latency-sensitive. On-chain state reflects only the status changes and receipts that matter for auditability and settlement.

Execution Layer

Human work happens in the execution layer. Contributors receive tasks, complete them under the declared rules, and submit structured outputs. The protocol is designed to support both microtasks and high-skill tasks, so execution constraints are configurable.

The execution layer also supports protocol-level integrity checks embedded into task design. These may include consistency tasks, micro-checks, calibration tasks, and other mechanisms. This is not intended to prove humanity in isolation, but to provide signals that improve verification, raise the cost of automation and low-effort submissions, and support bounded-risk outcomes.

All task content and raw outputs remain off-chain, ensuring privacy, reducing costs, and enabling compliance handling where necessary.

Verification Layer (PHK)

The verification layer is the core security engine of the protocol. It enforces Proof of Human Knowledge (PHK), a framework that combines validator review, anomaly signals, audits, and due-process escalation paths where enabled.

Verification Layer Specifications

1. PHK Inputs

Each contribution is evaluated under a campaign configuration committed by hash, including:

• validation rubric;
• quality tier configuration (validator quorum size, threshold, audit policy);
• dispute/arbitration configuration where enabled;
• privacy mode;
• assistance policy; and
• the referenced parameter and service policy versions.

2. Quality Tiers

Quality tiers are standardized verification presets that define verification strength and operational expectations. A tier specifies:

• validator quorum size and consensus threshold;
• audit policy (random sampling rate and trigger rules);
• dispute/arbitration availability and deposits where enabled;
• settlement finality rules and delays;
• privacy constraints and allowed verification signals; and
• exposure limits or routing constraints for low-trust or high-risk identities where implemented.

Campaigns must declare a tier preset, or explicitly declare a custom tier configuration, so verification strength, expected cost, and expected latency are transparent and comparable across campaigns. Campaigns commit the exact tier parameters by hash at creation time.

Implementation note: Current live tier availability and defaults are documented in App Status and Protocol Defaults.

3. PHK Outcome Types

A contribution resolves to one of these finalized states:

• Accepted
• Rejected
• Accepted after audit
• Rejected after audit
• Arbitrated

Finality occurs only after the applicable audit/dispute/arbitration path closes under the campaign's rules.

4. PHK Decision Process

1. Assignment: a submission is assigned to one or more validators under the routing policy active for the campaign/network phase.
2. Validator review: validators apply the rubric and produce approve/reject decisions and optional structured rationale fields.
3. Consensus: the protocol applies the campaign's consensus threshold rules.
4. Audit triggers: audits may be random, disagreement-triggered, risk-triggered, or requester-dispute-triggered where enabled.
5. Finality: after audit/dispute/arbitration resolution, an outcome is finalized and becomes the canonical input for protocol truth, receipts, reputation, and metrics.
6. Commit-reveal voting: for tiers that enable it, validator decisions may use a commit-reveal mechanism to reduce bribery, influence, and herding.

5. PHK Security Targets and Measurable Metrics

PHK is defined by measurable metrics that are reported per campaign and per tier.

Core PHK metrics:

• Agreement Rate (AGR): expected validator agreement under the rubric.
• Audit Overturn Rate: fraction of initially accepted outputs that are overturned by audits/arbitration.
• Rejection Rate: fraction of submissions rejected under the tier's rules.
• Time to Finality: distribution of time from submission to finalized state.
• Integrity / Duplication Rate (IDR): near-duplicate rate within the campaign.
• Assistance-policy metrics where assistance is disallowed, including SAR estimates.

PHK metrics are computed from finalized outcomes. Operational overlays, when present, may be reported separately, but they do not redefine PHK quality metrics.

PHK Tier Report System

To make verification measurable and comparable across campaigns, the protocol defines a standard PHK Tier Report. Reports are computed off-chain because content may be sensitive and may be shared publicly in aggregated form depending on campaign privacy mode. A campaign's PHK Tier Report MUST reference the campaign configuration hash and the active Parameter Registry version.

Required report fields:

• campaign identifier and configuration hash;
• tier identifier and parameter snapshot (quorum, thresholds, audit and dispute settings);
• submission volume and finalized accepted/rejected counts;
• AGR distribution and median;
• Audit Overturn Rate overall and by trigger type;
• rejection rate overall;
• Time to Finality distribution;
• IDR where applicable; and
• SAR estimate and method flags when assistance is disallowed.

Operational/testnet overlays such as held settlement, frozen payout, or TGE exclusion should be labeled separately as operational counts rather than PHK-quality counts.

6. Assistance Policy (AI Tooling Policy)

Each campaign declares an assistance policy:

• Allowed: AI assistance is permitted. PHK verifies rubric compliance and workflow finality, not human-only origin.
• Allowed with disclosure: assistance is permitted, but contributors must disclose assistance usage in a structured field. False disclosure may be penalized if proven via audit/arbitration under campaign rules.
• Disallowed: AI-assisted or automated submissions are not permitted. The protocol uses defense-in-depth (tier configuration, audits, integrity signals, and economic enforcement) to reduce and bound violations.

Detection signals are risk indicators, not standalone proof.

7. Cost and Latency Transparency

Verification strength increases cost and latency. For transparency, each tier may provide expected ranges for:

• expected verification cost multiplier;
• expected median time-to-finality; and
• expected audit overhead share.

8. Disputes, Arbitration and Slashing (Due Process)

PHK finality is designed to be enforceable without relying on provisional signals. Penalties, including slashing where enabled, may be applied only after a defined due-process path completes.

Campaigns may enable a dispute path depending on tier and campaign mode.

• HVO mode: disputes operate at the individual output level.
• HVD dataset mode: disputes typically operate at the sample or batch level and are resolved by statistical quality guarantees and schema compliance rather than requester preference alone.

A dispute must reference the campaign configuration hash, the task/output identifier(s), and the specific acceptance criteria or rubric clause claimed to be violated.

9. PHK Receipt (Workflow Proof)

For each finalized output, the protocol produces a PHK Receipt that includes:

• campaign identifier and campaign configuration hash;
• task identifier and task spec/version hash where applicable;
• quality tier identifier and tier parameters used;
• finalized outcome state;
• quorum summary;
• agreement-strength summary used for reputation scoring, and whether the outcome was audited/arbitrated;
• audit/arbitration flags and finality reference where applicable;
• optional randomness references when used;
• optional delivered artifact reference when enabled for delivery integrity; and
• timestamps and receipt signature.

A commitment to the PHK Receipt is anchored on-chain to enable independent auditability without revealing sensitive content.

Preparation Layer

This layer handles formatting, encryption, bundling, and delivery preparation after PHK finality. It packages finalized outputs into the requester's required format and can produce delivery artifacts, manifests, and delivery receipt metadata once completion rules are satisfied. Payloads remain off-chain even when their hashes or receipt references are anchored for auditability.

Distribution Layer

The distribution layer delivers both categories of output: HVOs and HVD datasets. They may be delivered through private channels, subscriptions, public listings, and direct integrations.

It uses end-to-end encryption, supports confidentiality modes that restrict metadata exposure, and reduces leakage risk through campaign-scoped access control, minimized delivery metadata, and optional watermarking where enabled by the campaign.

For datasets, the distribution layer also enforces licensing posture and maintains requester-facing manifest and receipt metadata. Licensing records and usage rights may be recorded on-chain as verifiable references while content remains off-chain.

Access control, encryption, storage, and delivery happen off-chain.

For HVOs, the distribution layer focuses on secure delivery, entitlement checks, and explicit delivery completion rather than assuming that acceptance alone equals delivery.

How Licensing Enforcement Works

Enforcing licensing means enforcing access and delivery conditions against a committed rights configuration. The Distribution Layer performs:

• entitlement checks to verify the recipient is allowed to access the artifact under the campaign's delivery configuration;
• key release / encryption control so decryption material is released only to entitled parties;
• license-bound delivery with logged delivery receipts; and
• traceability linking the delivered artifact to the relevant artifact hash and license reference.

The protocol records only the licensing commitment references and relevant integrity hashes on-chain to keep content and buyer metadata off-chain.

Warning: the protocol can restrict access and make terms auditable, but it cannot prevent off-platform copying after a buyer legitimately receives a dataset. For high-risk cases, campaigns should use confidentiality mode, watermarking, or contractual enforcement outside the protocol.

Governance and Coordination Layer

Lioth governance controls the evolution of protocol parameters without controlling individual content outcomes.

During bootstrap and testnet, the Foundation coordinates protocol iteration, publishes initial parameter defaults, and may use audited operational controls needed to keep the network usable. None of these controls permit the Foundation to rewrite PHK outcomes. Current live bootstrap behavior is documented in App Status.

Mainnet Governance (DAO)

After bootstrap, the Lioth DAO governs protocol parameters and treasury allocations through on-chain governance, covering:

• staking/bonding parameter changes;
• role and validator eligibility thresholds;
• campaign modes and standard fields;
• validation tier configuration defaults;
• dispute/arbitration rules and incentives; and
• treasury allocations and ecosystem grants.

Off-chain coordination supports proposal discussion, analysis, audits, votes, and implementation, while approved changes are reflected on-chain.

Parameter Registry

A registry contract stores the active parameter set that all spec-compliant clients and Protocol Service Operators must reference. This includes:

• role eligibility defaults and optional stake requirements where enabled;
• campaign mode templates and required fields;
• validation tier defaults;
• dispute/arbitration defaults; and
• treasury policy parameters.

Parameters are versioned and update only through governance execution, so no single party, including the Foundation, can silently change protocol rules after governance activation.

Spec Registry

Protocol services are constrained by versioned service specifications referenced by hash. The Spec Registry keeps:

• approved spec hashes per service type;
• optional compatibility windows; and
• deprecation markers.

PSOs emit signed service events that reference the campaign configuration hash and the service spec hash they executed. This allows multiple independent PSOs to run the workflow while remaining verifiably spec-compliant.

Emergency Controls

During early mainnet, an Emergency Pause mechanism may exist to handle critical vulnerabilities. This is a bounded safety valve:

• Objective: pause new campaign creation or routing, and optionally settlement execution.
• Limitation: it cannot seize funds, rewrite outcomes, or override PHK finality.
• Transparency: every pause emits an on-chain event with a reason code and public incident reference.
• Duration: pauses are time-bounded and automatically expire unless renewed through governance.

On-Chain and Off-Chain Boundaries

The protocol's principle is that on-chain states should only contain what is necessary for finality, auditability, and settlement. Everything content-heavy or sensitive remains off-chain. This ensures Lioth's scalability while preserving privacy and enabling verifiable trust.

• On-chain: campaign/specification commitment hashes, finalized outcome receipts, settlement receipts, reputation updates and slashing events where applied, dataset artifact hashes and licensing references, optional randomness references.
• Off-chain: prompts, raw outputs, embeddings and fraud-signal artifacts, QA report details, manifests and payload bodies, encrypted delivery payloads, storage, and key management.

Task Routing and Lifecycle

Each campaign declares a quality tier that defines validator quorum size, audit policy, dispute/arbitration settings where enabled, finality rules, and privacy constraints. Tiers determine verification strength and cost/latency tradeoffs and are committed by hash at campaign creation time. The protocol routes work through a standardized lifecycle that applies to both direct deliverable jobs and dataset packaging:

1. Campaign creation and target accepted outputs

   A requester initiates a campaign with a committed specification that defines task schema, acceptance criteria, cohort target, privacy mode, quality tier, target accepted outputs where applicable, delivery mode, and settlement rules.

2. Task generation and task pool

   The campaign specification is normalized into protocol-standard tasks. Required fields, response formats, and campaign constraints are enforced before tasks enter the assignment pool.

3. Eligibility checks and contributor routing

   The orchestration layer assigns tasks to eligible contributors based on the active access policy, caps, cohort constraints, and campaign rules. Routing resists abuse with throughput limits, repeated-pairing constraints, and integrity posture.

4. Execution and submission

   Contributors complete tasks and submit outputs in the required schema. Task content and raw outputs remain off-chain.

5. Validator assignment

   Submissions are assigned to validators under the active routing policy, which may distinguish policy eligibility, bootstrap availability, and effective runtime readiness depending on network phase. Any bootstrap/testnet assignment override must be audited and cannot alter PHK truth.

6. Validator review and PHK finality

   Validators apply the campaign rubric and produce approve/reject decisions. Humans remain the source of PHK decisions. Integrity signals, cluster posture, or operator actions may affect routing/audit pressure, but they do not insert canonical approve/reject truth.

7. Safety overlay intervention, where needed

   After or around PHK finality, operational release controls may hold settlement, freeze payout, quarantine entities, or restrict eligibility through a separate safety layer. These actions affect release policy, not PHK truth.

8. Packaging and delivery

   After completion rules are satisfied, finalized outputs are packaged into requester-facing deliverables. Dataset mode produces an artifact, manifest, and delivery receipt metadata. Direct deliverables similarly have explicit delivery readiness and receipt semantics rather than an implicit handoff.

9. Settlement and progression

   Settlement releases or holds value according to PHK finality plus any separate operational release policy. Reputation and trust updates are grounded in finalized outcomes. Current live requester progression policy, where applicable during bootstrap, is documented in App Status.

Types of Tasks

Lioth is designed as a general-purpose protocol for distributing tasks to humans and verifying outputs through Proof of Human Knowledge. The protocol supports a wide range of task formats, from high volume microtasks to expert workflows and longitudinal research. Task types are grouped below by the kind of human signal they produce and the typical validation requirements.

Research and Survey Tasks

These tasks collect structured answers from contributors, typically as multiple-choice, rating scales, or short-written responses. Common requester needs include measuring attitudes, gathering demographic breakdowns, testing messaging, or collecting user feedback. The output may include a JSON row per participant with fields such as answers, timing metadata, and optional free-text rationale. Validation focuses on completion integrity, attention checks, and anomaly signals.

Interactive Study and Experiments

These tasks measure behavior in a framed environment, such as a web experiment, a prototype test, or a stimulus-response workflow. Execution may happen in an external study environment, while Lioth handles eligibility, verification receipts, and settlement.

Requesters look for reaction-based experiments, choice modeling, memory or perception tests, and controlled behavioral tasks. Outputs may be structured logs and experiment results mapped into a standard schema, and a protocol receipt indicating completion and verification strength.

Validation looks for protocol compliance, attention checks, session integrity, and patterns across participants.

Human Rating, Comparison, and Preference Tasks

The requester looks for human judgement at scale, and provides items to compare or evaluate so contributors score them using a rubric. Some concrete examples could be:

• A contributor ranks five product descriptions by clarity.
• A contributor compares two model answers and selects the better one.
• A contributor scores a response on correctness, helpfulness, and safety from 1 to 5, with a short justification.

The outputs include scores, ranked lists, chosen options, and optional justifications, and validation looks for agreement rates and audit rates that can be quantified and reported.

Labeling and Categorization Tasks

These tasks convert content into labels. They are often used for training data, search quality, and analytics. Examples:

• Assign a category to a support ticket.
• Label whether a comment is abusive, hateful, or benign.
• Mark which search result is more relevant.
• Extract entities such as company names, locations, or product types into fields.

Outputs include discrete labels, multi-label tags, and structured extracted fields.

Validation uses rubric review, gold-task calibration, and consensus thresholds to reduce noise.

Data Extraction and Verification Microtasks

These tasks produce structured information from messy sources, or verify that information is correct. Examples:

• Read a webpage snippet and extract price, brand, and model into fields Verify whether an address format is valid without storing the full address on-chain Check whether two records refer to the same entity (deduplication)
• Validate that a claim is supported within the provided context.

Common outputs include structured fields, boolean checks, and confidence values.

Validation focuses on consistency, duplication detection, and audit sampling for high-impact fields.

Content Moderation and Policy Review

These tasks apply a policy rubric to content that can be used for safety labeling, compliance screening, or platform governance workflows. Examples:

• Decide whether a post violates policy and select the violation category.
• Rate severity and recommend an action.
• Identify whether content contains disallowed personal data.

Outputs include label decisions and a rubric-based rationale, and validation could require higher tiers due to subjectivity and adversarial pressure.

UX Testing and Qualitative Feedback

These collect user feedback on interfaces, flows, or prototypes. They can include structured ratings, feedback, or step-by-step usability traces. Examples:

• Navigate a prototype and report where you get stuck.
• Complete a checkout flow and rate trust, clarity, and friction.
• Answer a short set of questions after using a feature.

Outputs often may include ratings, structured issue reports, and optional media files depending on privacy mode.

Validation focuses on completion proof and rubric compliance.

Research, Synthesis, and Expert Jobs

These are longer tasks where a requester wants a coherent deliverable rather than a single label, often involving multi-step reasoning and higher skill. Examples:

• Produce a structured research brief comparing three vendors with cited sources provided by the requester.
• Write a step-by-step operating procedure for a workflow.
• Perform expert adjudication on borderline moderation cases.

Typical outputs include structured documents, decision logs, and evidence fields.

Validation requires using milestone-based reviews, higher validator quorum, and arbitration support.

Forecasting and Scenario Tasks

These tasks produce probabilistic judgements about future events with rationale. Examples:

• Assign a probability to a statement resolving within 3 months and justify the decision.
• Provide a scenario tree with likelihood weights.
• Update probabilities after new information is provided.

Outputs may include probabilities, confidence intervals and rationale fields.

Validation focuses on calibration, consistency over time and audit review for outliers.

Longitudinal and Recursive Tasks

These tasks repeat over time with the same participants or cohort. They are used for diary studies, recurring evaluation, or follow-up experiments. Concrete examples:

• Weekly product usage diary entries.

• Repeated preference evaluations over multiple model versions.

• Follow-up interviews after an initial survey.

Other Tasks

The protocol can adapt to other types of tasks driven by demand of requesters. This ensures to be in the front line of the market’s needs, focusing on adaptability and adoption. It supports tasks where the output is a choice, a score, a label, a structured form, short or long explanations, verified by multi-validator consensus and audits.

Task Structure

The protocol standardizes tasks into consistent structure so they can be routed, executed, verified, and optionally packaged into datasets. Every task shares a core structure that remains stable across task types. Some tasks may have extended fields without breaking interoperability. The standardization has three goals:

• Enables orchestration and verification across campaigns.
• It makes outputs easier to aggregate into datasets when required.
• It allows the protocol to produce verifiable receipts (outcome, validation strength, and proof of source), without storing sensitive content on-chain.

Core Task Fields

Task ID

It’s a unique identifier for the task instance.

Campaign ID

Identifier linking the task to a campaign.

Main Prompt

The prompt shown to contributors, specifying the work that must be done. Prompts may reference attachments.

Response Schema

Description of required output fields and types. This enables validation and consistent packaging. Supported types include text fields, numbers, choices, and structured JSON.

Validator Rubric

Validation criteria used by validators, including acceptance and rejection guidelines.

Task Specific Fields

Tasks can include extended fields that depend on the task type or campaign mode. They add additional structure, and don’t overwrite or redefine core fields. Common extended fields include:

Acceptance Criteria (Requester-Facing)

A structured description of what “done” means. For direct deliverable campaigns, this can include objective requirements and rubric-based subjective requirements. For dataset campaigns, acceptance criteria often emphasize consistency, formatting, and schema adherence rather than requester preference.

Cohort Requirements

Rules defining who is eligible to complete the task, expressed as reputation requirements, Account Trust/runtime policy, allowlists, or zero-knowledge attribute proofs.

Privacy Mode

Flags controlling confidentiality constraints such as restricted prompt visibility, redaction requirements, and whether optional external analysis steps are permitted.

Quality Tier

A configuration object that defines validator quorum size, consensus threshold, audit rate, escalation triggers, and dispute availability. This allows the requester to trade off cost, latency, and verification strength.

Assistance Policy

A campaign-declared policy describing whether AI assistance is allowed, allowed only with disclosure, or disallowed for submissions. The policy determines which verification signals may be used, how audits interpret suspected automation, and what penalties can apply for violations after final resolution.

Attachments and Stimuli References

Pointers to off-chain materials (images, documents, audio, prototype links). These are referenced rather than embedded into on-chain data.

Recontact and Longitudinal Fields

Identifiers that allow repeated tasks over time under the same campaign rules, without requiring identity disclosure.

Payment and Settlement Parameters

Per-task payout, bonus rules, and milestone structure. These belong primarily at the campaign level but can be overridden for specific tasks when needed.

On-Chain and Off-Chain Placement

Stored On-Chain Stored Off-Chain

Operational release controls, when present, are kept as auditable records separate from canonical PHK finality.

Campaign Structure

The work in the platform is organized in campaigns. It is the operational unit that defines rules, budget, eligibility, and delivery requirements for a set of tasks. Campaigns support HVO campaigns (direct outputs) and HVD dataset campaigns (aggregated datasets). Both use the same routing and validation workflow.

The core campaign fields currently supported are:

Campaign ID

Unique campaign identifier.

Campaign Mode

HVO or HVD Dataset mode. This determines whether outputs are delivered as individual task results or assembled into a dataset artifact.

Requester ID

Identity of the requester funding and receiving outputs.

Title and Summary

A short human-readable description of the campaign’s goal.

Task Template Reference

Reference to the task template(s) used in the campaign. Campaigns may use one template or a small set of templates.

Cohort Requirements

Eligibility rules for contributors, currently based on reputation state, Account Trust/runtime policy, cohort requirements, and quality-tier constraints. Future versions may support additional eligibility mechanisms.

Quality Tier Configuration

Defines verification strength through validator quorum requirements (Q0-Q3 tiers). Additional verification features are planned for future development.

Acceptance Criteria

What constitutes an acceptable output, currently based on validator consensus. For dataset campaigns, this includes basic quality metrics.

Privacy Mode

Defines confidentiality rules. Currently supports standard, restricted, and confidential modes as configuration options. Full enforcement is planned for future development.

Budget and Economics

Total budget and payout rules. Currently supports basic budget allocation with planned economic features for future development.

Dispute and Arbitration Configuration

Defines whether disputes and arbitration are enabled. These features are configured but not yet implemented in the current platform.

Timeline and Termination Rules

Campaign completion conditions. Additional timeline controls are planned for future development.

Delivery Configuration

How outputs are delivered. Currently supports private delivery to requesters. Additional delivery modes are planned for future development.

Service Policy

Defines service operator selection and redundancy. This is a planned feature for future decentralized service infrastructure.

Assistance Policy

Policy governing AI/tool assistance. Currently configurable but enforcement is planned for future development.

Protocol Roadmap: The sections below describe planned dataset licensing and versioning features. On-chain licensing records, cryptographic hash commitments, royalty policies, and distribution-layer access control are not yet active in the current platform. They are documented here to define the target protocol architecture.

Dataset Campaign Extensions

Dataset campaigns support additional configuration for packaging and reuse. Current implementation provides basic dataset assembly.

Dataset Schema and Format

Target dataset format (for example JSON, Parquet) plus schema versioning.

Target Sample Size and Sampling Strategy

Required sample counts and any stratification requirements. Dataset QA Metrics Metrics to compute and report, such as agreement rate, audit rate, deduplication rate, timestamp distribution, and coverage measures.

Licensing Constraints (Dataset Mode)

For dataset campaigns, “licensing constraints” are not a vague label. They are a declared rights configuration that controls access via the Distribution Layer, and produces a Dataset Licensing Record that is referenced on-chain. The protocol does not attempt to replace legal enforceability; it creates cryptographically verifiable commitments to the license terms used for access control, auditability, and downstream traceability.

Dataset Licensing Record

A Dataset Licensing Record is an immutable record describing the usage rights attached to a dataset artifact produced by a campaign. The full license text/terms are stored off-chain (e.g., in the Distribution Layer storage), while the protocol commits a Dataset Licensing Record hash reference on-chain. Required fields:

• dlr_id : unique identifier for the licensing record campaign_id : campaign that produced the dataset dataset_artifact_hash : hash of the packaged dataset artifact license_template_id : identifier for a standard license template (optional but recommended) license_terms_hash : hash commitment to the full license terms document usage_rights (structured): allowed_uses (e.g., internal evaluation, research, commercial, ○ training, redistribution) prohibited_uses (e.g., resale, re-identification, model training, ○ derivative datasets) derivative_rights (allowed / restricted / forbidden) ○ redistribution_rights (none / permitted / permitted with ○ constraints) attribution_required (yes/no + attribution string if applicable) ○ exclusivity (non-exclusive / time-limited exclusive / exclusive) ○ territory (global or specific jurisdictions) ○ term (start date + expiry, or perpetual) ○ privacy_and_compliance_flags (structured): whether the dataset is subject to additional constraints (e.g., “no personal data”, “restricted cohort”, “confidential mode only”) issuer_signatures : requester signature (and optionally curator/DAO signature if governance requires)

Optional (but strongly recommended) fields:

• royalty_policy_id / royalty_policy_hash (if resale/subscription is enabled)

• revocation_policy (when allowed; otherwise explicitly state “irrevocable”)

• audit_rights (whether buyer access is logged; what can be audited)

Default rule: dataset campaigns must declare at least: allowed uses, prohibited uses, redistribution rights, attribution requirement, and term. Campaigns that omit these fields are invalid and can’t be published or distributed. On-chain, the protocol records (campaign_id, dataset_artifact_hash, license_terms_hash, dlr_id, issuer_signature) as the licensing reference.

Versioning and Update Policy

Rules for dataset revisions and subscription updates.

On-Chain and Off-Chain Placement for Campaigns

Campaigns are committed on-chain as minimal, non-sensitive metadata.

On-Chain Off-Chain

Privacy and Anonymity

The platform prioritizes contributor privacy. Participants are not required to reveal real-world identity. Contributors are assigned anonymized worker codes to prevent identity linkage across campaigns. Current implementation provides basic anonymization with plans for enhanced privacy features.

Design Principles

The platform follows core privacy principles:

1. Sensitive content is stored securely. Prompts, attachments, and outputs are managed with access controls.

2. Participation doesn't require real-world identity. Eligibility is enforced through declared routing rules such as reputation, Account Trust/runtime policy, and cohort proofs.

3. Metadata collection is minimized for privacy protection.

It is crucial to treat it carefully due to potential privacy leaks, so campaigns explicitly define which metadata hooks are enabled.

Privacy Modes

Campaigns choose a privacy mode in the configuration. It determines how tasks are distributed, what is visible to participants, what metadata is collected, and how outputs are delivered.

Standard Mode

Suitable for non-sensitive studies and general evaluation tasks. The characteristics are:

• Task prompts and context are delivered off-chain to contributors and validators.
• Outputs are stored off-chain and delivered through the Distribution layer.
• The protocol records on-chain only campaign commitments, outcomes, and settlement receipts.
• Minimal metadata hooks are enabled to support anti-fraud measures.

Standard mode doesn’t require identity disclosure, but it may allow a broader catalogue of campaigns and higher transparency for aggregated results.

Protocol Roadmap: The sections below describe the full privacy design planned for the Lioth protocol. Confidential modes, watermarking, confidentiality bonds, private cohort proofs, encrypted storage with PSOs, key custody modes, delivery receipts, and on-chain licensing references are not yet active in the current platform. They are documented here to define the target protocol architecture.

Confidential Mode

Confidential mode is for campaigns where prompts, context, or outputs contain sensitive information (enterprise IP, unreleased products, internal policies). It is designed to reduce leakage risk. It can’t guarantee that a human will never leak anything, but the goal is to make leakage unlikely, limited in impact, and enforceable.

Confidential mode protects the prompt and attached materials, the identity of the customer or enterprise (when needed), the outputs and deliverables, and the linkability of participants across campaigns. The core idea is to reduce exposure, restrict access and enforce consequences through many mechanisms:

• Minimize what is shown: redact names, remove identifiers, and splitting work into smaller pieces.
• Restrict who can access the work: confidential tasks can be limited to vetted cohorts, using declared eligibility rules, reputation, Account Trust/runtime policy, and cohort proofs. This increases accountability.
• Make leaks traceable when possible: campaigns can include per-participant watermarking or canary tokens so that leaked text can be linked back to the source.
• Make leaks costly: high-sensitivity campaigns can require a confidentiality bond. If a leak is proven through arbitration, the bond can be slashed.

Confidential Tiers

The protocol supports three confidentiality tiers, so requesters can choose the right trade-off between scale and risk:

• Tier 1 (Confidential Public): it is used when the task can be safely crowdsourced after redaction. Typical controls may include redaction, abstraction and task splitting.
• Tier 2 (Confidential Vetted): it is used when contributors must see sensitive context. Some controls may include reputation gating, cohort restriction, watermarket, and optional bond.
• Tier 3 (Enterprise Restricted): it is used when leakage risk must be extremely low. Typical controls include enterprise-approved cohort or enterprise-hosted task environments, with Lioth providing verification receipts and settlement.

Recommended Campaign Fields

• privacy_tier: public_redacted, vetted, enterprise_restricted
• allowed_context: redacted, full, enterprise_hosted cohort_requirements: eligibility rules, trust/readiness policy, and cohort proofs
• watermarking: on, off dispute_rules: dispute window + evidence requirements + arbitration quorum

Private Cohort Mode

This mode adds cohort gating to either standard or confidential mode. In private cohort mode:

• Contributors must present an eligibility proof to receive tasks, and these can encode attributes such as region, language proficiency, professional background, or prior screening completion.

• Proofs are designed to avoid revealing identity. The requester learns that the participant satisfies the cohort condition, not who they are.

By this way, it supports workflows like screening funnels, longitudinal studies, and targeted recruitment while preserving participant anonymity.

Data minimization and metadata hooks

Metadata hooks are optional and campaign-based. They exist to support verification quality and fraud detection, but they are constrained because metadata can be identifying. The protocol defines a minimal default metadata set:

• Completion time bucket Task spec version
• Client version Task variant identifier
• Optional cohort proof reference

Additional telemetry may be enabled only when a campaign explicitly opts in and privacy mode allows it. It may include copy-paste indicators, interaction event counts, or keystroke timing statistics. These signals should be used as risk indicators for audit triggers, not as standalone proofs. If enabled, they should be processed and stored off-chain.

Proof of Eligibility without Identity Disclosure

Campaigns often need targeted cohorts. The protocol supports this using privacy-preserving proofs rather than identity disclosure. A requester can specify cohort requirements such as:

• Passed a screening task
• Language proficiency tier
• Domain expertise credential
• Geographic region
• Longitudinal continuity

Participants can satisfy their requirements by presenting proofs. The proof reveals only the required statement, not personal information. The protocol can verify the proof and route the task accordingly. This mechanism supports screening funnels and recontact workflows while reducing the incentive for identity farming and data harvesting.

Storage, Encryption and Delivery

All task content and outputs are stored off-chain. The protocol treats storage and delivery as part of the Distribution Layer and requires confidentiality as a mandatory feature. Data objects (off-chain, content-addressed) The Distribution Layer operates on a small set of standardized objects:

• Task Payload: the encrypted submission payload produced by a contributor (raw output + required fields).
• Validated Output: the accepted/rejected result reference + any allowed structured fields for delivery.
• Bundle: one or more outputs packaged into the requester’s required format (JSON, CSV, Parquet, report, file set, etc.).
• Manifest: a machine-readable index of a bundle (object IDs, schema/version, counts, hashes, size, timestamps).
• Delivery Receipt: a signed event proving that a specific manifest/bundle was prepared and delivered under a specific campaign configuration hash (without revealing contents).

Encryption Requirements (At Rest + in Transit)

At minimum:

• Encrypted at rest: all payloads, bundles, datasets and manifests are stored encrypted.
• End-to-end encryption to requesters: delivery uses an encryption envelope so only entitled requesters (and authorized organizational keys, if enabled) can access to data.
• Key separation: encryption keys for content are distinct from identity/reputation keys and are not committed on-chain.
• Campaigns may require replicated encrypted storage across multiple PSOs (tier-defined replication factor) to reduce availability risk.
• Delivery integrity may be verified via bundle/manifest hash commitments and signed delivery receipts, independent of which PSO served delivery.

Key Custody Modes (Campaign Parameter)

Each campaign declares a key custody mode inside its Delivery Configuration:

• Requester-managed keys (default): requesters can provide or generate a public key (or org set key) to encrypt delivery envelopes.

• The protocol never needs requester private keys.

• PSO-managed ephemeral keys (optional): a Delivery PSO generates per-bundle encryption keys and encrypts them to requester keys; PSO never receives requester secrets and cannot decrypt after envelope creation.

• Enterprise-hosted environment (confidential/enterprise tier): delivery, storage, and decryption occur inside an enterprise-controlled environment. The protocol provides verification receipts and settlement only. It is recommended when policy requires data residency or internal-only handling.

Entitlements and Access Control

Access control is enforced through entitlements linked to campaign mode and licensing:

• Direct work mode: entitlements typically belong to the requester identity (and optionally a requester organizational group).
• Dataset mode: entitlements reflect licensing constraints (public/private, permitted usage, resale rules). Entitlement checks happen off-chain, while licensing references for dataset campaigns can be recorded on-chain.

Delivery Modes (Campaign Parameter)

Delivery configuration specifies one or more supported delivery paths:

• Private delivery (default): requester-only encrypted delivery (download/API/webhook).
• Subscription feed: incremental bundle updates over time (dataset updates, continuous labeling streams).
• Public distribution (opt-in): listing of dataset artifacts with licensing references (content still off-chain).

Delivery Receipts and Integrity Commitments

For each delivered bundle or dataset artifact, the Distribution Layer produces a Delivery Receipt (signed service event) containing:

• Campaign identifier + campaign configuration hash
• Bundle/manifest identifier(s) and bundle/manifest hash Delivery mode and endpoint type (without revealing secrets)
• Entitlement reference (e.g. requester ID, license ID reference)
• Timestamp(s) and PSO signature

A commitment to the Delivery Receipt may be recorded on-chain. This enables independent verification that a specific bundle hash was delivered under a specific configuration, without publishing sensitive content.

Retention, Deletion, and Audit Logs (Off-Chain)

Each campaign declares retention and logging parameters:

• Retention window: how long encrypted payloads/bundles/manifests are kept by Distribution PSOs.
• Deletion semantics: PSOs can delete stored encrypted objects after retention. The protocol can’t guarantee deletion of copies downloaded by requesters.
• Audit logs: delivery logs are available off-chain for enterprise audit needs, including which delivery receipts were issued and when.

On-Chain Records

The protocol records only the information required to provide settlement finality and independent auditability. On-chain records include:

• Campaign identifier and configuration commitment hash.
• Escrow funding commitment and settlement receipts.
• Task outcomes (accepted, rejected, audited) as state transitions.
• Validator quorum summary and finality proofs.
• Reputation updates and slashing events, when applicable.
• Dataset source of origin proofs and licensing references for dataset campaigns.
• Licensing commitments (dataset campaigns): a Dataset Licensing Record commitment reference, binding dataset_artifact_hash ↔ license_terms_hash, plus issuer signature(s). This enables third parties to verify which licensing terms governed distribution without revealing the full license document on-chain.

Off-Chain Storage

Off-chain data includes:

• Full task prompts, attachments, and external materials.

• Raw outputs and deliverable payloads.

• Detailed validator rationales and review materials.

• Fraud-signal computation artifacts such as embeddings and similarity indices.

• Dataset artifacts and QA report details.

• Private delivery endpoints and access control metadata.

Threats and Privacy Risk Boundaries

The protocol treats as privacy risks these actions:

• Collecting direct identifiers (names, phone numbers).
• Storing raw outputs on-chain.
• Collecting high-resolution telemetry by default.
• Cross-campaign linkability through shared metadata.

To reduce these risks, the protocol requires:

• Campaign-level declaration of privacy mode and metadata hooks.
• Default minimization of telemetry.
• Confidentiality-safe delivery pipelines.
• Separation between on-chain commitments and off-chain content.

Protocol Identity and Pseudonymity

Each participant in the protocol has a persistent pseudonymous identity used for routing, reputation, settlement, and delivery entitlements, but it is not a required real-world identity. Protocol identities allow continuity for longitudinal studies and allow performance to accumulate over time without exposing personal information. These can be configured to support:

• single-campaign participation with limited linkability;
• multi-campaign participation with reputation continuity; and
• cohort continuity for recontact workflows.

The protocol treats linkability as a privacy risk. Campaigns should avoid collecting unnecessary correlating signals. Distribution and storage layers must support isolating campaign data so that a participant's activity cannot be trivially linked across unrelated campaigns.

Implementations may use overlap and cluster-confidence signals to manage operational risk. Those signals can justify routing or readiness restrictions, but they are not the same thing as canonical proof of a shared real-world identity or confirmed fraud.

Identity Layer: Uniqueness, Reputation & Economic Incentives

Lioth coordinates human work without requiring KYC. The identity layer is designed to make multi-account behavior economically unreliable and operationally weak, while allowing long-lived contributors to build credibility over time. The protocol does not claim perfect one-human-one-account uniqueness. Instead, it targets a practical security outcome: new or suspicious identities should have low throughput, low earning capacity, and higher scrutiny, while high-quality identities compound durable performance history.

Protocol Identity Models

A protocol identity is a pseudonymous account represented by a handle and protocol-maintained state. No real-world identifiers are required. For each identity, the protocol tracks:

• reputation state R(id) in [0,1];
• optional bond/stake balance S(id) >= 0 where enabled by campaign/network phase;
• performance vector V(id) including finalized quality history, audit outcomes, dispute outcomes, volume, and integrity posture; and
• where a given network phase uses it, a separate operational access score such as Account Trust, distinct from canonical PHK truth.

Identity is treated as an economic and reputational object. Personal identity is not a protocol dependency.

Uniqueness without KYC

The protocol discourages Sybil behavior through several mechanisms:

• cold-start limits: new identities begin with lower caps, lower routing priority, limited launch access, and higher scrutiny;
• reputation compounding: a well-behaved contributor maximizes long-term earnings by building one strong identity rather than farming weak accounts;
• adaptive scrutiny: integrity signals can trigger increased audits, reduced routing, delayed settlement, or temporary operational restrictions; and
• where enabled, economic friction such as stake/bond requirements for more sensitive modes.

Reputation as Finalized Performance Memory

Reputation is the protocol's memory of verified performance. It updates only from finalized outcomes after validation, audits, and disputes/arbitration have reached finality. Reputation updates must be traceable to finalized receipts and reference the active Parameter Registry version. To avoid conflating different skills, Lioth separates reputation into tracks:

• $R_{\text{work}}(id)$

  measures contribution quality as a worker.

• $R_{\text{valid}}(id)$

  measures accuracy and consistency as a validator, arbitrator, or auditor.

Campaigns may also define domain tags so reputation can be tracked per domain when specialization is required.

Operational Access Layers

Some bootstrap or testnet deployments may use an operational access layer, such as Account Trust, on top of finalized performance tracks. Operational access layers can govern caps, validator readiness, settlement timing, launch progression, reward shaping, or other runtime policy without becoming PHK outcomes or confirmed-fraud findings.

This separation matters: R_work and R_valid remain protocol performance tracks grounded in finalized outcomes, while operational access layers remain phase-specific routing and readiness policy.

Implementation note: Current live Account Trust behavior is documented in App Status.

Update Triggers

A reputation track updates when a finalized event occurs:

• contributor update: on finalized task outcome for the contributor's submission;
• validator update: on finalized task outcome for tasks the validator reviewed, and on finalized audits or arbitrations they participated in; and
• no update happens from flags or suspicion alone; only confirmed outcomes and finalized enforcement actions apply.

Operational access layers, by contrast, may aggregate finalized performance with network-phase policy inputs for routing, readiness, and release control. They remain separate from PHK finality.

Scoring Inputs (Q, Risk, Inactivity)

All inputs are normalized to [0,1] and computed per track.

• Quality score Q_work (contributors)

  For a finalized contribution, define:

  • O (outcome): 1 if finalized state is accepted, including after audit or arbitration, else 0.
  • A (agreement): validator alignment strength, computed from the finalized quorum summary.
  • G (gold/calibration): optional score on campaign-defined gold or calibration tasks.
  $$Q_{\text{work}} = w_O \cdot O + w_A \cdot A + w_G \cdot G$$

• Quality score Q_valid (validators, auditors, arbitrators)

  For each finalized task a validator reviewed:

  • M (match): 1 if the validator's revealed decision matches the finalized outcome, else 0.
  • A (agreement context): optional scaling factor from quorum agreement.
  • G (gold/calibration): optional accuracy on gold tasks.
  $$Q_{\text{valid}} = w_M \cdot M + w_A \cdot A + w_G \cdot G$$

• Risk (confirmed integrity violations only)

  • Risk is 0 unless confirmed by audit/arbitration, or other tier-defined finalized enforcement.
  • Risk_work applies to contributors when finalized enforcement confirms fraud or policy violation.
  • Risk_valid applies to validators when finalized enforcement confirms negligence patterns or collusion/manipulation.

• Inactivity (privilege decay)

  • Inactivity is 0 while active; after inactivity_grace_days it rises toward 1 according to a registry-defined schedule.

Update Equations

Each track updates with an exponential moving update that subtracts penalties:

Where:

• \lambda controls responsiveness to new outcomes.
• \mu controls penalty strength for confirmed integrity violations.
• \delta controls inactivity decay.

All coefficients are per-track and set in the Parameter Registry. Values remain within [0,1].

Minimum Sample and Start Protections

To prevent lucky tasks from over-boosting reputation:

• the protocol can enforce minimum finalized-evidence thresholds before an identity advances into higher-trust roles; and
• new identities begin in a lower-access posture through caps, audits, settlement delays, and other operational controls.

Bootstrap or testnet deployments may also use audited bootstrap controls to address cold start without pretending readiness has already been fully earned.

Validator Readiness

Validator readiness now has multiple layers:

• Policy-eligible validator: the account satisfies the active readiness policy.
• Bootstrap-approved validator: where used, the account has been explicitly approved by audited bootstrap/testnet operator control to participate as a validator during cold start.
• Effective validator readiness: the validator is currently usable after role, policy, bootstrap approval where applicable, account status, safety restrictions, and integrity restrictions are all considered.

This means a validator can be policy-eligible and bootstrap-approved yet still be workspace-unavailable because of an integrity restriction or account/safety restriction. Bootstrap approval or audited assignment overrides affect availability only. The validator still produces the PHK decision.

On-Chain Reputation Update Receipt

When a reputation update is recorded on-chain, it must include:

• identity ID and track, and optional domain tag;
• previous value, new value or delta, and timestamp;
• references to finalized task/audit/arbitration receipt(s) used; and
• the Parameter Registry version hash used for coefficients/weights.

This enables independent verification of rule application without revealing sensitive content.

Reputation Tiers and Trust Bands

To keep the system predictable, the protocol maps performance into tiers that control caps, access, multipliers, and role eligibility. Exact parameters can be tuned by governance and may vary by network phase. Tiers are not a guarantee of truth.

Some network phases may also map operational access scores into bands that govern contributor caps, settlement timing, reward shaping, quality-tier ceilings, launch access, or validator eligibility. These bands are runtime operational controls. They do not replace the underlying reputation tracks.

Economic Incentives

The protocol uses multiple incentive functions that depend on finalized performance and network phase:

• task caps (throughput control);
• reward shaping where enabled for the active network phase;
• optional stake requirements where enabled; and
• access to higher-sensitivity pools or higher launch tiers.

Bootstrap/testnet implementations may prioritize caps, settlement timing, and launch progression over bond-heavy participation. Bonds and slashing remain broader protocol tools rather than prerequisites for every deployment phase.

Role Incentives and Separation of Duties

Because the protocol has multiple participant roles, incentives must avoid conflicts:

• contributors earn rewards for finalized accepted work;
• validators earn for producing decisions that remain aligned with finalized outcomes;
• auditors/arbitrators earn only through due-process paths where enabled; and
• curators earn for useful templates/specifications rather than raw volume alone.

This separation reduces collusion incentives and prevents a single role from controlling outcomes.

Requester Abuse Resistance

The incentive system must also protect contributors from malicious requesters. The protocol supports:

• bounded dispute windows;
• dispute deposits for requesters to prevent spam disputes;
• arbitration quorums for subjective deliverables; and
• settlement finality rules so reputation and payouts update only after final resolution.

Optional Boosters (Proof of Personhood and Expertise Credentials)

Boosters reduce cold-start friction while keeping the protocol KYC-free. If an identity presents a valid proof of personhood, it may receive higher initial caps or reduced friction in early participation. Participants may also optionally link verifiable external credentials to qualify for domain-specific cohorts. These credentials should be optional, scoped to eligibility and routing rather than public identity, revocable, and processed off-chain.

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

Security and Anti-Fraud Mechanisms

The protocol is designed to produce high-quality human work through PHK finality under bounded-risk assumptions. Security combines tiered verification, validator review, integrity signals, operational access controls where present, and due-process enforcement. Different deployment phases can activate narrower or broader subsets of that design without changing the PHK trust boundary.

Threat Model

The protocol considers these threats:

• automated or AI-generated submissions intended to earn rewards without genuine human work;
• Sybil farming with many low-cost identities to increase throughput or bypass caps;
• collusion between contributors and validators to approve low-quality or fraudulent work;
• validator corruption or laziness, approving bad work to maximize rewards;
• spam and throughput attacks designed to overload validation capacity;
• dataset manipulation attempts such as bias injection, duplication, poisoning, or low-effort volume; and
• requester abuse, including frivolous disputes or adversarial rubrics intended to deny payouts.

The protocol does not claim to prevent all attacks. The security objective is bounded-risk:

• keep SAR below tier targets when assistance is disallowed;
• keep Audit Overturn Rate below tier targets as a proxy for verification reliability; and
• make adversarial participation operationally weak and economically unattractive through caps, routing restrictions, audits, and due-process penalties where enabled.

Campaigns must declare their assistance policy and tier configuration so verification strength and risk posture are explicit.

Implementation note: Current live bootstrap/testnet security behavior is documented in App Status. The sections below define the broader security model and trust boundaries; not every module is active in every deployment phase.

Claim Policy

The protocol does not claim to prove "human-only" origin. It claims to commit rule configurations by hash, enforce verification workflows and due process, and publish bounded-risk metrics at campaign and tier level.

Security Primitives

Lioth relies on five security primitives:

• finalized-outcome-based reputation and, where used, separate operational access controls;
• throughput caps, settlement delays, and launch restrictions for new or weak identities;
• multi-party verification with audits and challenge paths;
• off-chain integrity signals anchored to finalized outcomes; and
• due-process penalties where enabled after PHK finality.

Contributor-Level Defenses

Contributors are the main source of outputs, so the system prioritizes early detection and bounded impact:

• Fresh-identity supervision: new identities operate under stricter constraints such as lower caps, lower routing priority, higher settlement delay, and narrower launch access.
• Similarity and duplication defenses: near-duplicate work is treated as a primary signal of automation or farming.
• Behavioral anomaly detection: timing, overlap, and workflow patterns can trigger increased scrutiny.
• Economic deterrence after proof: where campaigns enable it, confirmed fraud can still lead to reputation loss, payout loss, access restrictions, and optional slashing.

Flagging alone does not finalize truth or apply confirmed-fraud penalties.

Cluster Confidence and Operational Restriction Levels

Implementations may use cluster-confidence scoring to summarize overlap posture across accounts. This can produce operational restriction levels that affect routing priority, audit pressure, validator availability, or whether an account is available for automatic routing. These levels are not themselves canonical proof of collusion or fraud. They are provisional integrity posture used to reduce risk while PHK, audits, and due process continue to govern truth.

This distinction is critical:

• Provisional integrity posture: cluster confidence, anomaly flags, similarity signals, overlap metrics.
• Confirmed violation: fraud/collusion/negligence established through PHK-linked audit/arbitration or other finalized enforcement path.

The former can justify operational restrictions. The latter is what can justify finalized penalties.

Validator Integrity and Anti-Collusion

Validators are a critical trust bottleneck. The protocol designs validator power to be measurable and punishable.

• Validator review remains canonical: final outcomes are produced by validator decisions under PHK, not by protocol services or operator tooling.
• Assignment integrity: validators are routed under the active assignment policy, with pairing limits, conflict controls, and integrity restrictions where applicable.
• Multi-party review: each task is reviewed by the number of validators required by the relevant tier/runtime rules.
• Audits and challenge paths: some tasks may be audited regardless of outcome, and additional audits may trigger on disagreement or risk posture.
• Validator incentives: validators are rewarded for decisions that remain aligned with finalized outcomes, not for volume alone.

Bootstrap Validator Supply and Force Assignment

Bootstrap/testnet deployments may use audited validator approval or assignment overrides to keep validation capacity usable during cold start or incident response. These controls can affect who is available to review, including cases where automatic routing would otherwise block a validator, but they do not let operators insert approve/reject outcomes. The assigned validator still produces the PHK decision.

What Can Be Independently Verified

The protocol can be audited for steering and collusion resistance by verifying:

• that validator quorums and assignment events match the active routing policy and recorded workflow events;
• that repeated pairing limits were enforced where applicable;
• that any manual or force assignment was explicitly logged with actor, reason, and target;
• that final outcomes match quorum thresholds and finality receipts; and
• that operational safety actions, if any, did not rewrite canonical PHK truth.

This does not claim perfect censorship resistance of off-chain routing. It provides auditability and enforceable constraints under committed rules.

Campaign-Level Controls Against Spam and Overload

Spam is handled primarily through throughput control and bounded access. Campaigns and runtime policy can enforce:

• per-identity caps and concurrency limits;
• operational access ceilings for task types or launch access;
• queue throttling and adaptive routing;
• higher audit pressure when abnormal patterns appear; and
• safety-overlay holds where active incidents require operational containment.

These controls prevent validation bottlenecks and preserve usability.

Dataset and Deliverable Integrity

Both protocol output types require integrity guarantees. Mechanisms include:

• deduplication and novelty checks for dataset campaigns;
• anomaly detection for label distributions, entropy, cohort drift, and suspicious validator agreement;
• schema compliance and quality reports for dataset artifacts;
• artifact hashing, manifest generation, and delivery receipt metadata for requester-facing delivery; and
• provenance anchoring and licensing references without exposing content.

Anomalies do not automatically invalidate data. They trigger deeper audits, more conservative routing, or further review.

Requester Abuse Resistance

Anti-fraud must apply to requesters as well. This includes:

• bounded dispute windows;
• requester dispute deposits where enabled;
• arbitration quorums for subjective deliverables; and
• settlement finality rules so payouts and reputation updates occur only after resolution.

Operational safety controls may also hold settlement or release paths during incidents without changing PHK truth.

Protocol Applications and Use Cases

Lioth is a general-purpose coordination layer for human work where outputs can be delivered directly as services, or packaged as high-value datasets with source and quality metrics. The same architecture supports microtasks, research studies, expert work, evaluation pipelines, and long-running programs. This section describes the most important applications enabled by the protocol, using simple categories that map to real customer demand.

1. Human Work and Microtasks

The protocol supports task outsourcing, but designed for higher trust, better verification, and stronger privacy. A requester defines a campaign, a cohort, a task schema, and validation rules. Contributors complete tasks, validators finalize outcomes, and the deliverable is packaged and distributed. Typical task types include:

• Preference ranking and qualitative feedback

• Classification and rubric-based labeling

• Transcription, extraction, and cleanup

• Short research tasks and structured summaries Creative generation with constraints (copy variants, naming, critique)

• Bilingual or cultural interpretation tasks

What Lioth adds compared to centralized task platforms:

• Measurable verification strength (quorum, audits, dispute finality)

• Reputation-gated access to sensitive or high-value work

• Privacy tiers for proprietary prompts and confidential delivery Objective source of origin receipts for delivered work

• A long-term identity and reputation system that compounds quality

2. Research Studies and Participant Recruitment (Screening, Longitudinal, Interviews)

• The protocol supports a research-style workflow where the value comes from recruiting the right participants and collecting clean responses.
• Supported campaign modes include:
• Screening funnels
• Multi-part studies Diary studies
• Interviews and focus groups

Typical task types:

• Surveys and experiments with attention checks Behavioral responses to stimulus (ratings, forced choice, comprehension)
• Longitudinal experience reports (time-series human behavior)
• Cohort-based comparisons (region, profession, experience tier)

3. Human Evaluation for AI Systems (Evaluation Pipelines and Training Signals)

A major use case of the protocol is producing human judgement signals that are difficult to automate and remain valuable even as models improve.

Some examples include:

• Pairwise reference evaluation of model outputs (A/B/Tie)

• Rubric grading (helpfulness, correctness, style, safety, policy compliance)

• Red teaming and failure discovery with reproducible test cases “Human-in-the-loop” review pipelines for sensitive domains These outputs can be delivered as direct deliverables (evaluation reports, failure catalogs, red-team findings), or packaged datasets (preference labels, rubric scores, adversarial sets) with QA metrics.

4. Forecasting and Human Judgement Under Uncertainty (Probabilities + Reasoning)

Traditional prediction markets aggregate capital into a single price. Lioth can run forecasting campaigns that aggregate human probability estimates and reasoning. The output is not only a number, but an interpretable forecast object. Forecasting tasks ask contributors to:

• Assign a probability to an outcome within a defined horizon
• Cite key drivers and risks Optionally update forecasts as conditions change

Instead of producing only a single “market price”, the protocol produces:

• Aggregated probability estimates (mean, median) and dispersion (agreement vs disagreement)
• Cohort-based differences (by region, experience tier, expertise cohort)
• Dominant narratives and cited drivers
• Tail-risk signals and low-probability scenarios

These outputs can be distributed as forecasting feeds (rolling updates), event probability datasets, consensus and uncertainty indices, or scenario planning inputs for enterprises.

5. Human-Calibrated Forecasting Models (Learning From Judgement)

Over time, forecasting campaigns produce a dataset of probabilities, rationales, and realized outcomes. This allows the protocol to measure calibration and train models that learn from human judgement rather than replacing it. Each record can include:

• Forecast probability

• Rationale and drivers Optional domain tags and cohort metadata

• The eventual outcome when resolved This enables calibration metrics per identity cohort, weighting schemes that privilege proven forecasters in specific domains, and domain-specific forecasting agents trained on human reasoning

6. Policy Adjudication and Moderation Decisions (Rubric-Based Judgement)

Some tasks require consistent application of rules under ambiguity. The protocol supports policy adjudication campaigns where contributors or trained reviewers apply a rubric to cases, and final outcomes are produced through multi-party verification audits. Typical task types:

• Content moderation edge-case review
• Compliance triage and risk classification
• Safety policy interpretation for AI outputs
• Contract clause classification or policy mapping

These campaigns benefit from restricted cohorts and reputation gating, higher quorums and audit rates, confidential tiers for sensitive content, dispute and arbitration procedures for subjectivity.

Lioth’s advantage is that recruitment, validation, and payments are coordinated under a single protocol model, while private prompts and raw responses remain off-chain and can be delivered confidentially.

7. UX Testing and Product Feedback (Human Interaction Data)

Lioth supports UX prototype testing campaigns where the value is human interaction, confusion points, friction, and qualitative reasoning. This is difficult to replace with synthetic responses because the signal is where humans struggle, what they misunderstand, and what they prefer. Typical task types include:

• Complete a flow in a prototype and report friction
• Rate clarity, trust, and usability
• Explain choices and expectations
• Produce structured issue reports and suggested improvements

Outputs can be direct deliverables (issue lists, cohort summaries, recordings handled off-chain), or longitudinal UX studies (repeat sessions over time with the same cohort).

8. Focused Agent Programs (Bootstrapping Demand and Building Expert Systems)

The protocol can also generate demand internally through long-running programs that train and evaluate domain-focused agents. In these programs:

• Experts contribute structured reasoning traces, rubrics, evaluations, and failure cases
• Validators enforce quality and consistency
• Outputs become either direct deliverables (evaluation suites, policies, SOPs) or packaged datasets for training and testing. This supports early network bootstrapping even before large enterprise demand exists, while producing assets that later requesters can license, subscribe to, or use to train internal systems.

9. Reputation As Cognitive Capital (Validated Human Knowledge)

Lioth’s reputation system is designed as a measurable record of verified cognitive performance. It can capture signals such as:

• Contribution quality under validation
• Consistency across tasks and contexts
• Calibration accuracy in forecasting-style tasks
• Policy judgement consistency under rubrics
• Overconfidence and underconfidence patterns

This reputation is pseudonymous, non-transferable, earned only through verified outcomes, and represents performance. This matters to route high-value work to proven participants without requiring KYC, and creates a new way to validate expertise.

Definitions and Glossary

This appendix includes both required primitives and optional modules. A minimal Lioth implementation requires only: Tasks, Campaigns, Contributions, Validators, PHK, PHK Receipts, and Delivery via the Distribution Layer. Optional components are explicitly labeled.

A.1 Core Primitives (Must-Know)

Lioth Protocol

A decentralized protocol for distributing structured tasks to humans, verifying outputs through PHK, and delivering finalized results through the Distribution Layer. Lioth supports both direct work deliverables and reusable dataset packaging.

Task

A structured unit of work defined by prompt/context, response schema, constraints (e.g., time window), and a validation rubric. Tasks are the atomic building blocks of Lioth.

Campaign

A batch of tasks with shared intent, schema, cohort requirements, budget, and verification settings (tier, audits, disputes). Campaigns are the operational unit for requesters.

Contribution

A participant’s submission for a task, including response fields and protocol-permitted verification metadata.

Requester

An entity that creates campaigns and funds payouts (company, researcher, institution, individual). Requesters define acceptance criteria, quality tier, cohort requirements, and delivery mode.

Acceptance Criteria

The conditions a requester defines for “done” and “acceptable.” May include objective checks (format, completeness) and subjective checks (quality, relevance) expressed via a rubric.

PHK (Proof of Human Knowledge)

Lioth’s verification framework and finality system for producing Human Verified Outputs. PHK combines randomized validator assignment, multi-validator evaluation, audits and dispute/arbitration (if enabled), integrity signals, and optional economic enforcement to finalize outcomes and emit PHK Receipts.

PHK Receipt

A verifiable record of which campaign rules were applied and what final outcome was finalized, referencing the relevant campaign configuration/commitments.

HVO (Human Verified Output)

A task result that has been finalized under PHK.

Deliverable HVO (Direct Output)

An HVO intended for direct consumption by a requester (e.g., evaluation, extraction, moderation, QA, research). Deliverable HVOs are delivered through the Distribution Layer and are not necessarily aggregated into datasets.

HVD (Human Verified Data)

A packaged dataset composed of HVO, produced under a dataset specification, accompanied by provenance hashes and a quality report, intended for aggregation, reuse, and licensing.

Dataset Artifact

The final packaged dataset (e.g., JSON/Parquet) produced from validated contributions/HVO, accompanied by a dataset specification and quality report.

Distribution Layer

The layer responsible for delivering verified outputs and datasets through public listings, private enterprise delivery, subscriptions, or direct integrations.

Dataset Licensing Record

A verifiable record of dataset rights and constraints referencing provenance hashes and license terms, without revealing sensitive content.

A.2 Requests, Specs, and Packaging

Campaign Specification (Campaignspec)

A requester-submitted specification that defines a campaign’s schema, cohort requirements, tier configuration, budget, acceptance criteria, delivery mode, and any dispute/arbitration options.

A.3 Actors (Human Roles)

Contributor

A participant who completes tasks and produces contributions.

Validator

A participant who verifies contributions by applying the rubric, detecting suspicious patterns, and participating in audits and dispute/arbitration where enabled. Auditor (role specialization; optional) A validator participating in an audit quorum during escalations.

Curator (Optional)

A participant who proposes, structures, and maintains high-value dataset templates or campaign schemas, especially for thematic or long-running efforts.

Arbitration Pool / Arbiters (Optional)

A designated set of validators (or specialized participants) used for dispute resolution when arbitration is enabled.

A.4 Verification, Escalation, and Policy

Consensus Threshold

The acceptance rule for a contribution (e.g., number/proportion of validators required to approve), including any escalation rules under disagreement.

Audit

An escalation step where an expanded quorum reviews a contribution due to disagreement, value/risk tier, anomalies, or dispute triggers.

Dispute

A formal challenge to an acceptance/rejection outcome, triggering additional review or arbitration under protocol rules.

Arbitration (Optional)

A higher-level review process (expanded quorum or designated pool) that resolves disputes and may trigger enforcement actions (e.g., slashing or requester penalties) under protocol rules.

Assistance Policy

Campaign-declared policy governing AI/tool assistance: allowed , disallowed , or allowed-with-disclosure , with enforcement and audit behavior defined by the tier/configuration.

Quality Tier

A predefined verification configuration (validator quorum, audit behavior, dispute options, privacy mode) that defines verification strength vs cost.

Benchmark Campaign

A controlled campaign designed to measure tier performance under defined conditions (e.g., calibration/gold tasks, duplication stress tests, latency/finality measurement).

Tier Targets

Governance-defined objective thresholds for bounded-risk metrics per tier, used for reporting and tuning rather than guarantees.

A.5 Economics & Enforcement

Escrow

Funds locked for a campaign to guarantee payouts, validator rewards, and dispute/arbitration costs.

Work Budget (WB)

Escrow line item reserved for contributor payouts upon finalized acceptance.

Verification Budget (VB)

Escrow line item reserved for validator base rewards for quorum reviews.

Audit Reserve (AR)

Escrow line item reserved for audit execution and auditor rewards, spent only when audits trigger.

Dispute / Arbitration Reserve (DR)

Optional escrow line item reserved for dispute handling and arbitration quorum costs, spent only if disputes are enabled and triggered.

Protocol Fee

A fee routed to the protocol treasury/security budget to fund maintenance, security, and ecosystem incentives.

Heldback Reward

A fraction of validator base rewards held until finality and released/forfeited based on alignment with finalized outcomes.

Stake (S)

Collateral locked by participants (contributors/validators; optionally requesters) that can be slashed for proven fraud, negligence, or abuse.

Slashing

A penalty that reduces stake (and potentially reputation) when fraud, collusion, or negligent validation is proven under protocol rules.

Reputation (R)

A non-transferable score reflecting historical quality and integrity. Reputation may influence task access, reward multipliers, validation weight, rate limits, and role eligibility.

Royalty Split

A committed distribution rule for dataset licensing/subscription revenue across contributors, validators/auditors, curators (if applicable), and the protocol treasury.

A.6 Privacy, Identity, and Eligibility

Proof of Personhood / Proof of Humanity (Pop/Poh) (Optional)

External systems that help establish uniqueness of a participant. In Lioth these are never mandatory; they may reduce friction or increase confidence where required.

Zero-Knowledge Credential (ZK Credential)

A privacy-preserving proof of an attribute (e.g., “Region: EU”, “Role: founder”) without revealing identity. Used for cohort-restricted campaigns.

ZK Issuer (Optional)

An entity able to attest to an attribute for ZK credentials (institution, platform, employer, or protocol-native issuer based on contribution history).

A.7 Protocol Services, Operators, and Auditability

Protocol Service Operator (PSO)

An entity that runs one or more deterministic protocol services (e.g., orchestration, integrity checks, dataset assembly, delivery) under published service specifications. PSOs emit signed service events. PSOs do not determine final acceptance; final outcomes are produced through PHK and recorded via PHK Receipts.

Service Specification

A versioned definition of how a protocol service must behave (inputs, allowed outputs, receipt format, constraints). Service specs are referenced by hash to enable auditability and reproducibility across multiple operators.

Signed Service Event

A cryptographically signed record produced by a protocol service (e.g., assignment event, guard report, dataset assembly report, delivery receipt) referencing the campaign configuration hash and relevant spec hashes. Signed service events support auditability but do not override PHK finality.

Implementation note: Bootstrap/testnet operator-assisted actions, when present, must be explicitly logged and never substitute for PHK outcomes. Current live behavior is documented in App Status.

Validation Guard (Optional)

An automated integrity service that computes risk indicators and flags suspicious contributions. It does not finalize outcomes; validators do. Cluster-confidence or anomaly outputs from the guard can justify operational restrictions or audits, but not canonical fraud findings on their own.

Spec Registry

An on-chain registry that stores approved service specification hashes, and optional version compatibility windows, for protocol services. Enables multiple operators to run identical deterministic workflows under publicly verifiable spec versions.

A.8 Control Plane, Data Plane, and Finality Artifacts

Control Plane / Data Plane

The control plane refers to on-chain commitments, PHK receipts, settlement/finality references, and parameter governance. The data plane refers to off-chain content, computation, encrypted storage, integrity artifacts, manifests, and delivery payloads. Lioth commits minimal control-plane artifacts on-chain while keeping sensitive data-plane content off-chain.

Finality Artifacts

The current protocol/runtime semantics distinguish several artifact classes:

• PHK receipts: canonical proofs of accepted/rejected finality.
• Service events: auditable orchestration, integrity, packaging, and delivery records.
• Delivery receipts: requester-facing delivery references for artifact/manifest versions.
• Safety-overlay events: operational records for payout freeze, settlement hold, quarantine, and TGE eligibility changes.

Only PHK receipts define canonical task truth. The others support execution, delivery, and operational safety without becoming truth authorities.

A.9 Governance & Safety

Lioth DAO

The on-chain governance system responsible for protocol parameter changes and treasury allocations after bootstrap.

Governance Activation

The milestone at which parameter authority transitions from bootstrap defaults to DAO-governed changes. Activation process and criteria are defined in the governance section.

Parameter Registry

An on-chain registry storing the canonical active protocol parameters (role thresholds, tier defaults, campaign templates, dispute defaults, fee policies). Parameter changes are applied through governance execution and become the source of truth for compliant clients and PSOs.

Governance Timelock

A delay between a governance vote passing and execution of the change on-chain. Timelocks reduce governance capture risk and give participants time to monitor, react, or exit.

Admin Safety Overlay

Bootstrap/testnet deployments may operate a distinct operational safety overlay that can hold settlement, freeze payout release, quarantine entities, mark suspected exploit posture, or exclude TGE-sensitive eligibility. These controls are auditable and intentionally separate from PHK finality. They do not rewrite accepted/rejected truth.

Implementation note: Current live safety-overlay and validator-bootstrap behavior are documented in App Status.

Bootstrap Validator Controls

Bootstrap/testnet deployments may approve validators for participation or use audited assignment overrides in controlled scenarios when automatic routing is blocked by cold start or integrity restrictions. These controls solve operational availability problems only. They do not let operators decide PHK outcomes.

Emergency Pause (Optional)

A bounded safety mechanism to temporarily pause specific protocol functions during critical incidents. Emergency Pause is transparent, time-limited, and does not permit fund seizure or outcome rewriting.

Security Council (Optional, Early Phase)

A limited-scope multi-signature committee authorized only to trigger Emergency Pause under strict constraints during early mainnet. Intended to sunset or be reduced as governance matures.

A.10 Reports and Metrics (Advanced)

PHK Tier Report

A standardized off-chain report summarizing campaign and tier performance metrics, referencing the campaign configuration hash and Parameter Registry version. Metrics include:

• AGR (Agreement Rate): rate of validator agreement under the configured rubric/quorum.
• AOR (Audit Override Rate): frequency with which audits overturn or materially change initial outcomes (when audits are enabled).
• RR (Rejection Rate): proportion of contributions rejected under PHK finality.
• TTF (Time To Finality): time from contribution submission to final outcome.
• DSPR (Dispute Rate): frequency of disputes per finalized outputs (when disputes are enabled).
• SAR (Suspicious Activity Rate): rate of contributions flagged by integrity signals/guards/sentinels (as configured).
• IDR (Integrity/Duplication Rate): measured duplication or integrity failure rate under configured detection methodology.

Acronym Policy

This document uses acronyms only when they (1) appear frequently, (2) materially improve readability, and (3) do not conflict with other abbreviations. The first occurrence of any acronym must be written as Full Term (ACR). Acronyms that appear infrequently are written out in full to reduce cognitive load.

To avoid ambiguity, each acronym maps to exactly one concept across the entire specification. In particular, escrow line items WB/VB/AR/DR are reserved exclusively for Work Budget, Verification Budget, Audit Reserve, and Dispute/Arbitration Reserve; metric abbreviations must not reuse these tokens (e.g., use AGR for agreement rate and IDR for integrity/duplication rate).