Skip to main content
When a track is erasure-coded, its slices are handed to a spool group. A spool is a slot of storage that a node hosts: the unit of assignment, of voting weight, and of migration when responsibility moves between machines. A spool group is a set of 20 spools on 20 different nodes that jointly hold the slices assigned to them. The 20 is fixed on purpose: it matches the erasure coding. Every coded track becomes 20 slices, one per spool, and any 7 of them rebuild the data (how slicing works). A node hosts at most one spool per group, so a track’s slices always sit on distinct machines. Losing a disk, a node, or several nodes doesn’t lose your data.
A coded track fanning out into slices, landing in one group's spools spread across distinct nodes, with a subset of seven slices highlighted as enough to recover the track.

One coded track fans out into 20 slices across a group. Any 7 recover it.

​
The group is the unit of trust

A group does two jobs: it holds data, and it votes. When a group receives a track’s slices, each member signs receipt. A supermajority (14 of the 20 members) gets aggregated into a single BLS signature, and that one signature lands on-chain to certify your data as available (what certification promises, how the chain checks it). The same pattern approves network-wide decisions: spool assignments, snapshots, parameter changes. When a group of independent, staked machines agrees on a result, the chain accepts it.

​
Which group gets your data

You don’t choose, and neither does anyone else. When a track is registered, the Solana program assigns it to whichever group currently holds the fewest bytes. Clients can’t steer data toward friendly nodes, and load stays balanced without a scheduler. The assignment is recorded on-chain. Finding your data later is a lookup: the track names its group, and the group names its nodes.

​
Who hosts the spools

Spools change hands at epoch boundaries, and nobody is trusted to hand them out.
1

Everyone computes the same answer

Each epoch, every node independently computes the next epoch’s complete spool assignment from on-chain randomness and the current stake weights. The allocation uses D’Hondt-style proportional assignment, deterministic to the byte and built to move as few spools as possible while tracking stake.
2

The answer is voted on

Nodes confirm the computed assignment group by group. Within each group, members exchange signatures, and one aggregate per group lands on-chain. Once every live group has approved, the assignment is canonical for the next epoch.
3

Then it takes effect

Spools that changed owners are transferred or recovered during the epoch’s sync phase, before serving begins. A spool that moved away stays on its previous owner for a safety window (accepting no new slices), so migration never races durability.
If you know Ceph, its placement groups are a good first mental model: a layer of indirection between data and disks, so placement scales. The mechanics differ from there. Ceph computes placement with CRUSH hashing against a cluster map that monitors maintain. Tapedrive derives placement from stake weights and on-chain randomness, every node computes it independently, and the result only counts once the groups have voted it in on Solana.

​
An elastic network

The number of spool groups is a live network parameter. Nodes vote a preferred group count as part of their per-epoch preferences; the votes are aggregated when an epoch commits and applied when it advances. The network starts life with a single group and grows as capacity and membership grow. The count never goes down. Committee membership and the rest of the network’s shape scale the same way: by vote, without hard caps (staking and committees, the voted parameters).