Babylon (BABY) sustainability report

Babylon is present on the following networks: Babylon.

Babylon Genesis is a sovereign proof-of-stake chain built on a widely used interoperable framework, and its consensus operates in two layers that should not be confused with one another. The base layer is conventional: a validator set bonded with the chain's native asset runs a Byzantine fault tolerant protocol in which a proposer offers a block and the set commits it once more than two thirds of bonded power has voted, giving deterministic finality at each block.

The second layer is what the network was built for. A separate role, the finality provider, votes on whether already-produced blocks are final, and the voting power behind those providers comes not from the chain's own asset but from bitcoin locked on the Bitcoin network. A holder locks a bitcoin output under a timelocked script and keeps their own keys throughout; nothing is wrapped, bridged or transferred to a custodian, and the coins never leave Bitcoin. The lock designates a finality provider, whose participation is identified by a cryptographic key of a particular construction.

That construction is what makes the arrangement enforceable. A finality provider signs its votes with a one-time signature scheme in which signing two conflicting messages with the same key mathematically reveals the provider's private key from the two signatures alone. Anyone can then use that revealed key to execute a penalty transaction on Bitcoin, so the punishment for equivocation is enforced by arithmetic rather than by a contract on some other chain. A committee co-signs staking transactions in advance to ensure that the unbonding and penalty conditions conform to the protocol's rules, which is necessary because Bitcoin's scripting is not expressive enough to check them itself.

The exposure this creates should be stated precisely. What can be taken is the finality provider's own stake and the portion of a delegator's bitcoin that the delegator pre-authorized in the original locking transaction; a delegator's principal beyond that pre-approved fraction is not at risk, and the provider carries the larger share of the exposure. Unlocking early is possible subject to a waiting period of roughly a week.

Babylon is present on the following networks: Babylon.

Three groups earn from the network. Validators securing the base chain earn from issuance of the native asset and from transaction fees, in the standard manner of the framework, with delegation available to holders who do not run infrastructure and a commission taken before the remainder is shared. Finality providers earn for casting finality votes. Bitcoin holders who lock coins and delegate them to a finality provider share in that provider's earnings after its commission, which is the economic proposition the network is built around: a yield on bitcoin that does not require giving up custody of it or moving it to another chain.

The penalty structure is unusual and worth setting out carefully, because the risk borne by the two sides is asymmetric by design. A finality provider that signs conflicting votes has its key exposed by the signature scheme itself, and its own stake is taken. A delegator who chose that provider loses only the fraction of their locked bitcoin that they agreed to expose when they created the lock, with the remainder returning to them under a short timelock after the penalty transaction executes. A delegator therefore knows their maximum loss at the moment of locking, which is a materially different proposition from delegation on chains where a proportional share of the whole bonded amount is at risk.

Unlocking is available at any time subject to a waiting period of approximately a week, during which the coins remain exposed to penalty so that a provider's delegators cannot escape ahead of an offense being proven. Early unlocking requires the co-signature of the committee that validated the original lock.

Users of the chain pay ordinary gas fees denominated in the native asset, priced by the computational and storage resources a transaction consumes, with a minimum price that validators may set individually. There are no recurring rents on holdings. Bitcoin holders additionally bear the transaction fees of the Bitcoin operations needed to lock and later release their coins, which are paid on that network and are unrelated to this one's fee schedule.

Babylon is present on the following networks: Babylon.

The accounting boundary is the most consequential decision in estimating this network, and getting it wrong would produce a figure off by several orders of magnitude. The network derives economic security from bitcoin, but it does not cause any bitcoin mining to occur. The coins used as stake are already in existence and their locking and release are ordinary Bitcoin transactions; the network additionally writes periodic checkpoints to Bitcoin, which are likewise ordinary transactions. Bitcoin's energy consumption is determined by its own mining economics and would be identical whether or not this network existed. It follows that no share of Bitcoin's mining energy is attributed here. What is attributed is the marginal cost of the transactions this network causes to be published on Bitcoin, which is a negligible quantity of additional data in blocks that would have been produced regardless.

