> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phyi.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Protocol

> What lives on chain: submissions, rounds, task seeds, weights, consensus, and attestations.

The Bittensor chain is the protocol's coordinator and its source of truth. This
page lists what is recorded or derived on chain and how the pieces bind together.

## The submission record

A miner's submission binds its **code** under its hotkey and track, signed by the
hotkey. There is no container image — the validator owns the runtime:

```text theme={"system"}
submission = {
  hotkey, track,
  agent_hash:    sha256 of the agent code,
  entrypoint:    the agent_main function name,
  inference_key: metered key reference (spent through the proxy)
}
```

The `agent_hash` in every SSSA's attestation block is checked against this
record, which is how attribution to the miner flows even though the validator
signs the SSSA.

## Rounds and the task seed

Rounds are scheduled by the server, which issues every validator the same round id
and seed. The chain provides a fallback seed for local development.

| Value           | Role                                                                                              |
| --------------- | ------------------------------------------------------------------------------------------------- |
| Round id + seed | Issued by the server; seeds deterministic task selection and per-task probe derivation            |
| Block hash      | Fallback round seed when no server schedules the round: `round_seed = hash(block_at_round_start)` |

The round's parameters are published, so anyone holding them can recompute the
task set, which makes task selection auditable: a validator cannot substitute a
rigged set.

## Weight submission

Before the round closes, each validator submits its graduated weight vector for the
track. Late or missing vectors are simply outweighed by consensus. Yuma computes
the stake-weighted median per agent, clips weights above it, and allocates emission
in proportion to the clipped, stake-weighted aggregate. See
[Weights and Consensus](/core/weights-and-consensus).

## The attestation

The SSSA is written on chain, carrying:

```text theme={"system"}
attestation = {
  agent_hash,          # which pinned agent produced the verdict
  miner_hotkey,        # who submitted that agent
  validator_hotkey,    # who executed the run and observed the evidence
  signature,           # ed25519 over the canonical hash, by the validator
  canonical_hash       # sha256 of the NFC-normalised, key-sorted body
}
```

Verification is offline and serverless: recompute the canonical hash from the
published SSSA, check the signature against the validator's on-chain hotkey, and
check `agent_hash` against the round's pinned submission record. See the
[SSSA Schema](/core/sssa-schema).

## The contributor commitment

The subnet owner publishes the recognized-contributor set as an on-chain
commitment. Validators read it when applying the 5% contribution pool, so the
pool works without any server. See the
[Incentive Mechanism](/get-started/incentive-mechanism).

## Validator eligibility

| On-chain value   | Role                                            |
| ---------------- | ----------------------------------------------- |
| Validator permit | Granted by stake weight; required to validate   |
| vtrust           | Positive when actively setting weights          |
| Stake            | The weight of a validator's vector in consensus |
| Bonds            | Reward alignment with consensus over time       |

There is no central register: the chain alone determines who may validate.