Skip to main content
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 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).
  • 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).
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).

​
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).