Documentation

2. Governing Principles

Two constraints hold across every interaction described in this document. They are architectural, not incidental, and they explain most of the design decisions that follow.

3. Roles and Responsibilities

4. The Submission and Verification Cycle

The cycle below repeats continuously in the background for every participating miner. It is presented here as a sequence of stages; timing details for each stage are given in Section 5.

1. 1

   Stage 1 - Preparation (miner-side, one time)

   A miner operator enables participation and configures which provider and model it is offering, along with the corresponding API key, entirely within its own environment. No data leaves the miner at this stage.

2. 2

   Stage 2 - Submission request (validator-initiated)

   The validator retrieves the protocol's current public key and its current list of accepted providers and models, then issues a submission request to every eligible miner. These values are fetched fresh on each round rather than cached, so a request is never encrypted against a key the protocol has since rotated away from.

3. 3

   Stage 3 - Miner response

   Each miner evaluates the request locally against its own configuration:

   • If the miner has not opted in, it declines.
   • If the requested provider or model is not on the accepted list for that round, it declines.
   • Otherwise, it encrypts its key against the protocol's public key and responds affirmatively.

   This evaluation is designed to fail safely: any unexpected error on the miner's side results in a decline rather than a malformed or partial submission.

4. 4

   Stage 4 - Relay

   The validator forwards each affirmative response to the protocol exactly as received, with no visibility into its contents. Responses of either kind (offer or decline) are logged for basic participation tracking; as detailed in Section 6, this record does not influence reward.

5. 5

   Stage 5 - Verification and custody

   On receipt, the protocol performs an ordered sequence of checks: it confirms the provider and model are permitted, decrypts the submission, places a genuine test call against the provider to confirm the key is functional (rather than merely well-formed), and checks that the same key is not already active under a different hotkey. A submission that passes every check is re-encrypted under a separate storage key and retained; the temporary decrypted copy is discarded immediately. A submission that fails any check is rejected outright and never stored.

6. 6

   Stage 6 - Active use

   An accepted key becomes available to the protocol's key pool. At present, this pool is exercised by a recurring health-check process that re-tests each active key on a schedule; this is also the current source of the usage data described below. The same pool is designed to serve future protocol-side consumers as they are introduced.

7. 7

   Stage 7 - Reporting

   The validator periodically requests all usage activity recorded since its last check - successes, failures, average latency, and current active status - for every key it has submitted. This report is the sole input to the scoring calculation described in Section 6.

5. Timing and Cadence

Three independent schedules govern the cycle. They are not synchronized with one another, and understanding the distinction matters for interpreting observed behavior.

Because scores can update many times between two weight submissions, only whichever score a miner holds at the precise moment an epoch triggers is the value that reaches the chain.

6. Reward Calculation

Reward weight derives from exactly one internal value maintained by the validator for each miner, and that value is written to in exactly one place: the scoring routine described below. There is no separate code path that credits a miner for participation alone, and none that penalizes a miner for declining to submit a key.

7. Key Lifecycle

A contributed key passes through a well-defined sequence of states from submission to eventual retirement:

1. Submitted - the miner transmits an encrypted key through the validator.
2. Verified - the protocol decrypts and tests the key against the real provider, and checks for duplication.
3. Active - an accepted key is stored, encrypted at rest, and becomes eligible for use.
4. Monitored - recurring health checks and, eventually, genuine usage generate ongoing performance reports.
5. Retired - once a key stops functioning (quota exhaustion, revocation, or invalidation), the next report marks it inactive; its score is forced to zero and the miner's blended score decays over subsequent rounds rather than being removed abruptly.

No key is ever specially deleted from the scoring process. A retired key simply stops generating positive reports, and its effect on reward fades through the same averaging mechanism that governs every other change in performance.