> ## 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.

# Solana Control Plane

Solana is Tapedrive's control plane. It keeps a replicated record of which nodes are
participating, which erasure-coded pieces they store, what has been certified, and the
state the whole network needs to agree on. The Tapedrive nodes themselves are the data
plane: they store and serve the bytes.

Solana is a good fit for this job because it replicates state across nodes, moves
quickly, and reaches consensus quickly. In practice, it gives Tapedrive the write-ahead
log needed to coordinate a horizontally scalable storage network. [Local Tapedrive](/tapenet/local)
uses the same model with tapesvm, a high-performance drop-in replacement for Solana.

If you're newer to Solana: a program is Solana's equivalent of a smart contract.
Program-owned accounts hold the shared state described on this page.

Every participant reads the same on-chain state and rebuilds from it, so the network needs no gossip protocol and no trusted operator. Any disagreement resolves against the chain.

## The program suite

* **The core program, `tapedrive`,** owns the network's state machine: tapes, tracks, groups, epochs, votes, and rewards.
* **The staking program, `staking`,** manages node staking pools and delegation ([how staking pays](/protocol/architecture/token-economics)).
* **The token program, `token`,** handles the TAPE token itself.

## What lives on-chain

Three kinds of record, in reader terms:

* **The network registry.** System parameters, the current epoch and its phase, committee membership with stake, spool ownership per group, and a routing directory of peer addresses. Together these answer "who is the network right now" from chain state alone.
* **The data registry.** Every tape (capacity, usage, expiry, delegate, and its Merkle tree of tracks) and every track commitment. Together these answer "what is stored, and how do I verify it".
* **Economics.** The storage price and capacity, the reward pool, and the live votes ([token economics](/protocol/architecture/token-economics)).

These registry accounts are dynamic: they grow through permissionless resize instructions as the network grows. There are no compile-time capacity constants anywhere in the account model, which is the on-chain half of the no-hard-limits design ([an elastic network](/protocol/architecture/spool-groups#an-elastic-network)).

## What the programs enforce

Grouped by who calls them:

* **Users** reserve and extend tapes; register tracks, which deducts capacity and assigns a spool group in the same instruction; certify tracks with a group's aggregate BLS signature, verified on-chain; and delete tracks with a Merkle proof against the tape's commitment.
* **Nodes** register, stake, and join the committee; attest sync; submit and vote on snapshots and assignments; file invalidation proofs against bad data; claim epoch rewards; and unstake and leave.
* **Anyone** can call the permissionless instructions: resizing registry accounts, extending any tape, and settling per-node reward claims. These instructions check the proof or signature, not the caller. If the proof is valid, the program doesn't care who submitted it.

## Reads never touch the chain

Nothing about a read writes on-chain. Reads resolve against account state, directly or through a gateway that already tracks it, so read throughput is bounded by gateways and storage nodes rather than by Solana. The chain's write load is bounded per write and per epoch: registration and certification per track, and a fixed set of votes and settlements per epoch ([how reads flow](/protocol/architecture/gateways)).