Layer 1 blockchain
Babylon ticker BABY
Summary
Cosmos SDK chain running CometBFT: BABY-staked validators propose blocks and commit each height once more than 2/3 of voting power precommits. A second layer comes from Bitcoin: holders lock BTC in self-custodial Bitcoin scripts and delegate it to finality providers, who vote on each committed block with extractable one-time signatures. Babylon marks a block finalized once providers with more than 2/3 of active BTC voting power have signed it. A provider that signs two conflicting blocks exposes its key, and a share of its delegated BTC is burned on Bitcoin (0.1% in every Bitcoin staking parameter version through 27 September 2026). Every 360-block epoch, validators BLS-sign a checkpoint that is written to Bitcoin to resist long-range attacks. 56111419202139
Design
- System
- Layer 1 blockchainBabylon Genesis (chain ID bbn-1, mainnet since April 2025) is a sovereign Cosmos SDK proof-of-stake chain with its own BABY-staked validator set. It is not a Bitcoin layer 2, sidechain or bridge: staked bitcoin never leaves Bitcoin, and Bitcoin is used for staking scripts and for timestamped checkpoints of Babylon's state, not as a settlement layer for Babylon transactions. It is not a Cosmos Hub consumer chain.
- Settlement family
- Cosmos SDK
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- BABY validators chosen round-robin in proportion to voting power. On 27 September 2026, 68 validators were bonded (maximum 100) and the three largest held more than a third of bonded BABY. Finality providers never propose blocks. 23 were in the active BTC set, holding about 40,345 BTC of voting power; two providers whose self-chosen names are Kraken and Kraken02 held about 82% of it.
- Fork choice
- No Nakamoto-style fork choice: CometBFT decides each height once validators with more than two-thirds of voting power precommit. The BTC finality vote does not choose between forks; if it stalls, CometBFT keeps producing blocks that stay unfinalized until providers resume or governance jails non-voters. Against long-range forks, the chain whose checkpoint reached Bitcoin first is treated as canonical.
Qualifications
- Bitcoin secured claim · Contested. Babylon calls itself secured by Bitcoin. Block production and liveness rest on BABY validators; bitcoin stakers add a finality vote with a small burn on double-signing, and Bitcoin checkpoints guard against long-range forks. Bitcoin miners do not validate Babylon blocks.
- Shared security · Not applicable. Babylon Genesis runs its own BABY validator set and staking module. It does not receive Cosmos Hub validator security.
- Ibc · Applies. IBC links Babylon Genesis to other chains through on-chain light clients. It is recorded under bridges and is not a rollup or channel layer.
- Bitcoin finality vote concentration · Applies. At height 4,627,600, two providers named Kraken and Kraken02 held about 82% of active BTC voting power. That is enough to finalize blocks without other providers, and enough to stall the finality vote if they stopped signing. Names are self-declared on chain; their descriptions point to kraken.com, but no operator announcement confirming them was found.
- Tps · Unknown. No classified Babylon throughput figure was found or recorded. A block interval of about 9.6 seconds, averaged over 10,000 blocks in September 2026, is an interval, not a capacity measure.
Tradeoffs
- Emphasizes
- Security Contested
- Gives up
- Simplicity and breadth of participation. Security is layered (BABY validators, a separate BTC finality vote, a 6-of-9 covenant committee that must co-sign every stake, and Bitcoin checkpoints), so full settlement takes hours rather than seconds. At review two providers self-named Kraken and Kraken02 held most of the BTC finality voting power, and contract upload is limited to governance-approved addresses. Single-chain throughput is not a design goal.Whether bitcoin adds much security is disputed. The BTC vote does not produce blocks, the burn on double-signing was 0.1% of delegated BTC, and two providers held more than the two-thirds needed to finalize alone. Bitcoin checkpoints do give an outside ordering against long-range forks.
- Full node at home
- Demanding 326The node repository lists a quad-core amd64 CPU, 32 GB RAM, 1 TB NVMe and a 100 MBps bidirectional connection as tested by validators, and warns that lower specs may crash. The September 2026 v4.5 security upgrade shipped its binary through a download link released 30 minutes before the upgrade height, and no public v4.5 source release was found on GitHub at review, so operators could not build it from public source. Current state size was not measured.
- Throughput claims
- No classified figure recorded
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | A trust-minimized cross-party swap mechanism on Babylon Genesis was not reviewed. IBC transfers are not atomic swaps. |
| Authenticated data publication | Unknown | Not yet assessed under the current definitions; Babylon's Bitcoin timestamping writes compact commitments to Babylon's own checkpoints into Bitcoin transactions. That is consensus checkpointing, not a feature Babylon users invoke to publish data, and the earlier note said the absence of such a feature was not verified. 36 |
| Light clients | Built into the protocolLimited scope | Consensus produces what a light client checks: CometBFT validators sign each committed height, and IBC, which Babylon runs (ibc-go v10 since the v4 upgrade), has connected chains track each other's consensus state with on-chain light clients. Limit: light verification serves IBC counterparties; no user-facing Babylon light client was reviewed. Babylon also keeps a Bitcoin header light client on chain to check checkpoint and staking transactions; that verifies Bitcoin, not Babylon. 41012 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Babylon Genesis was reviewed. IBC channels are messaging paths, not payment channels. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | CosmWasm contracts are live. On 27 September 2026 only eight allow-listed addresses could upload contract code (one is the governance module's own account; the others were added by governance votes), and anyone could instantiate uploaded code. A planned EVM was postponed in October 2025. 1182838 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; the earlier review did not verify any feature for cancelling, delaying or recovering payments on Babylon Genesis accounts. The Bitcoin staking scripts use timelocks and a covenant-signed early exit, which lock the staker's own BTC rather than reverse or recover a payment. Babylon's Trustless Bitcoin Vaults are a separate lending-collateral design on Bitcoin and Ethereum. 9 |
| Rollups | None found Earlier definition | No rollup settles to Babylon Genesis. Planned networks that would reuse staked bitcoin for other chains and rollups were postponed until after the vault launch, and the staking specification says stakers can currently choose only providers for Babylon Genesis. 928 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | UnknownTower DEX, Persistence DEX | Governance approved code-upload rights for both DEX teams in April 2025. A proposal in voting on 27 September 2026 would remove both deployer addresses from the upload list as inactive. Current pools and liquidity were not measured. 222427 |
| Issuer-native stablecoins | None found | Circle does not list Babylon for USDC. USDC on Babylon is an IBC voucher from Noble, not issuance on Babylon. 233 |
| Algorithmic stablecoins | Unknown | Algorithmic or hybrid stablecoins on Babylon Genesis were not reviewed. |
| Bridges | Native to the protocolIBC (ibc-go), Union | IBC connects Babylon to Noble, Axelar, the Cosmos Hub and other chains. The chain registry also lists Union-bridged tokens from Ethereum and BNB Smart Chain, mostly wrapped or liquid-staked bitcoin tokens, and bitcoin tokens from Ethereum that reach Babylon over IBC routed through the Cosmos Hub. Circle CCTP does not list Babylon. Risk: IBC safety depends on each counterparty chain and correct light-client setup. Union adds its own verification and contract risk. Wrapped bitcoin tokens that arrive by bridge carry their issuers' custody risk; BTC staked through Babylon's Bitcoin scripts stays in self-custodial scripts on Bitcoin. 212233435 |
| Block explorers | Established in the ecosystemMintscan, Valopers, NodesHub, Moon-Runners, Xangle Babylon Explorer | The chain registry lists Mintscan, Valopers, NodesHub and Moon-Runners; Babylon's own upgrade proposal links the Xangle explorer. The registry's Nodes Guru explorer redirected away at review. Listing is not a quality check. 1263637 |
| Hardware wallets | ThinLedger (Babylon module in Ledger's wallet code, switched off by default) | See custody rows: Trezor states it does not support Babylon, and Ledger's wallet code has a Babylon module behind a switch that is off by default, with no Ledger product page confirming BABY accounts. Babylon's Ledger clear-signing work covers bitcoin vault transactions, not BABY accounts. 293132 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | PartialSame as native: Unknown | Cannot: Add a Babylon Genesis account in Ledger's own wallet unless Ledger has switched the network on: current Ledger Wallet code includes a Babylon module but keeps it behind a feature switch that is off by defaultFirst-party support exists in Ledger's code, a Babylon Genesis module with transfers and staking, but it is limited to a switch that is off by default, and no readable Ledger page confirms it has been switched on; Ledger's Babylon coin page returned 404. Babylon's March 2026 post says BABY support is still to come; its Ledger clear-signing work covers bitcoin vault transactions, not BABY accounts. 293031 |
| Trezor | None foundSame as native: No | Cannot: Manage Babylon Genesis (BABY) accounts in Trezor SuiteTrezor's Babylon page says Trezor does not support Babylon. A Trezor can still hold ordinary bitcoin, but whether Babylon staking scripts can be signed with a Trezor was not checked. 32 |
Public data
iKnow Blockchain has no public-data lookups for Babylon yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
v4.5 security upgrade shipped with binaries released shortly before activation
Governance approved the v4.5 software upgrade, described as containing important security fixes. The upgrade height 4,511,100 was reached at 12:01 UTC on 14 September 2026. Binaries were made available through a download link 30 minutes before the upgrade, with details of the fixes to follow after mainnet and testnet upgraded.
- Proposal:passed (proposal 24)
- Implementation:security fixes applied; details undisclosed at review
- Release:binary shared by download link 30 minutes before activation; no public GitHub release at review
- Activation:active since height 4,511,100
Sources: Babylon on-chain governance (via Polkachu REST endpoint) — Governance proposal 24: v4.5 Software Upgrade (external site) · Polkachu public REST endpoint for bbn-1 — Applied upgrade plan v4.5 (on-chain query) (external site) · Polkachu public REST endpoint for bbn-1 — Babylon block 4511100 (v4.5 upgrade height) (external site) · Babylon Labs — babylonlabs-io/babylon releases (external site) · Polkachu public REST endpoint for bbn-1 — Babylon governance proposals list (on-chain query) (external site) · Babylon Labs — Release notes from babylon (Atom feed) (external site)
-
v4.4.0 brought Cosmos SDK v0.53.8 security fixes to Babylon through a coordinated upgrade
Node release v4.4.0 moved Babylon to Cosmos SDK v0.53.8 and wasmd v0.60.5, both listed as state-breaking in the change log. Its v4.4 upgrade handler changes no state; the code says it exists to coordinate the binary swap for the SDK security release. The Cosmos SDK team had published v0.53.8 on 27 July 2026 with fixes to transaction signing, signer and multisig checks and public-key validation, and asked chains to adopt it through a coordinated upgrade.
- Proposal:expedited software-upgrade vote in August 2026, per the on-chain proposals list read earlier on 27 September 2026
- Implementation:Cosmos SDK v0.53.8 and wasmd v0.60.5; upgrade handler makes no state changes
- Release:released as v4.4.0 on GitHub on 6 August 2026; latest GitHub release at review
- Activation:mainnet upgrade described in the governance record; activation height not re-checked in this pass
Sources: Babylon Labs — babylon v4.4.0 release (external site) · Babylon Labs — Babylon node CHANGELOG at tag v4.4.0 (external site) · Babylon Labs — v4.4 upgrade handler source (external site) · Babylon Labs — babylon go.mod at tag v4.4.0 (external site) · Cosmos SDK maintainers (cosmos/cosmos-sdk) — Cosmos SDK v0.53.8 release (external site) · Polkachu public REST endpoint for bbn-1 — Babylon governance proposals list (on-chain query) (external site)
-
v4.3.1 fixed a block-size miscount that could crash the validator proposing a checkpoint block
Node release v4.3.1 fixed security advisory GHSA-692h-272j-rvgc. When the block proposer packed an epoch checkpoint into its proposal, the node counted transactions by raw size, while CometBFT checks the slightly larger encoded size. A full block at a checkpoint boundary could therefore pass Babylon's check but exceed CometBFT's limit, and CometBFT would then crash the proposer. The fix counts encoded sizes and drops trailing ordinary transactions if a proposal still fails the size check.
- Implementation:proposal size accounting fixed in the checkpointing module
- Release:released as v4.3.1 on GitHub on 21 July 2026
- Activation:per node on install; no coordinated upgrade found; operator adoption not checked
Sources: Babylon Labs — babylon v4.3.1 release (external site) · Babylon Labs — Checkpoint proposal size accounting fix (GHSA-692h-272j-rvgc) (external site) · Babylon Labs — Babylon node CHANGELOG at tag v4.4.0 (external site) · Babylon Labs — Release notes from babylon (Atom feed) (external site)
-
v4.3.0 fixed two security flaws and removed phantom bitcoin voting power left by stake extensions
Babylon Labs released node version v4.3.0 with fixes for two security advisories. The first covered a stake extension (called stake expansion in the code) that was unbonded early, before its Bitcoin inclusion proof was recorded; the original stake could then stay active on Babylon, with voting power, although its bitcoin output had already been spent. The v4.3 upgrade handler finds such original stakes and force-unbonds them. The second fix stops a validator's checkpoint signature for the wrong epoch from being folded into an epoch's aggregate signature, which could seal a checkpoint whose signature does not verify.
- Proposal:expedited software-upgrade vote in May 2026, per the on-chain proposals list read earlier on 27 September 2026
- Implementation:two advisory fixes plus a v4.3 upgrade handler that force-unbonds affected original stakes
- Release:released as v4.3.0 on GitHub on 5 May 2026
- Activation:mainnet upgrade described in the governance record; activation height not re-checked in this pass
Sources: Babylon Labs — babylon v4.3.0 release (external site) · Babylon Labs — Babylon node CHANGELOG at tag v4.4.0 (external site) · Babylon Labs — Changes between babylon v4.2.7 and v4.3.0 (external site) · Babylon Labs — v4.3 upgrade handler source (external site) · Polkachu public REST endpoint for bbn-1 — Babylon governance proposals list (on-chain query) (external site)
-
Babylon announced Ledger clear signing for Bitcoin vaults, with BABY support to follow
Babylon Labs announced a Ledger integration centred on clear signing for Trustless Bitcoin Vault transactions, so users can read what they approve on the device. The post says BABY will be supported as part of the broader integration and that support for Babylon bitcoin staking is planned.
- Implementation:vault clear signing announced; BABY and BTC staking support planned
- Release:not confirmed from a Ledger product page
- Activation:Unverified
Sources: Babylon Labs — Babylon and Ledger Integration Expands Access to Trustless Bitcoin Vaults (external site) · Ledger (LedgerHQ/ledger-live) — Ledger Live Cosmos coin module: Babylon chain definition (source code) (external site)
-
v4 upgrade added BTC-BABY co-staking and cut BABY inflation to 5.5%
After a signalling vote passed on 6 October 2025, the v4 software upgrade (governance proposal 18) went live at height 1,893,601 on 13 November 2025. It added co-staking rewards for users who stake both BTC and BABY, reduced BABY inflation from 8% to 5.5% a year, and let bitcoin stakers extend a stake's timelock without unbonding.
- Proposal:passed (proposals 15 and 18)
- Implementation:released as v4.0.0
- Release:Released
- Activation:active since height 1,893,601
Sources: Babylon on-chain governance (via Polkachu REST endpoint) — Governance proposal 18: v4 Software Upgrade (external site) · Babylon on-chain governance (via Polkachu REST endpoint) — Governance proposal 15: Signalling Proposal: Inflation reduction and the introduction of co-staking (external site) · Polkachu public REST endpoint for bbn-1 — Applied upgrade plan v4 (on-chain query) (external site) · Babylon Labs — Babylon node CHANGELOG (external site) · Babylon Labs docs — BABY tokenomics (external site)
-
Babylon Labs put Bitcoin vaults ahead of multi-network staking and an EVM
Babylon Labs said it would focus engineering on Trustless Bitcoin Vaults and launch the planned networks secured by staked bitcoin, and an EVM on Babylon Genesis, only after the vaults. It said vaults would first integrate with mature DeFi protocols on large chains, starting with Ethereum, and be deployed on Babylon Genesis and other networks later.
- Proposal:announced roadmap
- Implementation:multi-network staking and EVM postponed
- Release:vaults on public testnet at review
- Activation:not active
Sources: Babylon Labs — A Vault First Roadmap - Catalysing Bitcoin DeFi (external site) · Babylon Labs — Bitcoin Staking script specification (external site) · Babylon Labs docs — Babylon Labs documentation home (external site) · Babylon Labs — Bitcoin Borrowing, Repriced (external site)
Topics your AI can explain
Your AI can explain these topics for Babylon through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Babylon's documentation site renders little text for automated reading; node hardware figures come from the node repository README, and no official figure for current state size or archive storage was found.
- The v4.5 security upgrade (September 2026) source was not found on GitHub at review; nodes report version 4.5.0 and the fixes had not been described publicly. The main-branch change log lists one unreleased checkpointing security fix whose advisory page was not public, and whether it belongs to v4.5 is unconfirmed.
- Finality-provider names such as Kraken are self-declared on chain (their on-chain descriptions point to kraken.com) and were not confirmed by an operator announcement; a June 2025 Babylon post about Kraken describes a staking integration for Kraken users, not a finality provider.
- The covenant committee's nine members were not identified; only the key count and 6-of-9 threshold were verified.
- Current liquidity on Tower DEX and Persistence DEX was not measured, and whether either still operates on Babylon Genesis is unknown.
- Ledger support for BABY accounts is unconfirmed for users: Ledger's wallet code keeps its Babylon module behind a switch that is off by default, the Ledger coin page returned 404, and Ledger's switch settings for users could not be read.
- Whether BABY transaction fees are burned or paid to stakers was not reviewed.
- No atomic-swap mechanism, reversible-transfer or recovery feature, channel layer or algorithmic stablecoin on Babylon Genesis was reviewed.
- On-chain facts come from two public REST endpoints (Polkachu and Allnodes), not an independently operated archive node; both pruned early history.
- The standard staking parameter shows a 21-day BABY unbonding time while the epoching specification says unbonding completes once a checkpoint is final on Bitcoin; the actual observed unbonding duration was not measured.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Babylon Genesis chain registry record (external site)
- Babylon asset list (external site)
- babylonlabs-io/babylon repository (README and system requirements) (external site)
- Babylon node CHANGELOG (external site)
- x/finality module specification (external site)
- x/checkpointing module specification (external site)
- x/btccheckpoint module specification (external site)
- x/epoching module specification (external site)
- Bitcoin Staking script specification (external site)
- Babylon Genesis architecture (external site)
- Byzantine Consensus Algorithm (external site)
- IBC overview (external site)
- Babylon staking parameters (on-chain query) (external site)
- Babylon epoching parameters (on-chain query) (external site)
- Babylon Bitcoin checkpoint parameters (on-chain query) (external site)
- Babylon finality parameters (on-chain query) (external site)
- Babylon Bitcoin staking parameters (on-chain query) (external site)
- Babylon CosmWasm code upload parameters (on-chain query) (external site)
- Babylon bonded validators (on-chain query) (external site)
- Active finality providers and BTC voting power at height 4627600 (on-chain query) (external site)
- Registered finality providers and descriptions (on-chain query) (external site)
- Governance proposal 2: Whitelisting Address for Tower DEX (external site)
- Governance proposal 4: Whitelisting Address for Union (external site)
- Governance proposal 5: Whitelist Persistence Labs address to deploy Persistence DEX on Babylon (external site)
- Governance proposal 18: v4 Software Upgrade (external site)
- Governance proposal 24: v4.5 Software Upgrade (external site)
- Governance proposal 25: Remove Inactive Addresses from the CosmWasm Code Upload Allow-List (external site)
- A Vault First Roadmap - Catalysing Bitcoin DeFi (external site)
- Babylon and Ledger Integration Expands Access to Trustless Bitcoin Vaults (external site)
- Ledger Live Cosmos coin module: Babylon chain definition (source code) (external site)
- Ledger Wallet feature switch currencyBabylon (declared without an enabled value) (external site)
- Babylon wallet (external site)
- USDC contract addresses (external site)
- CCTP supported chains and domains (external site)
- Union (external site)
- Overview - Babylon (BABY) Mainnet Explorer (external site)
- Babylon Explorer (external site)
- Babylon governance proposals list (on-chain query) (external site)
- Babylon Bitcoin staking parameter versions (on-chain query) (external site)
- Kraken Integrates Babylon Bitcoin Staking Protocol for BTC Staking (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding