Celestia Fibre Hits 3 Tb/s
Teams evaluating Fibre keep asking us the same question: how much throughput can they actually count on? One prospective customer with extreme throughput requirements asked us to find out, so we ran an end-to-end benchmark across 120 validators.
It sustained 3.07 Tb/s of throughput, enough data for nearly 2 billion transactions per second. Every transaction Visa processed in 2025 would fit in just over two minutes.
As agentic payments and global finance move onchain, we expect applications to generate orders of magnitude more transaction data than existing blockchain systems can support. We designed Fibre in order to handle that load. Earlier this year, Fibre demonstrated 1 Tb/s in a partial benchmark. For this production benchmark we tested the entire system end-to-end: encoding fresh blobs, distributing and storing their pieces, collecting validator signatures, and submitting commitments onchain.
Below, we outline how Fibre works, what we changed to make the pipeline faster, and how we ran the benchmark.
How Fibre Works
In Fibre, blob data goes straight to validators. Celestia only records a commitment to that data and the validators’ signatures. That separation is what makes Fibre’s terabit throughput possible: the chain has to only keep up with commitments and not with the data behind them.
The client encodes a blob and sends each validator their own share of pieces. Each validator checks their pieces, stores them, and signs to confirm that they have them. Once validators holding two-thirds of the voting power have signed, the client submits their signatures to Celestia along with the blob commitment.
Chasing the Bottleneck
The work behind this result started well before the latest benchmark. Since March, we’ve been cutting repeated verification work, reusing memory, and removing unnecessary copies so Fibre can handle more uploads at once. Each round of testing helped us see where the next bottleneck was.
One of the biggest gains came from encoding. Before a blob goes out, Fibre splits it into pieces and adds extra recovery pieces using Reed-Solomon coding, so the original can be rebuilt even if some pieces never arrive. This happens for every blob, so it adds up fast. Modern ARM chips, like the AWS Graviton machines we tested on, can process many values in a single instruction. The encoding library we use already did this for some operations, but the Reed-Solomon encoding Fibre relies on still works through the data one value at a time. We wrote vectorised kernels for that path using NEON, ARM's vector instruction set, and tuned the workload around them. Median encoding time for a 2 GiB blob fell from 6.8 seconds to 0.9, roughly 7.5x faster.
Once encoding and distribution got faster, the chain itself became the bottleneck. During testing, we saw uploads spend about 1 second encoding and 0.5 seconds distributing their pieces, then as long as 14 seconds waiting for confirmation. Data was arriving faster than the chain could process it.
So we turned our work to the chain. We started reusing successful signature checks rather than repeating them, and ran verification in parallel. We also optimized how validators check PayForFibre (PFF) transactions, the onchain messages that record each Fibre upload. Validating a block proposal from scratch, with nothing cached, dropped from 10.35 seconds to 1.12. We also raised the per-block capacity for Fibre submissions from 200 to 2,000, and reduced the block time to 1 second. In the final benchmark, uploads waited an average of 2.2 seconds for confirmation.
The storage component was also substantially improved. We picked network-optimized instances for their bandwidth, but their attached disks (EBS) couldn't write anywhere near as fast as data arrived, so instead we started storing blob pieces in S3 (AWS's object storage). S3’s performance started degrading at ~3,500 uploads per second. In order to reduce the number of requests, we packed 16 Fibre pieces into each object and spread writes across hash-based key groups and multiple buckets. All of these improvements together cleared the way for a full-scale run.
Running the Benchmark
We benchmarked the process end-to-end across 120 validators, each running on its own AWS machine, from encoding fresh blobs to submitting their commitments onchain, with blob generation and encoding running on the same machines as the validators. The complete pipeline averaged 3.07 Tb/s over the full 143-second load window. Its best 60 seconds averaged 3.69 Tb/s, and its best 30 seconds 4.27 Tb/s.
These numbers count only blob data that was confirmed onchain. They exclude the recovery pieces added during encoding and the traffic of sending pieces to validators, both of which would push the figure higher.
Several settings were specific to this benchmark and will not be available in the initial mainnet release. We used 2 GiB blobs (mainnet will start at 128 MiB), 1-second blocks, and a limit of 2,000 Fibre submissions per block, up from the current 200. Memory and concurrency settings were also tuned for the specific machines we benchmarked on. The run used Fibre’s end-to-end production pipeline, but from an experimental performance branch, and some of the optimizations described above are still being refined before release.
The bars show the full 143-second average and the maximum rolling averages over 60 and 30 seconds. The dashed line marks the full-window average of 3.07 Tb/s.
What’s Next
Demand for blockspace is about to outgrow what existing blockchains offer, driven by agents paying on users' behalf and more of global finance moving onchain. This benchmark shows Fibre can keep up: at 3 Tb/s, it can support an AI agent for every person on Earth, each sending a transaction every 4 seconds.
We’ll bring Fibre to mainnet with capacity matched to early demand, then grow as usage does. Our goal is to scale to 3 Tb/s and go past it as applications need it. If you need throughput at this scale, get in touch.
Contributors
This work was led by Vlad Krinitsyn, with contributions from Rachid Chami, Preston Evans, Hlib Kanunnikov, Alex Kiss, Rene Lubov, and Rootul Patel.