Skip to main content
Tapedrive has a control plane and a data plane. Solana is the control plane: it keeps track of the nodes, the state of the network, and which erasure-coded pieces each node stores. Tapedrive nodes are the data plane: they store and serve the data itself. Tapenet is the open data plane made up of independent Tapedrive nodes. Local Tapedrive uses the same design with tapesvm, a drop-in replacement for Solana. Both use the same object model and the same tools. Here’s the whole system in one pass. Users hold wallets and sign transactions. Data lives as tracks on prepaid tapes. Erasure-coded tracks are cut into slices spread across spool groups of storage nodes. Gateways serve reads to the public. The challenge mechanism continuously verifies that nodes hold what they claim. And the entire network state is event-sourced: every participant rebuilds it by replaying the chain. Each section below compresses one detail page. Follow the links when you want the full story.

​
Key components

Four actors make up the network:
  1. Solana programs hold system state and perform the operations that matter for correctness: tape reservations, track registration, certification, votes, and rewards (Solana programs).
  2. Storage nodes are staked committee members that host spools of slices, follow the chain, and vote in their groups. They are not public read infrastructure: they serve staked peers, and users never talk to them directly (storage nodes).
  3. Gateways are the network’s public face. They follow the chain like nodes do, hold the object indexes, read slices from storage nodes as staked peers, and serve decoded data over HTTP to anyone (gateways).
  4. Clients are the SDKs and CLI. The wallet is the identity: writes are signed Solana transactions, and there are no accounts or API keys anywhere in the protocol.
Flowchart: clients connect through the public internet to gateways, gateways reach storage nodes as staked peers, and clients, gateways, and storage nodes all coordinate through the Solana programs.

Clients reach gateways over the public internet. Gateways reach storage nodes as staked peers. Everyone coordinates through the Solana programs.

​
The data model

One sentence per level. A tape is the prepaid container you reserve: capacity for a length of time. A track is one piece of raw data written to a tape. A coded track is cut into slices held by a spool group. A named track becomes an S3-style object, with listings and metadata. Details: tapes, tracks, slicing, objects, spool groups.
Diagram: a tape containing tracks, one track fanning out into slices across a spool group's nodes, and one named track projecting into an object listing.

A tape holds tracks. A coded track fans out into slices across a spool group. A named track becomes an object.

​
Writing

You reserve a tape once, before your first write (0). Small writes travel inside the transaction itself and are certified the moment it lands (tape replay). Larger writes take the erasure-coded path in the figure below, which involves your client, Solana, and one spool group of storage nodes. Every other group is untouched, however large the network grows. The client encodes the data into slices and computes commitments on its own machine (1). Registering the track on Solana (2) deducts tape capacity and assigns the least-loaded spool group. The client sends the slices to that group’s nodes (3), and each node checks its slice against the on-chain commitment before accepting it. When q of the nodes (14 of 20 on Tapenet) have returned signed acknowledgements, the client records them on Solana as one aggregate signature (4). That signature certifies the track, and certification is the network’s proof of availability. A node that missed the write catches up afterwards (5), with the same check against the on-chain commitments. See tracks for the write paths and spool groups for placement.
Diagram of a coded write between a client, one spool group of storage nodes, and Solana. Step 0: reserve a tape. Step 1: the client encodes and commits. Step 2: it registers the track on Solana. Step 3: it sends data to the group's nodes and collects q signed acknowledgements. Step 4: it certifies with an aggregate signature on Solana. Step 5: a node that missed the write catches up by replay. Other groups are untouched.

Orange arrows carry the data to O₁ through Oₙ, the storage nodes in one spool group, and the write counts once q of them have signed (14 of 20 on Tapenet). Dashed lines are steps before or after the write.

​
Reading

You read through gateways. A gateway keeps up with Solana in the background by tape replay (0), and a read submits no transaction. Your client sends an ordinary HTTP GET for a name or a track (1), straight to a gateway or through a CDN. The gateway finds the track (2) in the on-chain state, which records the track’s spool group and that group’s nodes. It asks those nodes for slices in parallel (3) and rebuilds the data from the first k valid slices to arrive (4), where k is 7 on Tapenet. A slice counts as valid once the gateway has checked it against the on-chain commitments, and nodes that are slow, missing, or dishonest get routed around. The gateway then checks the decoded result and streams it back to your client (5). Tapenet’s hosted public gateway serves light traffic free and anonymously under rate limits; sustained workloads use a paid gateway tier or run their own. A client that holds stake can read from the group itself without a gateway, along the dashed direct read line in the figure. Clients that want to check the bytes against the chain themselves can do verified reads through the SDK. Inline tracks can also be recovered from the Solana ledger itself (tape replay).
Diagram of a read between a client, an optional CDN, a gateway, one spool group of storage nodes, and Solana. Step 0: the gateway follows Solana by tape replay, and reads submit no transaction. Step 1: the client sends a GET for a name or track. Step 2: the gateway resolves the track. Step 3: it requests slices from the group's nodes. Step 4: it takes the first k valid slices. Step 5: it streams verified bytes to the client. A dashed line shows a direct read from the client to the group.

Orange arrows are the data coming back, and k is how many valid slices rebuild it (7 on Tapenet). The dashed lines are the gateway keeping up with Solana in the background and a direct read by a client that holds stake.

​
Epochs

The network runs on a clock. Time is divided into epochs, and everything network-wide changes at epoch boundaries, by vote: committee membership, spool assignment, capacity, and pricing. Each epoch moves through four phases (sync, snapshot, active, closing), and the network never advances past an epoch whose record isn’t sealed.