Celestia (TIA) sustainability report

Celestia is present on the following networks: Celestia, Cosmos, Osmosis.

Celestia narrows what a blockchain does. It provides ordering and guarantees that data has been published, and leaves execution to the rollups that post to it, so the network never runs the transactions whose data it carries. Consensus is Byzantine fault tolerant proof of stake of the kind used across its framework family: a proposer drawn from the validator set puts forward a block, validators exchange two rounds of votes, and the block commits once votes representing more than two thirds of bonded power have been collected. Finality is deterministic and arrives with the commit, so there is no confirmation depth to wait out. Safety holds while validators controlling less than a third of bonded power deviate; beyond that the chain halts rather than forking.

What distinguishes the design is how availability is verified. Block data is erasure coded into a two-dimensional matrix, and light nodes verify availability by sampling: each requests a handful of randomly chosen coordinates with their inclusion proofs, and a small number of successful samples establishes to high probability that the whole block is retrievable, because withholding any meaningful portion would cause a sample to fail. This lets a participant with modest resources check availability without downloading the block, and because such a node checks only that data was published rather than that it was valid, it does not depend on an honest consensus majority for the correctness of any rollup's state. Data is organized so that a rollup can retrieve the portion addressed to it without processing the rest.

Two limitations are acknowledged in the network's own documentation. A protocol allowing a sufficient number of light nodes to collectively reconstruct a block is still being developed, and a dishonest supermajority of validators could in principle commit a block with missing data, which honest full nodes would reject. Stake is genuinely at risk: the framework's penalties apply, confiscating a portion of bonded stake for signing conflicting blocks and imposing a smaller penalty with temporary removal from the set for prolonged unavailability.

The Cosmos Hub is a sovereign chain built with the Cosmos SDK and driven by CometBFT, the Byzantine fault tolerant engine that was published for several years under the name Tendermint Core and was renamed in 2023. Agreement is reached in rounds rather than by mining. One validator drawn from the active set proposes a candidate block, the set broadcasts a prevote and then a precommit on it, and the block is committed once precommits representing more than two thirds of bonded voting power have been gathered. Finality is therefore deterministic and arrives with the commit itself: there is no confirmation depth to wait out and, in normal operation, no competing tip to resolve. The safety guarantee holds so long as validators controlling less than one third of bonded voting power depart from the protocol. Beyond that threshold the chain stops producing blocks rather than splitting into two histories, which is the trade the engine deliberately makes in favor of consistency over continuous availability.

Anyone may declare a validator, but the set is capped. Candidates are ranked by the stake bonded to them, counting the operator's own bond together with stake delegated by holders of the network's native asset, and only the highest ranked occupy the active slots, of which there are currently one hundred and eighty. Voting weight inside a round is proportional to bonded stake, so delegation is how holders influence who validates without running infrastructure themselves. Stake withdrawn from a validator stays locked for three weeks, which keeps it answerable for faults committed before the withdrawal began.

For several years the Hub's distinguishing feature was that it lent this validator set to other chains, whose operators ran an additional node alongside the Hub node. That arrangement has ended. A software upgrade adopted through on-chain governance and executed in September 2026 removed the provider module from the protocol, closed the communication channels it used, and resized the active set to match. Hub validators now secure the Hub alone, and the chain's position in the wider ecosystem rests on routing messages and assets between independent chains rather than on renting out consensus.

Osmosis is a sovereign chain built with the Cosmos SDK, reaching agreement through CometBFT, the Byzantine fault tolerant engine that carried the name Tendermint Core until its rename in 2023. Blocks are committed in rounds: a validator from the active set proposes, the set votes in a prevote stage and then a precommit stage, and the block is finalized the moment precommits representing more than two thirds of bonded voting power are collected. Nothing is probabilistic about this, so a committed block cannot be reorganized away and no confirmation depth needs to be observed. The guarantee the engine provides is that honest validators never commit conflicting blocks while fewer than one third of bonded voting power misbehaves; past that point the chain halts instead of forking.

