Staked, but not storing
On-chain, a gateway registers and stakes like a node but never joins the committee. It holds no spools, casts no votes, and owes no storage duties. The stake is what opens the door: storage nodes serve reads only to peers whose stake clears a network-voted threshold. So anyone who wants to serve reads has to stake first, and read capacity grows the same way everything else in the network does: participants showing up with stake (storage nodes, token economics).What a gateway serves
In user terms: whole objects and tracks, range reads, and listings. Range reads follow the stream manifest, so a range over a huge file fetches only the segments it needs. Listings and metadata come from the gateway’s local object index without touching the chain. You always receive decoded bytes; slices are internal (the API reference).How a read is assembled
On-chain state names the track’s group, and the group names the nodes. The gateway requests slices from them in parallel and reconstructs from the first sufficient set of valid responses. Over-requesting is cheap and cuts tail latency, and slow, missing, or dishonest nodes are not waited for. Every slice is verified against on-chain commitments before use, and the decoded result is verified before serving. Reconstruction happens stripe by stripe, so responses stream as they decode and per-connection memory stays bounded no matter how large the object is. Caching works on slices, not decoded objects. The slices that reconstruct a track add up to roughly the object’s size, so slice caching costs about what object caching would, while staying individually verifiable and reusable across range reads.
A read fans out across the group. The first seven valid slices win.