If an AI agent leaves a verifiable transaction record every time it calls an API, buys data or uses compute, how much data would a blockchain need to support? This is the question Celestia aims to address with Fibre.
On October 1, 2026, Celestia announced a new end-to-end Fibre benchmark: 120 validators averaged 3.07 Tb/s of data throughput over a 143-second load window. This article examines the result from both an architectural and an operational perspective, putting the headline number in the context of real applications.
NodeStake prepared this article using Celestia's official blog and protocol specifications. Benchmark results are reported by Celestia; the illustrations were created by NodeStake. Mainnet parameters and rollout plans remain subject to subsequent official announcements.
Start with DA: can the application's data be retrieved?
Data availability (DA) concerns whether published application data can be obtained by the people who need it for verification. A rollup cannot simply announce a new state result: verifiers also need the transaction data to check how that result was produced.
Imagine a shop that must make its accounts available for inspection. Calculating new balances is execution; checking that the calculation follows the rules is verification; letting others obtain the records is data availability. Fibre primarily expands the capacity of that last responsibility.
This is why one bandwidth figure cannot describe the speed of an entire application. Transaction computation, state updates, proof generation, data retrieval and wallet interactions can all affect the user experience. For more on DA and benchmark methodology, see Celestia's Why Blockchain Benchmarks Are Usually Deceiving.
Fibre separates data distribution from onchain records
Fibre is a data availability protocol operated by Celestia validators, running alongside Celestia's existing DA path. It targets applications publishing large amounts of data: the client sends encoded data shards directly to validators, then submits a data commitment and validator signatures to Celestia.
A blob is a batch of data to be published. A commitment is a compact cryptographic record tied to that data. It helps verify the identity of the data, while storage and retrieval services still provide the actual contents.
- Encode the data. The client encodes a blob into shards and adds redundant information for recovery.
- Distribute directly. Validators receive their assigned shards, check the relevant proofs and payment promise, and store the data.
- Collect signatures. The client gathers validator confirmations. The default safety threshold is two-thirds of total voting power.
- Confirm onchain. The client submits signatures and the data commitment through a PayForFibre message, then waits for the transaction to be confirmed.
For retrieval, the client requests shards from validators, verifies the received data, and reconstructs the original blob after collecting enough valid shards. This lets individual nodes handle only a portion of the storage and transmission workload. The flow is described in the Fibre client specification and server specification.
Erasure coding provides room to recover missing shards
Fibre's encoding scheme is based on ZODA. One key concept is erasure coding: recovery information is generated in addition to the original data, making reconstruction possible even when some shards are missing. Recovery requires enough valid shards and depends on the protocol's honest-node and security assumptions.
Think of a puzzle stored across several locations, with extra information that can help reconstruct missing pieces. The puzzle does not need to live on one machine, but the reader still needs to check the pieces it receives and meet the recovery conditions.
Redundancy also consumes bandwidth and storage. Effective throughput for original data should therefore be considered alongside the encoded network traffic and storage overhead. For the protocol overview, see the official introduction and DA specification.
What did the 3 Tb/s benchmark measure?
The test covered fresh-data encoding, distribution, storage, signature collection and onchain submission. The throughput figure counts only original blob data confirmed onchain. Extra recovery data and transmission traffic were excluded.
Read the unit carefully: the lowercase b in Tb/s stands for bits. Using decimal units, 3 Tb/s is approximately 375 GB/s. Confusing bits with bytes creates an eightfold difference; this result should not be described as 3 TB per second.
The team improved the entire pipeline: ARM NEON accelerated erasure coding, cached signature checks and parallel verification reduced onchain work, and S3 storage combined shards and spread writes to reduce request pressure. Block capacity and block time were also adjusted. The results and settings are detailed in Celestia Fibre Hits 3 Tb/s.
How should we read “nearly 2 billion transactions per second”?
Celestia uses transaction counts to illustrate the potential scale of this bandwidth. We can make an independent estimate: assuming 200 bytes per transaction, 375 GB/s can accommodate roughly 1.875 billion such transaction records each second. A different transaction size gives a different result.
Example assumption: 200 bytes per transaction
3 Tb/s / 8 = 375 GB/s
375,000,000,000 bytes/second / 200 bytes
= 1,875,000,000 transaction records/secondThis calculation expresses data capacity. Executing those transactions also requires sufficient application compute and state-management capacity. A complex contract call and a simple transfer can have different computational costs; publishing equally sized records does not give them equal execution speeds.
What does it take to turn a benchmark into a mainnet service?
Celestia explains that this run used an experimental performance branch, 2 GiB blobs, one-second blocks and a maximum of 2,000 Fibre submissions per block. Memory and concurrency were tuned for the benchmark machines. The initial mainnet blob limit is planned at 128 MiB, with capacity growing alongside demand.
The 143-second window demonstrates short-term performance under that configuration. A sustainable service also needs evaluation of long-running operation, node failures, storage growth, retrieval and recovery. Celestia's article on blockchain benchmarks discusses how storage, indexing and node synchronization affect practical capacity.
- Application developers: Measure upload, confirmation and retrieval times with your own data sizes and workloads, and evaluate publishing fees.
- Node operators: Observe network bandwidth, encoding CPU, storage writes, retrieval and failure recovery together to identify the actual capacity bottleneck.
- Infrastructure providers: Specify data-retention periods, historical-data access and recovery objectives. DA and long-term archival need separate designs.
Which applications could benefit from Fibre?
Celestia's introduction highlights AI agent payments, metered data services and high-throughput markets. More abundant data-publishing capacity gives developers room to explore finer-grained records. The examples below build on those directions; each application's feasibility still needs independent evaluation.
- AI agent service transactions: Keep verifiable records when purchasing data, calling models or paying for compute, supporting later reconciliation and auditing.
- High-throughput rollups: Provide publishing capacity for dense transaction or application-event streams, while scaling execution, proofs and indexing accordingly.
- Usage-based data markets: Connect data access to payment records so providers and users can reconcile actual consumption more easily.
These applications also need appropriate fee, privacy and access-control designs. Each application should decide how sensitive information is protected, which records are public and how long they should be retained.
NodeStake's view: capacity must scale across the entire pipeline
From an infrastructure operator's perspective, we pay close attention to where the next bottleneck appears after a performance improvement. Faster encoding can put pressure on networking and storage; faster confirmation can require better retrieval and indexing. Practical service capacity depends on how these components work together.
Fibre offers a direction worth watching: distributed data services handle large-scale transmission while the chain processes compact commitments and confirmation records. For developers and operators, the next valuable step is to test how that architecture meets their own needs under real workloads.
References
- Celestia Fibre Hits 3 Tb/s — October 1, 2026. Benchmark results, optimizations and test conditions.
- Introducing Fibre: 1Tb/s of blockspace — January 13, 2026. Protocol design and potential application directions.
- Why Blockchain Benchmarks Are Usually Deceiving — July 3, 2026. Benchmark throughput versus production capacity.
- Fibre DA Specification — Official protocol documentation. Implementation details and parameters can change between versions.
- Fibre Client and Fibre Server — Upload, signatures, storage and data retrieval.