Validators are ranked by the stake bonded to them, self-bonded and delegated counted together, and the highest ranked fill a fixed number of active slots, which on this network is seventy, a deliberately tighter set than several of the chains it interoperates with. Delegation lets holders of the native asset assign their weight to an operator and share in that operator's rewards, and it carries the same downside the operator carries. Bonded stake takes a fortnight to unwind, roughly half the period used elsewhere in the ecosystem.

What sets this network apart from a general-purpose Cosmos chain is that its exchange lives inside the state machine rather than in contracts deployed on top of one. Pool creation, routing a swap across several pools, concentrated liquidity positions, and the accounting of trading fees are all protocol modules that validators execute as part of processing a block, so a trade is a consensus-level state transition carrying exactly the same finality as a transfer. The protocol also runs an arbitrage module of its own, which inspects a proposed block for price discrepancies its pools have opened and captures the correction for the protocol rather than leaving it to outside searchers. A number of recurring operations, issuance and reward distribution among them, are processed once per daily epoch instead of every block.

Celestia is present on the following networks: Celestia, Cosmos, Osmosis.

Validators earn from protocol issuance plus the fees paid for the data posted during their blocks. Issuance was cut by roughly a third at a 2025 upgrade, which also removed a previous requirement that rewards be claimed automatically and adjusted the treatment of rewards belonging to locked accounts. Holders may delegate to a validator without operating infrastructure, sharing rewards after a declared commission, and delegated stake is exposed to the same penalties as the validator's own, so choosing an operator carries real risk rather than only an opportunity cost. Unbonding takes a fixed waiting period during which funds remain slashable, which prevents an operator from withdrawing ahead of a penalty being applied.

The fee model is where this network departs most sharply from a general-purpose chain, and it follows directly from what the network sells. Users are not paying for computation, because no computation on their behalf takes place here. They are paying for space: a rollup submits a blob of data and is charged according to how many bytes it occupies, at a price per unit that rises when demand for space exceeds what blocks can carry. A submitter sets the price it is willing to pay and blocks fill in the usual way, so the market clears on space rather than on execution resources. This makes cost highly predictable for a rollup, since the charge follows directly from the size of what it publishes and does not depend on how complex the transactions inside that data happen to be.

Penalties are those of the underlying framework. Signing two conflicting blocks at the same height results in confiscation of a proportion of bonded stake, applied to the validator and its delegators alike, together with permanent ejection. Extended failure to participate in voting results in a smaller confiscation and temporary removal from the active set, with reentry possible once the operator resumes. There are no recurring storage rents charged to holders; the cost of retaining published data is borne by the network's own participants and funded through issuance and blob fees.

Block production is paid for from two sources: newly issued units of the network's native asset, and the fees attached to the transactions in each block. Issuance is not a fixed schedule. The protocol aims at a target proportion of total supply being bonded, set at two thirds, and moves the annual issuance rate up or down inside a governance-defined band whenever the bonded proportion drifts away from that target, so the reward for bonding strengthens when too little stake is committed and weakens when the target is passed. Everything issued in a block is pooled with the fees collected in it, a small fixed slice is diverted to a community fund that governance spends, and the remainder is divided among active validators in proportion to bonded stake. Each validator retains a commission, which the protocol requires to be at least five percent, and the balance accrues to its delegators for them to withdraw when they choose.

Penalties are graded by how damaging the fault is. A validator that signs two conflicting blocks at the same height forfeits five percent of the stake bonded to it, delegators included, since delegation is genuine economic exposure rather than a vote of confidence, and it is permanently barred from the active set rather than merely suspended. Failing to sign enough blocks across a long measurement window costs a far smaller fraction and results in temporary jailing, from which the operator returns by submitting an unjail transaction after a short wait. Because unbonding runs for three weeks, stake that has started to leave a validator remains liable for faults committed before it left.

