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.