Celestia says Fibre averaged 3.07 Tb/s for 143 seconds in an end-to-end test with 120 validators. The result measures experimental data throughput, not confirmed mainnet capacity or transaction speed.
When a Rollup publishes a batch, Celestia's ordinary block path is not the only route its data can take. Fibre moves large transfers off that path while keeping publication commitments on-chain.
That matters because a Rollup can execute transactions quickly and still hit a bottleneck when it cannot publish the data others need to verify its state. Fibre targets that constraint. The benchmark does not establish transaction speed, user fees, or production-scale reliability.
Fibre averaged 3.07 Tb/s for 143 seconds across 120 validators. Its best 60-second and 30-second averages were 3.69 Tb/s and 4.27 Tb/s, respectively.
Data off the block path
Celestia Fibre is a data availability protocol run by Celestia validators. Rather than send every byte of a large data blob through conventional block propagation, Fibre distributes encoded segments to validator services. The main chain records a commitment and confirmation information. Celestia's protocol overview describes this modular architecture, which separates data availability from the execution Rollups perform.
Data availability means users can obtain the information needed to check a blockchain's state. A hash or commitment alone does not provide that information. Erasure coding adds redundancy so missing pieces can be recovered, but recovery still depends on enough usable segments being served. Separating data delivery from consensus can raise capacity while shifting more of the burden to storage providers and network operations. Long-term retrieval performance matters alongside peak throughput.
An application starts the process by submitting a blob through a Fibre client. The client applies Reed-Solomon erasure coding, dividing the data into segments and adding redundancy. That redundancy is meant to let the original data be reconstructed if some segments are unavailable, provided the protocol's recovery conditions are met.
Fibre services on validators receive and store the segments, then sign to confirm receipt. Once validators representing at least two-thirds of voting power have signed, the client submits the signature set and data commitment to Celestia's chain. That commitment confirms publication. It does not contain the full blob or prove that every segment will remain retrievable indefinitely.
The Fibre testnet explorer displayed 8 Fibre nodes, with 99.7% of active stake reachable and all 81 checked nodes online. These are testnet observations, not evidence of mainnet performance or availability.
That is the system's central trade-off. Less large-scale data has to pass through consensus blocks, but validators take on greater bandwidth demands. They must also store data and keep retrieval services running. A signature records confirmation at publication time; users still depend on storage and retrieval arrangements when they need the data later.
What the benchmark shows
Celestia announced the 3.07 Tb/s average on October 1, 2026. The end-to-end test used 120 validators on separate AWS instances and measured the full publication workflow. Data was encoded and distributed to validators, which stored it and collected signatures. The client then submitted the on-chain commitment. Celestia had previously reported 1 Tb/s in partial-network tests, so the newer result covered a broader pipeline rather than raw network bandwidth alone.
The test used a 2 GiB blob, a one-second block time, and 2,000 Fibre submissions per block. Celestia also reported that ARM NEON vectorization cut median Reed-Solomon encoding time for a 2 GiB blob from about 6.8 seconds to 0.9 seconds. Those are benchmark parameters and reported optimizations, not a guarantee of continuous mainnet performance. Celestia also described the throughput as equivalent to nearly 2 billion transactions per second, based on an assumed transaction size. That is a calculation, not a measurement of transaction execution or real user activity.
Terabits per second measure data throughput, not transactions per second. Any conversion depends on how much data each transaction requires. A Rollup's actual throughput also depends on execution. State updates must be processed, proofs generated, and the network must confirm them. Treating Fibre's benchmark as a transaction-speed figure would confuse one infrastructure layer's capacity with the performance of an entire chain.
Rollup costs and open risks
More data availability capacity could ease a publication bottleneck when Rollups compete to post batches. Operators would have more room to organize data and choose publication strategies, but that does not guarantee lower user fees. Execution costs remain, as do proof-generation costs. Fibre validators also face bandwidth and storage expenses, plus maintenance costs that may show up in service pricing.
Celestia's original data availability path uses block data structures alongside Data Availability Sampling, or DAS. Light clients can use DAS to check availability without downloading an entire block. Ethereum's blob system publishes data through Ethereum's consensus framework and is being expanded through mechanisms such as PeerDAS. Fibre instead sends encoded segments directly to validator services and records commitments and confirmations on Celestia. These systems have different security and operating models; the benchmark does not rank one above another.
Node capacity and data recovery remain practical constraints. If too many participating nodes go offline, users may be unable to reconstruct a blob even when its commitment remains on-chain. The same risk applies if nodes discard data early. It also applies when they fail to serve their segments.
A benchmark using independent cloud instances cannot establish how the system will perform across varied real-world hardware. Network conditions and upload patterns will vary, while sustained demand presents another test. The testnet explorer's availability figures offer operational snapshots, but they do not answer those mainnet questions.
High-frequency trading applications could generate substantial volumes of records. App-specific chains could do the same. Automated services are another possible source. Still, not every operation needs to be published on-chain. A separate spatial-data project targets 3D information for AI systems. It illustrates a data-intensive use case, not evidence that such applications will adopt Fibre. Actual demand depends on what developers choose to make verifiable and retrievable, and what they are willing to pay to publish.
On October 7, 2026, Celestia released celestia-app v10.4.0 with an upgrade path to application version 10. Celestia followed with celestia-node v0.34.3, which added initial Fibre support. These releases prepared for a possible network upgrade; they did not confirm Fibre's activation on mainnet. As of October 8, the network still showed protocol version 9, with no upgrade scheduled.
