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

# Challenge Mechanism

A storage network's promises are only as good as its evidence that nodes still hold the data they were assigned. The challenge mechanism is that evidence. It runs all epoch, inside every spool group in parallel, and reads keep flowing while it works.

The shape in brief: challenges verify possession round after round, scores from those rounds set rewards, and an on-chain random audit at each epoch's end backs the whole thing with slashing.

## How a round works

<Steps>
  <Step title="A random challenge goes out">
    A rotating leader announces a challenge derived from on-chain randomness: every node in the group must prove it still holds one specific piece of one specific slice. The selection can't be predicted, so a node can't quietly discard data and hope it won't be asked.
  </Step>

  <Step title="Everyone proves, to everyone">
    Each member answers with a Merkle proof for its sample, broadcast to the whole group rather than to the leader alone. Every node sees every proof and forms its own view of who passed.
  </Step>

  <Step title="The group signs what it saw">
    The leader assembles the round's result, and members sign it only if it matches what they observed themselves. Enough signatures certify the round. If the leader stalls or lies, the round times out and is skipped rather than blocking anything.
  </Step>
</Steps>

This can't be gamed by getting friends into your group. The group is sized so that honest members always outnumber the signing threshold, and the threshold always exceeds the largest dishonest coalition the design tolerates. Honest nodes can always certify a truthful result, no coalition can certify a false one, and no extra layer of verification is needed on top.

It's also cheap. Round certificates stay off-chain and small; the chain sees per-epoch results, not per-round traffic. And since group composition is fixed by the epoch's assignment, nodes can't choose who checks them ([how groups are assigned](/protocol/architecture/spool-groups)).

<Frame caption="One round: a random challenge, proofs shared with the whole group, one aggregate signature.">
  <img src="https://mintcdn.com/tapedrive/IVlwjOpRsvR7xk5g/images/challenge-round.svg?fit=max&auto=format&n=IVlwjOpRsvR7xk5g&q=85&s=0a2f802a85039b646f78153632e74980" alt="One challenge round inside a group: nonce fan-out from the leader, proofs broadcast member to member, agreement on the result, one aggregate signature landing on-chain." width="593" height="480" data-path="images/challenge-round.svg" />
</Frame>

## Scores and rewards

A node's challenge score is the fraction of rounds it passed. At epoch settlement, that score scales the node's reward for the data it stored, measured against a network-wide bar. Store your data and answer challenges, earn in full. Miss rounds, earn less. The reward formula and the sync requirement live in [token economics](/protocol/architecture/token-economics).

## The random audit

After each epoch closes, randomness fixed only at epoch end selects, for each node, one previously certified proof to reproduce on-chain. The selection was unknowable while the epoch ran, so there was never a safe moment to cheat. Failing costs the node its epoch: slashing and forfeited rewards.

This is what anchors the cheap off-chain rounds. Every certified round is a potential on-chain obligation after the fact, so certifying a round you can't back up is a bet against your own stake.

## Invalidation proofs

There's also an accusation path that doesn't wait for a round. Any group member that finds stored data mismatching its certified on-chain commitment can submit an invalidation proof to the Solana program, and peers attest inconsistencies to each other on request. Consequences escalate: blacklisted storage earns nothing, and persistent misbehavior ends with removal from the network by group vote ([the instructions involved](/protocol/architecture/solana-programs), [the operator's view](/protocol/architecture/storage-nodes)).

## Reads are never interrupted

Verification runs alongside serving. No read windows close while challenges run, because the mechanism needs only Merkle proofs against on-chain commitments, independent of how the data is encoded.

For the systems reader: the liveness assumption is partial synchrony, the same assumption Solana itself runs under, so the mechanism adds no new trust requirements. The formal treatment (threshold arithmetic, adversary model, guarantees) lives in the [white paper](/protocol/architecture/white-paper).