Users pay for execution in gas, denominated in the native asset. The Hub prices gas with an adaptive base rate that climbs as blocks fill and decays as they empty, resting on a governance-set floor, and the base portion of each fee is retained by the protocol instead of being passed through to validators; a sender may attach a tip above the base rate to compete for inclusion when demand is heavy. Smart contract calls are metered by the resources they consume, and there is no separate recurring rent charged on stored data.

Three groups are paid on this network, and the balance between them has shifted markedly. New units of the native asset are minted on a daily cadence along a schedule that steps down by a third every seven hundred and thirty days, and governance decides how each day's issuance is split. Liquidity provision was once the largest claim on that issuance; it has since been removed from the split entirely, on the argument that trading revenue rather than subsidy now sustains the pools. The staking share has been cut back as well, with most of each day's issuance now directed into the community fund alongside a fixed development allocation. Bonded stake is increasingly compensated from revenue instead: transaction fees collected in the native asset accrue to stakers, and fees paid in other accepted denominations are converted first.

That revenue comes from trading. Every swap pays a spread factor to the providers of liquidity in each pool it touches, and separately a taker fee to the protocol, set by default at a tenth of a percent and overridden route by route by a delegated fee committee that prices heavily traded pairs down and thin ones up. Taker fees collected in the native asset are split so that the larger part is destroyed and the remainder is paid to stakers. Taker fees collected in other assets are divided between the community fund and a buyback that acquires the native asset before splitting it the same way, which ties the rate of destruction directly to trading volume. Liquidity providers may bond their positions for additional incentives, and a superfluid arrangement lets the portion of a bonded position represented by the native asset be delegated to a validator at the same time, so one unit of capital both secures consensus and backs a pool.

Ordinary transactions pay gas at a base price that climbs when blocks fill and falls back when they empty, resting on a governance-set minimum, a mechanism intended to price out spam rather than to raise revenue; fees may be paid in a whitelisted set of denominations, not only the native one. Validators must charge at least five percent commission. Signing two conflicting blocks costs a validator and its delegators a share of bonded stake and permanent exclusion from the set, while missing too many blocks results in jailing rather than confiscation.

Celestia is present on the following networks: Celestia, Cosmos, Osmosis.

The population to be counted here is more varied than on a chain that only validates. Three roles consume resources and each has to be sized separately. Validators run the consensus process, and their number is bounded by an active set parameter readable on-chain, so that count is known rather than estimated. Full storage nodes retain published data and serve it on request, and they are the role that makes availability meaningful, since data nobody retains cannot be retrieved; their number is estimated from public listings and network observation. Light nodes perform availability sampling, and there may be many of them, but each does very little work: a handful of small requests per block on hardware that may be an ordinary personal machine, so their aggregate contribution is small despite their count.

Representative hardware follows from the published requirements for each role, which differ substantially. A validator specification is demanding in processor and memory terms; a storage node's defining requirements are disk capacity and sustained network bandwidth rather than computation. Measured power draw for machines matching each description, under load and at idle, is applied across the respective populations.

One characteristic of this network shapes the result and is worth stating. The resource that scales with usage is storage and bandwidth rather than computation, because the network's function is to publish and retain data. As throughput grows, storage nodes hold more and transfer more, and their consumption rises with it in a way that a validator's does not. Data retention is also a continuing obligation rather than a one-time cost, so today's consumption partly reflects data published in earlier periods and still being retained and served.

The limitations are the usual ones. Node populations outside the capped validator set are observed from the outside and cannot be audited, operators running several roles on one machine are counted imperfectly, and where evidence is thin conservative assumptions are used that are more likely to overstate than understate. Figures are revised as observation improves.

The energy figure reported for this network is an estimate assembled from the machines that run it, not a metered measurement. The starting point is the size and composition of the node population: the validators in the active set, the candidates bonded but outside it, and the full, archive, and relay nodes that serve queries and forward packets between chains. That population is approximated from peer discovery on the public network, from the information operators publish about themselves, and from the chain's own records, since validator identity and bonded stake are recorded on-chain even when the machine behind them is not.

Each node is then given a hardware profile. The client software states the processor, memory, disk, and bandwidth a node needs to keep pace with block production, and a machine consistent with those requirements stands in for the node. Electrical draw for such a machine is taken from controlled measurement of comparable equipment across its load range, idle draw included, because a validator is powered continuously whether blocks are full or nearly empty. Multiplying representative draw by the estimated population across the hours of the reporting period gives a network total, and the share attributed to an individual asset is apportioned from observed on-chain activity.

Two limitations should be stated plainly. The population count and the hardware mix are inferences drawn from public observation and published requirements, not from disclosure: operators are not obliged to say what they run, several may sit in one facility, and rented virtual capacity is difficult to separate from dedicated hardware. Where evidence runs out, the assumption chosen is the one that raises the estimate rather than lowers it, so the reported figure is more likely to sit above the true value than below it. One component that appeared in earlier assessments of this network no longer applies. Because the Hub used to secure other chains, a proportion of their consumption was attributed to it and apportioned by gas usage; the provider arrangement was removed from the protocol in 2026, and the estimate now covers the Hub's own infrastructure alone. Figures are restated as observation improves.

The reported consumption for this network is a modeled estimate rather than a measurement taken from a meter, and it is built from the machines that keep the chain running. The first task is to size that machine population. It comprises the seventy validators in the active set, the bonded candidates waiting outside it, and the full, archive, and indexing nodes that serve the trading interfaces, routing services, and relayers connecting this chain to its neighbors. The count is approximated from peer discovery on the public network, from what operators publish about their own deployments, and from the chain's own on-chain register of who is bonded.

Each machine is then represented by a hardware profile. The client software publishes the processor, memory, disk, and bandwidth a node needs to stay in sync, and a machine meeting those requirements stands in for the node. This chain sits at the demanding end of the range for its family, because validators execute swap routing, concentrated liquidity accounting, and the protocol's own arbitrage checks inside block processing rather than delegating them to a contract layer, and because several recurring tasks are batched into a daily epoch that produces a pronounced load spike. Electrical draw for the representative machine comes from controlled measurement of comparable equipment across its load range, idle draw included, since nodes are powered continuously. Draw multiplied by population over the reporting period gives the network total, from which a per-asset share is apportioned using observed on-chain activity.

Two caveats matter. The population and the hardware mix are inferred from public observation and stated software requirements, not from operator disclosure, and where evidence is missing the assumption chosen raises rather than lowers the estimate, so the figure is likelier to overstate than understate. Second, a correction: earlier assessments attributed to this network a share of another chain's consumption on the grounds that the other chain contributed to its security. That is not how this network is secured. It has its own validator set, its own bonded stake, and its own penalties, and the estimate here covers only the machines that run it. Figures are restated as observation improves.

Celestia is present on the following networks: Celestia, Cosmos, Osmosis.

The three node populations are located by different means and with different confidence. The validator set is capped and its members commonly publish identity information, because delegators choose operators on reputation, so its geographic distribution is derived substantially from disclosure rather than inference. Storage nodes are located through network observation and hosting provider address ranges, with rather less certainty. Light nodes are the least observable, but also the least significant: each draws little power and many run on machines that would be switched on regardless, so an error in their distribution moves the result very little.

Each located machine is matched to published statistics for the grid supplying its region, and the renewable share reported is the average across those grids weighted by the consumption attributed to each location rather than by machine count. Because storage nodes consume disproportionately relative to their number, the weighting shifts the result toward wherever bandwidth and disk capacity are cheapest, which is not necessarily where validators cluster; treating the two populations as one would distort the answer.

Limitations apply as elsewhere. Disclosure is voluntary and self-selecting. Commercial hosting facilities do not publish their supply arrangements, so a regional grid average substitutes for the actual supply of a given building. Grid statistics are annual and regional and conceal daily and seasonal variation. Contractual renewable purchases are not counted, since the method describes the physical grid mix a machine draws from.

