Celestia Mainnet Beta launched on October 31, 2023, under the name Lemon Mint. The Foundation presented it as infrastructure for a modular ecosystem: developers could choose their own execution environment while sharing a publication layer. Its launch account also described Modular Summit as a meeting point for execution frameworks, sequencers and infrastructure teams. That is a concrete source for the community's collaborative identity. The same announcement warned that the early network was experimental.

Its targets of enormous blocks, widespread light clients and many independent rollups were ambitions, not measurements. Understanding both parts keeps the origin story useful: Celestia offered builders more architectural freedom, while expecting operators and applications to manage new dependencies rather than inherit a finished universal platform.

A block header can commit to data without proving that anyone can obtain the underlying bytes. Celestia addresses that problem by publishing blobs and enabling light nodes to sample small pieces of erasure-coded data. Successful sampling provides a probabilistic availability check without requiring every participant to download every block. Namespaces help an application retrieve the data relevant to it and check that the returned set is complete. This division is the core of the modular argument. Celestia does not execute every application represented in its blobs.

A payment application still needs rules for balances, transaction validity and dispute resolution. Availability makes those rules independently checkable only when the application actually supplies and maintains the rest of its verification system.

The retrievability documentation makes a distinction that marketing summaries often lose. Data availability establishes that data was published; it does not promise that every node will keep the history forever. Since version six, light nodes sample a seven-day window and can prune older blobs. Archival nodes may continue serving them, but free archival service is not guaranteed. A rollup that needs new nodes to replay its history must therefore arrange retention. The documentation suggests professional archives, snapshots or peer-to-peer historical synchronization.

These are part of the application's operating budget, not evidence that sampling has failed. A developer comparing costs should include recovery and long-term access, rather than treating a low publication fee as a complete storage contract.

A PayForBlobs transaction carries a sender, a namespace, a size and a commitment to the submitted data. The payment transaction and the blob have different roles, even though both enter the block. Celestia's fee documentation describes a base transaction component and a variable component related to blob size. It also describes a gas-price-prioritized mempool, where higher-fee transactions can receive priority. This matters when evaluating claims that the service has a permanently fixed price.

Spare capacity can make costs predictable under ordinary conditions without abolishing competition during congestion. A production application should measure inclusion, retries and batch sizing under its own workload. The economic unit is published data with a particular service behavior, not a generic transaction count shared with every execution chain.

TIA is Celestia's native asset. Developers pay publication fees in it, holders can delegate it to validators, and governance uses it for decisions within the protocol's remit. The token documentation also says a new rollup may choose TIA as its own gas currency instead of immediately issuing another token. That is an option, not a requirement imposed on every application using Celestia. The distinction is important for economic expectations. More chains can use Celestia without all their users holding TIA directly or treating it as their main savings asset.

Wallets display TIA while protocol operations commonly use the smaller utia denomination. Keeping the network, its fee asset and an application's separate token model distinct prevents misleading comparisons of their supplies and activity.

The current supply documentation records two changes after the original inflation schedule. Lotus reduced issuance toward five percent in July 2025; version six reduced it again toward two and a half percent in November 2025, with a declining path toward a one and a half percent floor. These are implemented changes, not the original eight percent launch policy. The same source distinguishes circulating supply from allocated tokens still subject to restrictions. Locked allocations could be staked, and rewards became transferable on receipt.

Consequently, an issuance reduction and a vesting release answer different questions. One changes newly created tokens; the other changes the transferability of existing allocations. A holder assessing dilution needs both histories, rather than assuming that lower staking rewards cancel a scheduled unlock.

Celestia's slashing documentation explains that delegators share the consequences when their chosen validator is penalized. It distinguishes temporary removal for downtime from the more serious consequences of double signing. That makes validator selection an operating-risk decision, not simply a ranking of advertised yields. A delegator does not personally run the signing infrastructure, yet the delegated stake can be affected by how that infrastructure behaves. Node operators must protect keys, monitor availability and coordinate upgrades.

The specific parameters can change with protocol versions, so this chapter does not freeze an old unbonding duration into a permanent promise. The durable point is the allocation of responsibility: staking returns are accompanied by protocol conditions, commissions and dependence on an operator's continued competence.

The Foundation delegation program aims to support competent operators and widen participation in the active validator set. Its published criteria cover uptime, ecosystem contributions, geography, infrastructure and compliance. Selection is an institutional decision about Foundation-owned stake, rather than an automatic reward for every applicant. The rules also reserve discretion to withdraw delegation. For smaller operators, such support can make participation feasible; for the wider community, it creates a reason to examine concentration and renewal decisions.