Within that boundary, the estimate is a node-level one of the usual kind. The active validator set is capped by an on-chain parameter, so its size is known rather than crawled. Finality providers run their own signing infrastructure and are a separate, smaller population identified on-chain by their participation keys, which makes them countable. Beyond both, full nodes operated by exchanges, explorers and applications hold copies of the chain without participating in consensus and are estimated from public listings and network observation. The committee that co-signs locking transactions runs infrastructure of its own, small in number and enumerable.

Representative hardware follows from the published requirements for running the node software, and measured power draw for machines of that description, under load and at idle, is applied across each population, weighted toward idle since a node spends most of its time validating and gossiping rather than working hard.

Limitations are as elsewhere. Populations outside the capped validator set are observed externally and cannot be audited, redundant infrastructure is largely invisible, and where evidence is thin the conservative assumption is used, more likely to overstate than understate. Figures are revised as observation improves.

Babylon is present on the following networks: Babylon.

The machine populations are located through a combination of disclosure and observation. Validators in the capped active set commonly publish identity information because delegators select operators on reputation, giving a distribution based substantially on what operators state about themselves. Finality providers are similarly visible, since attracting bitcoin delegations requires being identifiable, and many are operated by infrastructure businesses with published hosting arrangements. Full nodes run by exchanges, explorers and applications are located by network observation and hosting provider address ranges, with less confidence. The committee co-signing locking transactions is small and its membership is known.

Each located machine is matched to published statistics for the grid supplying its region, and the renewable share is the average across those grids weighted by the consumption attributed to each location. Because the populations involved are small and substantially disclosed, the geographic picture rests on firmer evidence than for networks whose participants are anonymous, and the residual uncertainty concerns how many physical machines sit behind each disclosed identity rather than where those identities are.

It bears repeating in this section that the bitcoin providing economic security is not part of this calculation. Mining location, the renewable mix of mining regions and the seasonal migration of mining capacity are properties of a different network whose energy use this one does not cause and does not attribute to itself.

Limitations are the standard ones: voluntary disclosure is self-selecting, commercial hosting facilities do not publish their supply arrangements so regional grid averages substitute for the supply of a particular building, grid statistics are annual and conceal daily and seasonal variation, and contractual renewable purchases are not counted because the method describes the physical grid mix.

Energy intensity per transaction is period consumption divided by transactions settled in the period. The validator set is capped, so consumption is close to fixed with respect to throughput and an additional transaction causes almost no additional energy; intensity falls as usage rises without any change in the underlying energy use. The figure is an average across the period rather than a marginal cost. 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.

Babylon is present on the following networks: Babylon.

Emissions are derived by applying a grid carbon intensity to the electricity attributed to each location in the distribution established above and summing across validators, finality providers, full nodes and the co-signing committee. The boundary is operational electricity; manufacture of hardware and construction of facilities are outside it.

The boundary decision set out in the energy methodology governs emissions too and is restated here because it is the figure most open to misreading. No portion of Bitcoin's mining emissions is attributed to this network. The bitcoin used as stake is already mined, locking and releasing it are ordinary transactions, and the checkpoints written to Bitcoin are a negligible marginal addition to blocks that would have been produced in any case. A reader comparing this network's emissions with those of a chain that secures itself through its own mining should understand that the security here is borrowed from work performed for entirely separate reasons, and that this accounting attributes that work to the network causing it.

Scope 1 covers emissions from sources under the direct control of node operators, principally occasional backup generation, and is a negligible contributor reported as such rather than modeled in detail. Scope 2 covers emissions embodied in purchased electricity and represents effectively the entire footprint.

Greenhouse gas intensity per transaction is period emissions divided by transactions settled, and carries the same caveat as energy intensity: consumption is close to fixed with respect to throughput, so the quotient is an average across the period rather than the emissions caused by one further transaction. Uncertainty compounds through the calculation, though it is smaller here than for networks with anonymous participants, since the machine populations are capped or enumerable and substantially disclosed; the principal residual uncertainties are redundant infrastructure behind each identity and the annual averaging inherent in grid intensity data. 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.