Energy intensity per transaction requires an adjustment in reading for this network. What the network processes is not transactions in the ordinary sense but published data, and the natural unit of its work is a byte rather than a transfer. Dividing period consumption by transactions settled produces a figure comparable with those published for other networks, but the quantity that actually drives consumption is data volume, so the intensity figure moves with the average size of what is published as much as with the count of transactions. It is an average across the period, not the energy caused by one further transaction. Source data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy: Share of electricity generated by renewables.

The renewable share reported for this network follows from where its machines sit, because electricity is not generated the same way everywhere. Node locations are approximated from publicly observable network data: the addresses peers advertise when they connect, the hosting ranges those addresses belong to, and whatever operators choose to disclose about their facilities. What this yields is a distribution of the node population across countries and regions, not a street address for any individual machine. Where that distribution cannot be resolved with enough confidence, the observed distribution of a network built and rewarded along similar lines is used in its place, on the reasoning that comparable economics tend to place infrastructure in comparable locations.

Each region in the distribution is matched to published statistics describing how its electricity is generated, and the network's estimated consumption is weighted across those regions to give the proportion supplied from renewable sources. The generation data is drawn from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy.

Energy intensity is a separate quantity and is easy to misread. It is not total consumption divided by the number of transactions. It is a marginal figure: the additional energy the network draws when one more transaction is included in a block. On a chain of this design the distinction matters a great deal, because the validator set is powered continuously and commits a block on a fixed cadence whether that block is full or nearly empty, so the great majority of the draw is a fixed cost that an extra transaction does not move.

The weak point of the method is the geolocation step. Address-based location is approximate and identifies the hosting provider rather than the customer; operators sitting behind commercial cloud regions are attributed to the advertised region rather than to any particular building; and grid statistics are national or regional averages that take no account of supply contracts a specific facility may hold. Where a stand-in distribution is used, its representativeness is itself an assumption rather than an observation.

Because electricity is generated differently from one grid to the next, the renewable share reported for this network depends on establishing where its machines are. Locations are inferred from publicly observable network data: the addresses validators and other nodes advertise to their peers, the hosting ranges into which those addresses fall, and whatever operators choose to publish about their own infrastructure. The output is a distribution of the node population over countries and regions, never a precise site for a given machine. Where the distribution cannot be established with confidence, the observed distribution of a network with a comparable consensus design and comparable rewards is substituted, on the assumption that similar economics lead operators to similar places.

Every region in that distribution is then paired with published statistics on the composition of its electricity generation, and the network's estimated consumption is weighted across the regions to yield the proportion met from renewable sources. The generation statistics are taken from Share of electricity generated by renewables, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy.

Energy intensity is reported as a marginal quantity and should not be read as consumption divided by transaction count. It answers a narrower question: how much additional energy the network draws when one further transaction is included in a block. That distinction is particularly sharp here. Validators run continuously and commit blocks on a fixed cadence whether or not there is trading to process, so nearly all of the draw is a standing cost, and the incremental cost of one more swap, which is executed by the same validator process as any other message, is very small by comparison.

The method's weakest link is geolocation. An address identifies a hosting provider rather than a customer, machines behind large commercial cloud regions are assigned to the advertised region rather than to a physical building, and the grid statistics are averages over a country or region that ignore any supply arrangement an individual facility has made. Where a stand-in distribution has been used, its representativeness remains an assumption.

Celestia is present on the following networks: Celestia, Cosmos, Osmosis.

Emissions are derived by applying a grid carbon intensity to the electricity attributed to each location in the distribution established for the renewable share, across all three node populations, and summing. The boundary covers operational electricity. Manufacture of the servers and, relevant here, of the storage media that retention depends on is excluded, as is construction of the facilities involved.

Scope 1 covers emissions from sources under the direct control of node operators, in practice occasional on-site backup generation. It is a negligible contributor for infrastructure of this kind and is reported as such rather than modeled in detail. Scope 2 covers emissions embodied in purchased electricity and accounts for effectively the whole footprint.

