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.