Neither conclusion requires assuming that delegated operators vote identically. The relevant questions are observable: who receives stake, whether independent infrastructure is sustained, how applicants are evaluated, and whether a validator can survive the end of a cohort without abruptly abandoning service.

Celestia's upgrade guide describes coordinated releases and validator signaling. From version three onward, readiness signals from five sixths of voting power precede activation after the specified delay. A software binary can therefore exist before its rules become active on Mainnet. The history records another useful boundary: Hibiscus version seven was skipped on Mainnet after a testnet bug, with version eight activated instead. Version nine followed in July 2026. This is why release names alone are poor evidence for deployed features.

A careful operator follows the target chain, active application version and activation record. A reader should apply the same discipline when a roadmap, a testnet tutorial and a promotional announcement describe different stages of the same work.

The January 2026 Fibre announcement reported a networking experiment approaching one terabit per second across 498 cloud machines in North America. It disclosed substantial CPU, memory and network resources, and described rollout as future work. Those details are more useful than repeating the headline without its conditions. Fibre uses a separate publication path in which clients distribute encoded pieces to validator-operated servers and collect commitments. The announcement presents this as suitable for larger, demanding workloads alongside the existing sampling-based service.

A benchmark can establish that a design performed under the tested configuration. It cannot establish current Mainnet demand, universal application throughput or equivalent performance on ordinary consumer hardware. Those are separate claims requiring different evidence.

At this review, the Fibre guide says Mocha has activated application version ten and tells bonded Mocha validators how to register their servers. It emphasizes that an installed multiplexer binary can still run version nine until the chain activates the new rules. That warning directly prevents confusing software readiness with Mainnet deployment. The guide also makes resource costs tangible: receive buffers, separate disks and signing latency need planning. Operators are not merely switching on a slogan about infinite capacity.

They are supplying bandwidth, storage and timely signatures under a specified configuration. The documented Mocha activation is a real milestone; this article does not promote it into an unverified Mainnet launch or claim the laboratory throughput as an ordinary live-network service level.

The documented OP Stack integration sends transaction batches to Celestia while recording a commitment identifier on Ethereum. An op-node reads that reference and retrieves the corresponding blob from Celestia. This can separate the settlement location from the location of transaction data, which is precisely the cost and flexibility tradeoff the integration is designed to offer. It also means an application's security description must name both systems and the connecting software.

Saying that a rollup settles on Ethereum is insufficient to describe how its data can be recovered or challenged. The integration documents fallback paths, but their existence in a repository is not evidence that every deployment configures them identically. Builders should publish their actual settings and failure behavior for users to examine.

The September 2026 documentation marks the Succinct-operated SP1 Blobstream deployments as legacy. They no longer receive new commitments, and the associated Celenium explorer has ended. Blobstream had relayed Celestia data-root commitments to contracts on EVM chains, allowing applications there to verify inclusion proofs. The source code and historical audit records remain available, but availability of code is different from a maintained service. The documentation explicitly tells dependent integrations to operate or obtain their own verification path.

This is a material lifecycle change for anyone relying on an older tutorial. It illustrates a broader modular responsibility without condemning the design: each team must know which dependencies are protocols, which are operated services, and who continues supplying the latter.

Private Blockspace is documented as a proxy that encrypts application data, creates a proof and publishes the encrypted blob to Celestia. Authorized parties can decrypt it, while others check availability and the commitments defined by the scheme. This is different from publishing plaintext for anyone to inspect. It can suit applications where confidentiality matters, but the privacy and verification claims must be stated separately. A public observer does not automatically learn balances or reconstruct a private application simply because the encrypted bytes are available.

Developers must also manage key material and define what their proofs actually establish. The feature broadens the design space for data markets and accountable private systems; it does not remove the need to evaluate each application's custody, access and recovery model.

The Genesis Drop announcement invited eligible developers and addresses active across Ethereum rollups and Cosmos networks to join Celestia from its first block. It linked distribution to the work of building a modular ecosystem, rather than presenting the chain as an isolated replacement for every other network. The invitation helps explain a community identity built around shared tooling and cross-ecosystem participation. Eligibility records still have limits: an address is not necessarily a distinct person, and accepting an allocation does not prove lasting commitment.

The useful historical fact is the deliberate breadth of the invitation. Its long-term success has to be assessed through maintained software, working applications and continuing participation after the initial distribution, not the size of the eligible-address list alone.