How It Works4 min readCelestia (TIA)

Celestia Fibre: Where the Data Goes After v10

Celestia’s v10 transition is visible in block headers. Fibre sends bulk data to validator servers and records signed evidence on-chain. What does that evidence establish?

Celestia Fibre: Where the Data Goes After v10

AI-generated conceptual illustration: bulky patterned ribbons sit in separate storage compartments while a small sealed receipt remains on the counter. The scene symbolizes distributed data and an on-chain record; it is not a real facility, protocol diagram or promise of permanent storage.

Key Points

  • Two public RPC providers returned matching headers: block 15,116,658 used app version 9; block 15,116,659 used version 10 at 03:45:49 UTC on October 20, 2026.
  • Fibre distributes encoded data to validator-operated servers. Normal PayForFibre settlement requires endorsements representing more than two-thirds of voting power.
  • Activation does not establish that every server is ready. Retention is limited, and the reported 3.07 Tb/s benchmark used settings different from the initial mainnet configuration.

Chronological Timeline

2026-10-01A large-scale Fibre experiment

Celestia reports a 3.07 Tb/s average over 143 seconds in a 120-validator AWS experiment with performance-specific settings.

2026-10-07The mainnet binary is released

The v10.4.0 release includes Fibre and explains preparation before app-version activation.

2026-10-20The v9-to-v10 boundary is observed

Block 15,116,659 carries app version 10 and a 03:45:49 UTC timestamp. Celestia also publishes its “V10 is live” Fibre setup notice.

A change visible between two blocks

Celestia’s v10 transition now has a checkable boundary. CoinYQ queried QuickNode and ITRocket on October 20, 2026. Both returned app version 9 for block 15,116,658 and version 10 for the next block, 15,116,659, timestamped 03:45:49 UTC. The providers also returned the same block hashes. Celestia’s official status page separately announced that v10 was live and operators could begin setting up Fibre servers.[1][2][3]

This is stronger evidence than the presence of a new executable. The October 7 v10.4.0 release could run the older application until the upgrade activated. The observed boundary establishes the app-version change; it does not measure Fibre traffic or show that every validator has a working Fibre endpoint. Those are separate operational questions.[4][2][7]

The large payload takes a separate route

Fibre gives data availability its own delivery path. Its client encodes a blob into recoverable pieces and sends those pieces to validator-operated Fibre servers. The protocol avoids requiring every server to hold the entire original blob. A reader with the blob’s identifier can request enough pieces to reconstruct it and verify the result against its cryptographic commitment, under the protocol’s honesty assumptions.[5]

A useful analogy is a delivery with a compact receipt: the receipt identifies the consignment without containing everything in it. Fibre similarly keeps the bulk data out of Celestia’s ordinary data square. What reaches the chain is a payment promise containing the commitment, accompanied by validator endorsements. The analogy describes the separation of jobs, not a guarantee that a paper receipt alone makes data retrievable.[5][6]

What the validators actually endorse

Before uploading, a user funds a Fibre escrow account. The client sends data pieces together with a payment promise signed by that account’s owner. Each server checks its pieces and the promise, then endorses the promise using its validator key. Once endorsements represent more than two-thirds of voting power, a PayForFibre transaction can settle the payment on-chain. This threshold is weighted by voting power, not by counting servers.[6]

The chain verifies the required evidence and charges the escrow. This record connects a commitment, payment promise and validator endorsements; it does not put all the original bytes inside the block. Readers still use Fibre to download them. There is also a separate timeout path: an expired, unsettled promise can be charged without validator endorsements, even if the upload never completed. A payment promise should not be mistaken for a promise to charge only after successful delivery.[6][5]

Availability has a time window

Fibre’s client documentation explicitly describes a limited retention window, controlled by a chain parameter, with servers free to keep data longer. Applications that need a durable history must retrieve and preserve it elsewhere. A permanent chain record is not a promise that the associated data pieces remain on every server forever.[5][6]

There is also work after activation. Operators run a separate Fibre service and register its address; clients discover servers through that registry. The October 20 setup notice addresses precisely this stage. A v10 block, a registered endpoint and a successful upload-and-download cycle are distinct observations. This article confirms the first, without claiming network-wide readiness for the others.[7][1]

How to read the 3 Tb/s headline

Celestia’s October 1 report described 3.07 terabits per second averaged over a 143-second window with 120 AWS validators, counting blob data that had reached on-chain confirmation. It used a performance branch: 2 GiB blobs instead of the initial mainnet setting of 128 MiB, one-second blocks and a higher per-block settlement limit. It was an experiment with stated conditions, not an observed mainnet throughput figure.[8]

The useful change is the separation itself: validator servers move and retain the large payload, while the chain settles a smaller signed record. The newly observed v10 boundary makes that design relevant to mainnet. Whether applications can use it reliably at scale will be answered by actual upload, retrieval and retention results, rather than by carrying a laboratory throughput number over unchanged.[5][6][2][8]

The next question

Continue reading

Explore the topic through other cases and contexts.

Sources & References

  1. [1]Source 1: Celestia — V10 is live: Mainnet Beta Fibre server setupCelestia · 2026-10-20Accessed 2026-10-20
  2. [2]Source 2: QuickNode public RPC — Celestia block headers 15,116,658–15,116,660QuickNode / Celestia networkAccessed 2026-10-20
  3. [3]Source 3: ITRocket public RPC — Celestia block 15,116,659ITRocket / Celestia networkAccessed 2026-10-20
  4. [4]Source 4: Celestia App v10.4.0 — mainnet release notesCelestia · 2026-10-07Accessed 2026-10-20
  5. [5]Source 5: Fibre client — publishing, retrieval and retention (v10.4.0 source)CelestiaAccessed 2026-10-20
  6. [6]Source 6: x/fibre — payment promises and validator endorsements (v10.4.0 source)CelestiaAccessed 2026-10-20
  7. [7]Source 7: Celestia documentation — running a Fibre serverCelestiaAccessed 2026-10-20
  8. [8]Source 8: Celestia Fibre hits 3 Tb/sCelestia · 2026-10-01Accessed 2026-10-20
← Back to all storiesExplore all coins →