Skip to main content
Full replication is durable but expensive: five copies cost five times the storage. Slicing gets comparable durability for a fraction of that. A coded track is cut into slices and spread across the distinct nodes of a spool group, and any 7 of the 20 slices rebuild the data. One exception up front: small writes skip slicing entirely and ride the chain instead (tape replay).

​
From track to slices

The encoding pipeline has four steps:
  1. The track is cut into fixed-size stripes.
  2. Each stripe is erasure-coded into 20 slices: 7 data slices and 13 parity slices.
  3. A short final stripe is zero-padded to full size. The padding is internal only; reads never return it.
  4. The client computes Merkle commitments over the result, registers them on-chain, and distributes the slices to the track’s spool group (registration and certification, placement).
Diagram: a track partitioned into stripes, one stripe encoded into twenty slices with data and parity slices visually distinguished.

A track becomes stripes; each stripe becomes 20 slices, 7 data and 13 parity.

​
Recovery

Any 7 of the 20 slices reconstruct a stripe. A read doesn’t need every node, only enough of them, and gateways exploit that by taking the first 7 valid slices to arrive. The cost works out to 20/7, about 2.8 times the original size. That’s the network’s effective replication factor. Plain replication at similar durability would cost several times more.

​
Repair

Disks die and nodes disappear, so slices get lost. When one does, the replacement is rebuilt by reading small fragments from many of the group’s nodes, not by downloading 7 full slices and re-encoding. That costs a fraction of the bandwidth of standard Reed-Solomon repair at the same storage overhead. Repairs happen constantly in any storage network, not just when hardware fails: spools change owners every epoch (sync and migration), and every move means rebuilding slices on the new node. Keeping each repair cheap is what keeps that churn affordable.

​
The code

Tracks are Clay-coded (the Clay codes paper). The scheme was chosen for three properties: repair reads a bandwidth-optimal minimum, recovery needs a standard any-7-of-20 threshold, and reads need no special decoding beyond assembling enough slices. Encoding parameters adapt with file size to keep padding overhead small. The current values are network parameters; the 20/7 profile here is the default at the time of writing.