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

# Slicing

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](https://docs.tape.network/protocol/architecture/tracks.md) is cut into slices and spread across the distinct nodes of a [spool group](https://docs.tape.network/protocol/architecture/spool-groups.md), 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](https://docs.tape.network/protocol/architecture/tape-replay.md)).

## 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](https://docs.tape.network/protocol/architecture/tracks.md), [placement](https://docs.tape.network/protocol/architecture/spool-groups.md)).

![Diagram: a track partitioned into stripes, one stripe encoded into twenty slices with data and parity slices visually distinguished.](https://mintcdn.com/tapedrive/IVlwjOpRsvR7xk5g/images/slicing-pipeline.svg?fit=max\&auto=format\&n=IVlwjOpRsvR7xk5g\&q=85\&s=011d918f29159e7e0e0769f9fdc42f77)

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](https://docs.tape.network/protocol/architecture/gateways.md) 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](https://docs.tape.network/protocol/architecture/spool-groups.md)), 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](https://www.usenix.org/conference/fast18/presentation/vajha)). 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.