Newsroom
2 October, 2026 / News / AI / Tags: fibre, celestia, pieces, encoding, blob

Experimental end-to-end test of the data-availability system achieved the rate over 143 seconds using 2-gigabyte blobs on AWS machines, far above planned mainnet limits
Celestia reported that its Fibre data-availability system sustained an average throughput of 3.07 terabits per second during a controlled benchmark lasting 143 seconds. The test involved 120 validators, each operating on a separate Amazon Web Services machine, and covered the complete pipeline from data encoding through onchain commitment.
The figure represents measured blob data that received validator signatures and onchain confirmation. It excludes recovery pieces created during encoding as well as the network traffic required to distribute pieces among validators. Peak intervals performed higher: the strongest 60-second period averaged 3.69 terabits per second, while the best 30-second stretch reached 4.27 terabits per second.
Engineers ran the benchmark with one-second block times and increased the number of Fibre submissions allowed per block from 200 to 2,000. Clients uploaded 2-gigabyte blobs. Uploads required an average of 2.2 seconds for confirmation. The same machines handled both blob generation and encoding.
These parameters differ from those planned for the initial mainnet release, which is expected to limit blob size to 128 megabytes. The test also employed an experimental performance branch of the Fibre software and machine-specific memory and concurrency settings. Celestia described the exercise as a measure of ceiling capacity rather than a demonstration of current live mainnet traffic.
Performance gains stemmed from several targeted changes implemented over preceding months. Encoding relied on Reed-Solomon coding to split blobs and generate recovery pieces. Engineers vectorized the coding routines with ARM NEON instructions available on the AWS Graviton processors used in the test. Median time to encode a 2-gigabyte blob fell from 6.8 seconds to 0.9 seconds, a 7.5-fold improvement.
Once encoding and piece distribution accelerated, chain confirmation became the constraint. The team introduced caching of successful signature checks, parallelized verification steps, and streamlined processing of the onchain PayForFibre transactions that record each upload. Time required to validate a block proposal from scratch without cache dropped from 10.35 seconds to 1.12 seconds.
Storage presented another bottleneck. Network-optimized AWS instances provided sufficient bandwidth, yet their attached disks could not keep pace with incoming writes. The solution shifted piece storage to Amazon S3 object storage. Pieces were bundled 16 per object and distributed across hash-based key groups and multiple buckets to maintain write rates.
Fibre separates the bulk data path from the blockchain. Clients encode a blob and deliver individual pieces directly to validators. Each validator verifies and stores its pieces, then signs to confirm receipt. Once signatures representing two-thirds of voting power are collected, the client submits those signatures together with a commitment to the Celestia chain. The chain itself never processes the full data payload, only the compact proof of availability.
The architecture targets applications such as rollups that require a reliable place to publish data for verification by users and other parties. Celestia noted that future demand could come from expanded onchain activity, including automated agents. The stated objective is to expand Fibre capacity to 3 terabits per second and beyond in step with application needs, beginning with mainnet limits matched to early usage.
The engineering effort was led by Vlad Krinitsyn, with contributions from Rachid Chami, Preston Evans, Hlib Kanunnikov, Alex Kiss, Rene Lubov and Rootul Patel.
The benchmark establishes that the Fibre design can move large volumes of data under controlled conditions with 120 validators. Questions of sustained performance under geographic distribution, adversarial conditions, varied hardware and economic constraints remain for production operation.








