Accepted and rejected truth still comes from validator review under PHK. Admin actions, routing services, and delivery services may affect who can review or when funds and artifacts are released, but they do not rewrite canonical finality.
App Status
Current Testnet Status
What the Lioth testnet app is already doing today, what remains intentionally operator-scoped or limited, and what still belongs to broader protocol design.
Use this page for current runtime behavior. Use the Whitepaper for protocol design and invariants, and Protocol Defaults for the current testnet defaults alongside the broader protocol envelope.
Protocol design
Whitepaper
The longer-form protocol architecture, invariants, and module-level design.
Current defaults
Protocol Defaults
The split between live testnet defaults and the broader genesis parameter envelope.
Protocol Invariants
Invariant
PHK finality is canonical
Invariant
Off-chain services are constrained executors
Assignment, packaging, safety, and delivery services run the workflow and emit audit records, but they are not truth authorities. They assist execution around PHK rather than replacing validator-derived outcomes.
Invariant
Sensitive content stays off-chain
Task payloads, attachments, fraud signals, and requester deliverables remain off-chain application data. Lioth keeps the control plane narrow while leaving sensitive execution and delivery artifacts outside the chain.
Invariant
Verified is bounded-risk and policy-scoped
In Lioth, verified means produced and reviewed under a declared rubric, quality tier, and assistance policy. It does not claim perfect truth, perfect Sybil resistance, or that every payout or eligibility release has already been operationally cleared.
Live Now
Live now
Account Trust
- Account Trust starts at
0and grows toward100. It is the current runtime access and readiness layer for caps, launch access, settlement timing, reward shaping, and validator readiness.
It is distinct from canonical PHK truth, distinct from confirmed-fraud semantics, and distinct from the underlying protocol reputation language.
Live now
Validator readiness lanes
- Validators can be policy-eligible through trust-band policy.
Validators can also be bootstrap-approved through explicit operator control in testnet.
Effective readiness is the current usable state after role, account, safety, and cluster restrictions are all considered together.
Live now
Bootstrap validator operations
Bootstrap approval is active because testnet validator supply is still being curated through cold start.
- The approval lane keeps the validator side of the network usable.
It expands participation availability; it does not grant admin truth authority over PHK outcomes.
Live now
Cluster-confidence restrictions
Lioth currently uses provisional off-chain integrity posture to classify accounts into scrutiny, restricted, or hard-block states.
These restrictions can block auto-routing or effective validator readiness.
They are operational restrictions, not canonical proof of fraud or collusion.
Live now
Manual force assignment for controlled verification
Admin can manually assign or reassign validators in controlled testnet scenarios.
The bypass applies to assignment and routing only, including cases where readiness or cluster restrictions would otherwise block auto-routing.
The action is audited, and the assigned validator still produces the PHK decision.
Live now
Admin safety overlay
Settlement hold, payout freeze, restriction or quarantine style controls, manual-review posture, and TGE eligibility exclusion or restoration are live.
- These controls are intentionally separate from PHK finality.
They affect operational release and eligibility, not canonical accepted or rejected truth.
Live now
Requester runtime framing
Current requester launch behavior is testnet-first and Q0-first for ordinary user launches.
Campaign credit spend is framed around target accepted outputs rather than raw task attempts.
Accepted-output counts matter in launch, completion, and requester progression semantics.
Live now
Completion and delivery
Requester-facing completion and delivered states exist in the app today.
- Approved outputs can be viewed and exported as delivered outputs.
Dataset mode can assemble requester-facing artifacts together with manifest and receipt metadata when campaigns complete.
Live but Limited / Testnet-Scoped
Limited now
Bootstrap approval is operator-scoped
Bootstrap approval is a current testnet control used to solve cold-start validator supply. It should be read as an operational readiness lane, not as a permanent claim about final mainnet authority structure.
Limited now
Manual assignment remains operator-assisted
Manual assignment and reassignment are live, but they are intentionally framed as controlled verification tools. They are not the long-term claim that all validator routing will remain operator-directed.
Limited now
Safety controls are deliberately strong
The current safety overlay is intentionally conservative. Testnet needs the ability to freeze release paths, hold settlement, and restrict entities while workflow integrity and abuse patterns are still being validated.
Limited now
Availability and routing are conservative
Auto-routing can exclude validators who are otherwise role-correct but not effectively ready because of trust-band, safety, or cluster restrictions. That conservatism is part of the current testnet posture.
Limited now
Requester launch scope is still narrow
Ordinary user-launched campaigns are currently narrower than the full protocol envelope. The app is live for requester flow and accepted-output semantics today, but broader requester behavior is not yet the default live surface.
Limited now
Thresholds and tuning can still move
Trust bands, cluster thresholds, quorums, reward shaping, and launch policy are current testnet parameters. They are expected to be tuned as the network gathers more operational evidence.
Planned / Broader Protocol Direction
Broader direction
Broader Q1-Q3 requester rollout
The whitepaper and defaults describe a broader requester envelope across higher-assurance tiers. Current live default behavior is narrower and should not be read as if full Q1-Q3 requester launch behavior is already active.
Broader direction
Full bond-heavy participation
Bonding, slashing, and heavier economic participation remain part of the protocol design. Standard current testnet participation is still intentionally bond-light or bond-free for ordinary flows.
Broader direction
Broader routing decentralization
Lioth's broader protocol direction includes stronger decentralized routing assumptions, including fuller VRF-driven assignment where appropriate. Current live routing is more operational and bootstrap-aware.
Broader direction
More complete escrow and economic logic
The broader protocol design includes richer escrow-backed settlement and distribution mechanics. The current app already has runtime rewards, requester credits, and delivery semantics, but not the full mainnet economic envelope.
Broader direction
Deeper governance-controlled parameterization
The whitepaper describes a more complete governance-owned parameter registry. Current testnet behavior already exposes some live tuning, but it is not yet the same thing as full governance-controlled live parameterization.
Testnet Notes
How to read the current app
Thresholds may change, restrictions may be tuned, and some controls exist specifically to keep the testnet safe while validator supply, routing, and delivery flows are still being validated.
If a broader whitepaper module is described elsewhere, do not assume it is already the current live default in the app. This page is the current implementation-status view; the whitepaper remains the broader protocol design view.
Next Steps
Protocol design
Whitepaper
Broader protocol architecture, invariants, and longer-horizon module design.
Defaults
Protocol Defaults
Current testnet defaults side by side with the broader genesis protocol envelope.
Context
Comparison
Strategic positioning and how Lioth differs from marketplaces and managed data vendors.