> ## 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. # Tracks A track is the fundamental unit of stored data on Tapedrive: one piece of raw data written to a [tape](/protocol/architecture/tapes). The hierarchy the rest of these docs use is short: a tape holds tracks, and a coded track becomes slices held by a [spool group](/protocol/architecture/spool-groups). A track is raw data first. It *can* back an S3-style object, but it doesn't have to. Tracks written with a name become [objects](/protocol/architecture/objects) and show up in listings. Nameless tracks (stream segments, internal blobs, content-addressed data) are equally real; they never appear in listings. Diagram: a tape containing tracks, one coded track fanning out into slices across a spool group, one track highlighted as named and projecting to an object, another highlighted as nameless. ## Anatomy of a track The chain knows four things about every track: * **A lookup key**: the hash of its name for named writes, a content hash for nameless ones. * **A kind**: inline or coded, meaning how the bytes are stored. * **A state**: registered, then certified, and possibly invalidated later. * **Its size**: the original, un-encoded byte count. Tracks don't live as individual on-chain accounts. They're compressed into the tape's Merkle tree, so a tape full of tracks costs the chain one commitment, and any single track can still be proven against it. One state matters most: **certified is the network's proof of availability**. A registered-but-uncertified track isn't guaranteed retrievable yet. Every write path below ends at certification, and no upload is done until it gets there. ## Three ways bytes become a track You don't pick a path. The SDK and CLI choose by size, and all three converge on the same result: a certified track on a tape. ### Inline Small writes ride directly inside a Solana transaction. The bytes land on-chain, the track is certified immediately, and no erasure coding happens at all. Solana's transaction limits set the ceiling; the SDK's default cutoff is 825 bytes, a client-side setting you can change, not a protocol limit. [Tape replay](/protocol/architecture/tape-replay) explains why this path makes small files cheap and what the network does with these writes afterward. ### Coded Mid-size writes become a single erasure-coded track. The data is sliced ([how](/protocol/architecture/slicing)), commitments land on-chain, storage nodes receive their slices ([where](/protocol/architecture/spool-groups)), and the group certifies availability. The SDK caps a single track at 64 MiB, which is also the unit gateways serve. ### Stream Anything larger splits into 64 MiB segments, each written as a coded track, plus one **manifest track** that maps byte ranges to segments. Range reads of huge files resolve the manifest first and fetch only the segments they need. The segment tracks are nameless; only the stream as a whole carries a name. ## Append and delete Tracks are never updated in place. "Replacing" data means writing a new track under the same key, and listings resolve to the latest write. Deleting is real: an on-chain operation with a Merkle proof against the tape's commitment, after which the capacity returns to the tape for reuse. Every track inherits its tape's lifetime. When the tape expires, the data is deleted, and anyone can pay to [extend a tape](/protocol/architecture/tapes) before that happens. ## Reading tracks back Any track can be fetched through a gateway by its identifiers ([gateway API](/apis/gateway)). And because every track is provable against on-chain commitments, you can verify what you receive instead of trusting the gateway: the SDK's [verified reads](/sdks/reading) do exactly that. Inline tracks have one more escape hatch: their bytes live in the Solana ledger itself ([tape replay](/protocol/architecture/tape-replay)).