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.