A feature specific to this network's accounting deserves stating. Because retaining published data is an ongoing obligation, part of the emissions in any period is attributable to data published in earlier periods that must still be held and served. Emissions therefore carry forward in a way they do not on a chain whose nodes primarily execute transactions, and a period of heavy publication raises the baseline for subsequent periods rather than only its own. The attribution used here assigns emissions to the period in which the electricity is drawn, not to the period in which the data was published, which is the conventional treatment and is stated so that the resulting time profile is not misread.

Greenhouse gas intensity per transaction is period emissions divided by transactions settled in the period, and inherits the caveat set out for energy intensity: the quantity driving consumption is published data volume rather than transaction count, so the figure is an accounting average. Uncertainty compounds through the calculation, with the storage node population and its hardware the least certain inputs, and grid intensities being annual averages that smooth substantial variation. Figures are restated each period as observation improves. Carbon intensity data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy, and is made available under a Creative Commons BY 4.0 license: Carbon intensity of electricity generation.

Emissions are derived from the same two inputs as the energy figures, an estimate of how much electricity the network's machines draw and an estimate of where those machines are, combined with the carbon intensity of the electricity supplied in each of those places. The geographic distribution is built from publicly observable network data and, where it cannot be resolved, from the distribution of a structurally comparable network. Each region's estimated consumption is multiplied by the emissions released per unit of electricity generated on that region's grid, and the products are summed to a network total.

The intensity data is drawn from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and made available under the Creative Commons CC BY 4.0 license.

The two reported scopes describe different things. Scope 1 covers emissions released by sources the operators of the infrastructure control directly, which in practice means combustion on site, such as a generator burning fuel. A network of this kind runs on ordinary servers in data centers drawing from public grids, so there is generally no such combustion to account for and the scope 1 figure is reported at or near zero rather than left out. Scope 2 covers the emissions embodied in the electricity those machines purchase, and effectively the whole footprint sits there. Greenhouse gas intensity is computed in the same marginal way as energy intensity: the additional emissions attributable to including one further transaction, rather than the network total divided by a transaction count.

Every uncertainty in the consumption and location estimates carries straight through into these numbers, and the intensity data contributes one of its own. Grid figures are annual and regional; they smooth over the hours of the day when consumption actually falls and over any generation a facility has contracted for directly. Where evidence is thin the more conservative assumption is applied, so the reported footprint is more likely to overstate than to understate the network's impact, and the figures are restated as the underlying observation improves.

Emissions figures are constructed from the energy estimate and the geographic estimate together. The distribution of nodes across regions is inferred from publicly observable network data, with the distribution of a structurally comparable network standing in where direct observation is insufficient. Each region's share of estimated consumption is then multiplied by the emissions released per unit of electricity generated on that region's grid, and the results are summed to give the network total.

Carbon intensity values are taken from Carbon intensity of electricity generation, compiled by Our World in Data with major processing from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy, and published under the Creative Commons CC BY 4.0 license.

The distinction between the two reported scopes is worth spelling out. Scope 1 captures emissions from sources the infrastructure's operators control directly, essentially combustion happening on their own premises. Validators and supporting nodes for this network are conventional servers housed in data centers and supplied from public grids, so there is ordinarily nothing of that kind to record and the scope 1 figure is reported at or close to zero rather than omitted. Scope 2 captures the emissions embodied in the purchased electricity that those machines consume, and in practice the entire footprint falls under it. Greenhouse gas intensity mirrors energy intensity in construction: it expresses the emissions attributable to one additional transaction at the margin, not an average obtained by dividing a total by a count.

Every uncertainty already present in the consumption and location estimates propagates into these figures, and the intensity data introduces another. Published grid intensities are annual averages across a region; they cannot reflect the hours at which a node's consumption actually falls, nor any generation a particular operator has contracted for directly. Where the evidence is thin, the conservative assumption is preferred, meaning the reported emissions are more likely to sit above the true value than below it, and every figure is revised as the underlying observation improves.