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

# Spool Groups

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](/protocol/architecture/slicing)). 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.

<Frame caption="One coded track fans out into 20 slices across a group. Any 7 recover it.">
  <img src="https://mintcdn.com/tapedrive/mrykmMuePwrTWaFw/images/spool-group-fanout.svg?fit=max&auto=format&n=mrykmMuePwrTWaFw&q=85&s=0a2433c6fe1d74c533a89e8968bffdb2" alt="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." width="757" height="372" data-path="images/spool-group-fanout.svg" />
</Frame>

## 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](/protocol/architecture/challenges), [how the chain checks it](/protocol/architecture/solana-programs)).

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

## 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](/protocol/architecture/storage-nodes), [the voted parameters](/protocol/architecture/token-economics)).