# Babylon Labs Documentation

> Babylon is a Bitcoin staking protocol that enables BTC holders to stake their Bitcoin to provide security to Proof-of-Stake chains. The Babylon Genesis chain is a Cosmos SDK-based blockchain that serves as the coordination layer, combining BTC staking with native BABY token staking in a dual-staking model. This documentation covers the protocol architecture, staking guides, developer integration resources, and node operator instructions.

## Core Documentation

### Protocol Overview

Babylon provides Bitcoin-native infrastructure for the decentralized economy. The protocol enables trustless interaction with Bitcoin state and native Bitcoin staking directly on the Bitcoin blockchain.

#### Products

- **Trustless Bitcoin Vault**: A toolkit that securely connects Bitcoin on-chain state to external smart contracts (e.g. Ethereum) and systems. By combining on-chain contracts, light-client proofs (ZK SNARKs), and independent indexers, it enables verifying Bitcoin consensus and UTXO state in other chains or applications without trusting any single third party.
- **Bitcoin Staking**: Enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.

#### Trustless Bitcoin Vault

Key capabilities:
- **Trustless verification**: No need to trust individual nodes or custodians; security is enforced by cryptographic proofs and on-chain rules
- **Verifiable light clients**: Provide provable, compact attestations of Bitcoin consensus to target chains
- **Modular architecture**: Indexer, prover, and contract layers are separated so each can be swapped or upgraded independently

#### Bitcoin Staking

Key features:
- **Trustless staking**: BTC remains native with no wrapped assets
- **Self-custody**: Stakers maintain direct control of their Bitcoin
- **Fast unbonding**: Stake withdrawal period of just a few days
- **Slashing capability**: Protocol-enforced penalties for security violations

When implemented at scale, Bitcoin represents the largest potential staking capital pool in the web3 ecosystem.

#### Security Model

Babylon implements the following security guarantees:
- **PoS Security**: Security violations trigger automatic slashing of a portion of the Bitcoin stake
- **Staker's Security**: Staked Bitcoin remains recoverable contingent on network compliance by the staker or delegated validator
- **Withdrawal Assurance**: Unbonding operations execute securely without requiring consensus coordination

#### Babylon Genesis

Babylon Genesis is a Cosmos SDK-based blockchain that serves as the coordination layer for the Babylon protocol. It provides native IBC (Inter-Blockchain Communication) protocol support and CosmWasm compatibility for smart contract deployment.

### Bitcoin Staking

Bitcoin staking in Babylon protocol enables BTC holders to lock their assets in a time-bound contract as security collateral, earning rewards for securing networks. The protocol implements a slashing mechanism where staked assets may be forfeited if protocol security rules are violated.

#### Native Bitcoin Staking Implementation

Babylon's staking mechanism is built directly on Bitcoin's UTXO model and native scripting capabilities. This differs from traditional cross-chain staking solutions that require wrapping or bridging Bitcoin to external networks.

**Core Requirements:**
- Self-custody: Stakers maintain direct control of their Bitcoin
- Trustless execution: No reliance on third parties
- Native operation: Direct integration with Bitcoin blockchain
- Slashing capability: Protocol-enforced penalties for malicious behavior

**Technical Implementation:**
The staking mechanism leverages Bitcoin's UTXO model, allowing holders to create multiple UTXOs with distinct spending conditions defined through Bitcoin scripts. These scripts form the basis of staking contracts with the following conditions:
1. Holder's cryptographic signature
2. Time-lock expiration
3. Covenant committee consensus (for slashing)

The protocol introduces Extractable One-Time Signatures (EOTS) and a covenant committee to enable slashing functionality. The committee can execute slashing through majority consensus if malicious behavior is detected.

#### Staking Architecture

Bitcoin Staking enables BTC holders to delegate their assets to Finality Providers. This architecture forms the foundation of Babylon's security model.

**Protocol Components:**
1. **Staking Contract**: Bitcoin script-based security mechanism with covenant committee integration, facilitated via Babylon Genesis
2. **Finality Provider**: Delegated validators for chain or data validation
3. **Babylon Genesis**: Coordination layer that tracks staking state and distributes rewards

**Security Properties:**
1. **Slashable PoS Security**: Guaranteed partial stake forfeiture upon safety violations
2. **Asset Safety**: Guaranteed withdrawal capability for honest stakers and validators
3. **Liquidity Assurance**: Secure, efficient unbonding without social consensus requirements

### Babylon Genesis Overview

Babylon Genesis is the coordination layer for the Babylon protocol, serving as the control plane for Bitcoin staking security and liquidity orchestration. Built on the Cosmos SDK framework, Babylon Genesis introduces key innovations for enhanced PoS security and interoperability.

#### Consensus & Security Model

Babylon Genesis introduces a multi-staked CometBFT (Tendermint) consensus mechanism:

1. **Bitcoin Staked**: BTC holders can stake their assets directly on the Bitcoin network in a self-custodial manner without wrapping or bridging. These BTC stakers delegate to a Finality Provider who enhances the security of the PoS chain.
2. **BABY Staked**: BABY token stakers delegate to CometBFT validators who oversee block production and consensus operations.

#### Bitcoin Timestamping & Checkpointing

Babylon Genesis leverages Bitcoin's blockchain to timestamp events from other blockchains, providing an additional layer of security and data integrity. This process:
- Creates immutable anchoring between Bitcoin's ledger and Babylon Genesis
- Mitigates vulnerabilities in PoS chains, such as long-range attacks and double-signing
- Enhances overall security through Bitcoin's proven consensus mechanism

#### Features Overview
- **Bitcoin Integration:** Direct connection to Bitcoin for staking and timestamping via bitcoin scripts
- **Bitcoin Staking:** Native BTC staking and timestamping mechanisms, and Extractable One-Time Signature (EOTS)
- **Scaling Transactions:** Aggregates timestamps and checkpoints to minimize Bitcoin transaction costs
- **Multichain Communications:** Seamless communication with other chains via the IBC protocol

#### Native Token: BABY

- **Name**: BABY
- **Total Initial Supply**: 10 Billion
- **Decimals**: 6

BABY works alongside staked Bitcoin, with BTC providing the economic security guarantees while BABY enables protocol operations and governance.

**Token Utility:**
1. Transactions / Gas Features
2. Governance
3. Staking & Security

#### Development Phases

**Phase 1: Bitcoin Staking**
- Enabled Bitcoin holders to stake their BTC using a secure, self-custodial staking script directly on Bitcoin
- Over 57,000 BTC were staked
- Established Bitcoin as a top 10 staking asset by market cap

**Phase 2: Babylon Genesis Launch**
- BTC stakers actively provide security to Babylon Genesis
- Demonstrates security features (e.g. slashing) of Babylon Staking Protocol
- Provides base staking rewards to BTC stakers

#### Babylon Genesis Validators

BGC's block production process is safeguarded by Genesis Chain Validators. They are nodes that validate transactions, produce blocks, and help secure the Babylon Genesis Chain.

#### Finality Providers

Finality Providers play a crucial role in securing not only PoS blockchains but also decentralized systems that require data validation. They manage their Extractable One-Time Signature (EOTS) keys, submitting signatures using public randomness.

### Architecture

The Babylon network has a layered architecture composed of Bitcoin scripts, Babylon node built on Cosmos SDK, Finality Providers, and peripheral software solutions designed to securely interact with Bitcoin Chain so it can facilitate Bitcoin staking.

On the top layer, Babylon ensures Bitcoin Chain and Babylon Genesis are securely connected and synchronized by using Checkpointing. It also keeps track of Bitcoin holders' staking transactions with a BTC staking monitor and indexer. The Vigilante network monitors the Bitcoin Chain and Babylon Genesis for any malicious activities.

The middle layer is the Babylon node. It is built on Cosmos SDK and implements the Babylon Bitcoin staking logic with eight core modules: Babylon Epoching, Checkpointing, BTC Checkpointing, BTC Light Client, Zone Concierge, BTC Staking, Finality, and Rewards.

At the bottom layer, EOTS Manager and Finality Provider nodes provide the means for group signatures and validating the data of an external network. Covenant Emulator provides enforcements on the transaction data for staking, unbonding and slashing.

### BTC Staking Program

Software solutions related to Bitcoin Staking processes including Finality Providers and EOTS Manager.

### Finality Providers

Finality Providers are critical components of the BTC staking program. The detailed documentation is maintained in the [finality-provider GitHub repository](https://github.com/babylonlabs-io/finality-provider).

### BABY Tokenomics

| Property | Details |
|----------|---------|
| Token Name | BABY |
| Total Initial Supply | 10,000,000,000 BABY (10 Billion) |
| Denomination | ubbn (micro BBN) |
| Decimals | 6 (1 BABY = 1,000,000 ubbn) |
| Inflation Rate | 5.5% per annum (reduced from 8%) |
| Governance | On-chain via BABY token voting (BTC stakers do not participate) |

#### The Role of BABY in Babylon Genesis

BABY is the native token of Babylon Genesis. It serves as the gas token for Babylon Genesis, facilitating transactions and smart contract execution. It also enables governance, allowing token holders and their delegated validators to vote on protocol changes and network upgrades.

#### Dual Staking & Security Model

Babylon Genesis employs a dual staking model, utilizing both BABY and BTC to strengthen network security. Both Bitcoin stakers and BABY stakers contribute security and receive BABY rewards.

#### Token Distribution

| Category | Allocation (BABY) | Allocation (%) | Vesting | Unlocking |
|----------|-------------------|---------------|---------|-----------|
| Community Incentives | 1,500,000,000 | 15% | No | Fully unlocked |
| Ecosystem Building | 1,800,000,000 | 18% | No | Yes, across 3 years |
| R&D + Operations | 1,800,000,000 | 18% | No | Yes, across 3 years |
| Early Private Investors | 3,050,000,000 | 30.5% | No | Yes, across 3 years |
| Team | 1,500,000,000 | 15% | Yes, across 4 years | Yes, across 4 years |
| Advisors | 350,000,000 | 3.5% | Yes | Yes, across 4 years |

**Community Incentives (15%):** 1.5 billion BABY tokens allocated for community incentives. Not locked and can be distributed at any time. Up to 400 million BABY tokens can be staked within this category.

**Ecosystem Building (18%):** 1.8 billion BABY tokens for grants, bounties, investments, marketing and acquisitions. Unlocked over 3 years, with 25% unlocked at network launch, and the rest unlocked linearly starting at the first anniversary.

**Research and Development + Operations (18%):** 1.8 billion BABY tokens for operations, research and development. Unlocked over 3 years, with 25% unlocked at network launch.

**Early Private-Round Investors (30.5%):** 3.05 billion BABY tokens, following a 4-year unlocking schedule. First unlocking at the first anniversary, releasing 12.5%. Remaining tokens unlock linearly over 3 years.

**Team (15%):** 1.5 billion BABY tokens with a 4-year vesting schedule, 1-year cliff followed by linear vesting. Subject to a 4-year unlocking schedule.

**Advisors (3.5%):** 350 million BABY tokens with individual vesting schedules and the same 4-year unlocking schedule as the team.

### Governance

#### Governance Framework

Babylon Genesis employs an on-chain governance system built on the Cosmos SDK governance module. This module empowers BABY token holders, along with their delegates, to propose, vote on, and enact modifications to the network through a transparent and decentralized process.

#### Governance Participants

- **BABY Token Holders**: Participate in governance by voting on proposals and/or submitting new ones.
- **Babylon Genesis Validators**: Vote with staked tokens and delegated tokens (if stakers don't vote).
- **Babylon Foundation**: Provide forum for governance process as the steward of the community.

#### Governance Parameters

| Parameter | Value | Description |
|-----------|--------|-------------|
| Minimum Deposit | 50,000 BABY | Minimum tokens required for a proposal to enter the voting period |
| Maximum Deposit Period | 14 days | Maximum time to reach the minimum deposit for a proposal |
| Voting Period / Expedited | 3 days / 1 day | Duration of the voting period for standard proposals / expedited proposals |
| Quorum | 33.4% (>1/3) | Minimum percentage of voting power needed for a valid vote |
| Approval Threshold | 50% | Proportion of Yes votes (excluding Abstain) needed for approval |
| Veto Threshold | 33.4% (>1/3) | Proportion of NoWithVeto votes that can block a proposal |
| Expedited Approval Threshold | 66.7% (>2/3) | Higher threshold for expedited proposals |
| Expedited Voting Period | 1 day | Shorter voting period for urgent proposals |
| Expedited Minimum Deposit | 200,000 BABY | Higher deposit for expedited proposals |
| Burn Proposal Deposit (no quorum) | No | Deposit returned 100% if quorum is not reached |
| Burn Proposal Deposit (veto) | Yes | Deposit burned 100% if the proposal is vetoed |
| Cancel Burn Ratio | 50% | 50% of the Deposit is burned if the proposer cancels the proposal |

#### Voting Options

- **Yes**: Approve the proposal
- **No**: Reject the proposal
- **No With Veto**: Reject and express strong opposition (contributes to veto threshold)
- **Abstain**: Formally register participation without affecting Yes/No ratio

#### Voting Inheritance

If a staker does not vote, their validator's vote is automatically inherited. If the staker votes before its validator, it will not inherit from the validator's vote. If the staker votes after its validator, it will override its validator vote with its own.

#### Proposal Types

- **Text Proposals**: Proposals for signaling community sentiment or discussing ideas.
- **Parameter Change Proposals**: Modify specific blockchain parameters without changing underlying code.
- **Software Upgrade Proposals**: Coordinate chain-wide software upgrades with specific upgrade heights or times.

Each type has two urgency levels: standard or expedited.

**Standard Proposals:** Minimum deposit of 50,000 BABY, deposit period of 14 days, voting period of 3 days, approval threshold of 50%.

**Expedited Proposals:** Higher minimum deposit at 200,000 BABY, shorter voting period of 1 day, higher approval threshold of 66.7%.

#### Proposal Lifecycle

1. **Discussion**: Community discussion on the Babylon Foundation Forum, refinement based on feedback, recommended discussion period is one week.
2. **Submission**: On-chain proposal submission with initial deposit, deposit period (up to 14 days) to reach minimum deposit.
3. **Voting**: 3-day voting period once minimum deposit is reached. All staked BABY holders can vote. Validators vote with their delegated stake unless delegators vote directly.
4. **Execution**: If approved, automatic implementation for parameter changes and fund transfers. Software upgrades are scheduled. Text proposals require manual implementation.

#### Unsuccessful Proposals

- **Pre-Voting Failures**: Deposit not burned, returned to contributors.
- **Quorum Failures**: Deposit not burned, returned to contributors.
- **Veto Situations**: Deposit burned fully. Only scenario where deposits are destroyed.

## Networks

### Mainnet

Babylon Genesis is the world's first Bitcoin Supercharged Network (BSN) and acts as the control plane for security and liquidity orchestration across future BSNs.

**Key Innovations:**

1. **Bitcoin Staking**: Self-custodial staking where BTC holders can stake directly, maintaining full custody. Dual quorum where BTC stakers delegate to finality providers while BABY token stakers delegate to Cosmos validators.
2. **Bitcoin Timestamping**: Immutable anchoring of events from other blockchains to Bitcoin. Advanced PoS security protecting against long-range attacks.
3. **Control Plane for BSN Ecosystem**: Orchestrating security and liquidity for all connected Bitcoin Secured Networks.

**Current On-chain Ecosystem:**
- Over 57,000 BTC staked by early adopters
- Finality Providers use staked BTC to secure Babylon Genesis
- BABY token enables decentralized protocol governance
- Upcoming cross-chain integrations with L1s, rollups, and DeFi protocols

### Testnet

Babylon Genesis Testnet is a public testing environment for developers and the community to safely explore, build, and experiment with features before mainnet deployment.

**What Developers Can Do:**
- DApp Development: Deploy and test decentralized applications
- BTC Staking Integration (Test Mode): Experiment with Bitcoin staking mechanics
- Cross-Chain Messaging: Test interoperability features
- Validator & Finality Provider Operations: Run validator nodes in a risk-free environment
- On-Chain Governance Simulation: Propose and vote on protocol upgrades
- DeFi Primitives: Deploy and interact with DeFi primitives
- APIs & SDKs: Integrate and test API endpoints and SDK libraries

### Chain Information

#### Babylon Genesis Mainnet

| Property | Value |
|----------|-------|
| Chain ID | `bbn-1` |
| Chain Name | `Babylon Genesis Mainnet` |
| Binary Name | `babylond` |
| Version | `v1.0.1` |
| Genesis Date | `2025-03-15` |
| Genesis File | [Babylon Github](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/network-artifacts/genesis.json) |
| Seed Nodes | [Babylon Github](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/network-artifacts/seeds.txt) |
| Peers | [Babylon Github](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/network-artifacts/peers.txt) |

#### Babylon Genesis Testnet

| Property | Value |
|----------|-------|
| Chain ID | `bbn-test-6` |
| Chain Name | `Babylon Testnet` |
| Binary Name | `babylond` |
| Version | `v2.3.1` |
| Genesis Date | `2025-10-12` |
| Genesis File | [Babylon Github](https://github.com/babylonlabs-io/networks/blob/main/bbn-test-6/network-artifacts/genesis.json) |
| Seed Nodes | [Babylon Github](https://github.com/babylonlabs-io/networks/tree/main/bbn-test-6/network-artifacts/seeds.txt) |
| Peers | [Babylon Github](https://github.com/babylonlabs-io/networks/tree/main/bbn-test-6/network-artifacts/peers.txt) |

### Node Information

#### Babylon Genesis Mainnet Endpoints

Endpoints for Phase 2 Babylon Genesis Mainnet (`bbn-1`).

**Polkachu:**
| Endpoint Type | URL |
|-------------|----------|
| RPC (Pruned) | `https://babylon-rpc.polkachu.com` |
| RPC (Archive) | `https://babylon-archive-rpc.polkachu.com` |
| LCD (Pruned) | `https://babylon-api.polkachu.com` |
| LCD (Archive) | `https://babylon-archive-api.polkachu.com` |
| gRPC (Pruned) | `babylon-grpc.polkachu.com:20690` |
| gRPC (Archive) | `babylon-archive-grpc.polkachu.com:20690` |

#### Babylon Genesis Testnet Endpoints

Endpoints for Phase 2 Babylon Genesis Testnet (`bbn-test-6`).

**Polkachu:**
| Endpoint Type | URL |
|-------------|----------|
| RPC | `https://babylon-testnet-rpc.polkachu.com` |
| LCD | `https://babylon-testnet-api.polkachu.com` |
| gRPC | `babylon-testnet-grpc.polkachu.com:20690` |

## Staker Guides

### Stakers Overview

Babylon Genesis implements a **dual-staking model** that combines the security of BTC (a PoW asset) with the efficiency of Proof-of-Stake consensus. Both BTC holders and BABY token holders can participate in securing the network while earning rewards.

#### Bitcoin (BTC) Staking

BTC staking enables Bitcoin holders to stake their assets directly on the Bitcoin network in a self-custodial manner without wrapping or bridging. BTC stakers delegate to Finality Providers who enhance the security of the PoS chain.

Key Features:
- Self-custodial: Maintain direct control of your Bitcoin
- Native operation: No wrapped tokens or bridges required
- Trustless execution: No reliance on third parties
- Slashing capability: Protocol-enforced penalties for malicious behavior
- Flexible delegation: Delegate across multiple Finality Providers

Benefits:
- Earn BABY rewards: 1% of annual inflation allocated to BTC stakers
- Co-staking rewards: Earn additional 2.35% annual inflation by also staking BABY tokens
- Secure the network
- Maintain Bitcoin ownership
- Fast unbonding: ~2 days compared to typical 21 days

#### BABY Token Staking

BABY staking is a native staking mechanism that secures the Babylon Genesis chain. BABY token holders delegate to chain validators to accrue inflationary rewards proportional to their stake.

Key Features:
- Epoch-based staking: Delayed execution queue for enhanced security
- Fast unbonding: ~2 days via Bitcoin timestamping protocol
- Governance participation: Voting power in chain governance
- Partial slashing: 5% slashing for double-signing violations

Benefits:
- Earn rewards: 2% of annual inflation allocated to BABY stakers
- Co-staking rewards: Earn additional 2.35% annual inflation by also staking BTC
- Governance rights
- Fast unbonding

#### Reward Distribution

The annual inflation (5.5%, reduced from 8%) is distributed among:
- BTC stakers: 1% of annual inflation (Finality Providers can charge commission)
- BABY stakers: 2% of annual inflation (CometBFT validators can charge commission)
- Co-staking rewards: 2.35% of annual inflation (for users staking both BTC and BABY)
- Finality Provider compensation: 0.075% of annual inflation
- Validator compensation: 0.075% of annual inflation

#### Risk Considerations

**BTC Staking Risks:**
- Slashing risk: 0.1% maximum penalty for protocol violations
- Finality Provider risk: Choose reliable Finality Providers
- Market volatility

**BABY Staking Risks:**
- Slashing risk: 5% penalty for validator double-signing
- Validator risk: Choose reliable validators
- Market volatility

#### Co-Staking

Co-staking allows earning additional rewards by staking both Bitcoin (BTC) and BABY tokens simultaneously using the same BABY address. Rewards come from a dedicated pool representing 2.35% of annual inflation.

Co-staking weight formula:
```
w = min(B_BABY / 20,000, B_BTC)
```

Where B_BABY = Total BABY staked, B_BTC = Total BTC staked to active Finality Providers.

Every 20,000 BABY staked makes 1 BTC eligible for co-staking rewards. The optimal ratio is 20,000 BABY per 1 BTC.

CRITICAL: Both BTC and BABY staking must use the exact same BABY address. If the addresses differ, you will receive ZERO co-staking rewards.

#### Fast Unbonding

Both BTC and BABY staking benefit from Babylon's Bitcoin Timestamping protocol:
- ~2 days unbonding vs typical 21 days
- Bitcoin checkpoint verification ensures security
- Automatic token release once confirmations are met

### BTC Staking

There are several ways a user can perform self-custodial staking on Babylon, including through supported wallets, custody services, exchanges, and liquid staking token projects.

### BTC Staking Tools

#### Wallets

**Extension Wallets supporting BTC Staking and Reward Claiming:** OKX, Onekey (including hardware), Bitget, Cactus, Keystone (hardware), Tomo, Unisat Wallet, Keplr, Cosmostation, Leap wallet, Imtoken, Binance, CoinEX, Coldlar.

**Mobile Wallets supporting BTC Staking and Reward Claiming:** OKX, Onekey, Bitget, Gate wallet, Unisat Wallet, Keplr, Cosmostation, Leap wallet, Coldlar (hardware via mobile).

#### Custody Services

Supported: Anchorage, Hex Trust, Cobo, Chainup, Ceffu, Amber, Bitgo.

#### Exchanges

Supported: Binance, Bitrue, OKX, Gate, Bitget, CoinEX, Coinone.

#### Liquid Staking Token Projects

Lombard (LBTC), Solv (SolvBTC.BBN), PumpBTC, Bedrock (UniBTC), Lorenzo (stBTC), Acorn/Amber (aBTC), Babypie (mBTC), pSTAKE (yBTC), Kinza (kBTC).

### Unbonding via CLI

#### Prerequisites

- Running Bitcoin node (`bitcoind`) with a legacy wallet on Bitcoin mainnet
- BTC Staker installation (requires Go 1.21+)
- Babylon keyring with tokens

#### Setup Steps

1. Download and extract Bitcoin Core binary (v26.0)
2. Create and start bitcoind systemd service with `-deprecatedrpc=create_bdb -mainnet -server -txindex`
3. Create legacy wallet using `bitcoin-cli -named createwallet wallet_name=btcstaker passphrase="<passphrase>" load_on_startup=true descriptors=false`
4. Install BTC Staker from `https://github.com/babylonlabs-io/btc-staker.git`
5. Configure `stakerd.conf` with Babylon and BTC node settings

#### Unbonding BTC Stakes

```shell
stakercli daemon unbond \
  --staking-transaction-hash `your_staking_transaction_hash`
```

The unbond command builds the unbonding transaction, sends it to Babylon Genesis chain, waits for signatures from Covenant Emulators, then sends the transaction to the Bitcoin blockchain.

Minimum unbonding time: 301 BTC blocks.

#### Withdraw Staked BTC

```shell
stakercli daemon unstake \
  --staking-transaction-hash `your_staking_transaction_hash`
```

Wait for staking/unbonding transaction timelock to expire before unstaking.

### Geo Blocking

Babylon's staking website and API services excludes users from certain jurisdictions to comply with local regulations.

**Restricted Territories** (cannot load website): Afghanistan, Belarus, Bosnia and Herzegovina, Burundi, Central African Republic, China, Crimea, Cuba, Democratic People's Republic of Korea, Democratic Republic of the Congo, Donetsk Region of Ukraine, Eritrea, Guinea, Guinea-Bissau, Haiti, Iran, Iraq, Lebanon, Libya, Luhansk Regions of Ukraine, Mali, Myanmar, Nicaragua, Russia, Somalia, South Sudan, Sudan, Syria, Venezuela, Yemen, Zimbabwe.

**Excluded Jurisdictions** (can load website but cannot connect wallets): United States of America, Canada, Australia.

VPN IPs are also blocked based on a Cloudflare managed list.

### Liquid Staking Tokens

Liquid Staking Tokens (LSTs) are tokens that stake on Babylon on behalf of token holders. They are intermediaries that enable individuals to participate in staking while maintaining liquidity.

When staking via LST protocols:
- The holder is not directly participating in Babylon staking
- The protocol manages the holder's stake and receives the points/rewards
- The holder is trusting the liquid staking protocol with their Bitcoin

LST protocols handle: managing staking transactions, performing delegation selection, handling reward distribution, maintaining the proper ratio between staked BTC and LSTs.

### BABY Staking

BABY staking is a native staking mechanism that secures the Babylon Genesis - the first Bitcoin Supercharged Network and a Proof of Stake chain. Token holders delegate to chain validators to accrue inflationary rewards proportional to their stake.

#### Benefits

- Earn rewards from annual inflation allocated to BABY stakers
- Secure the network
- Fast unbonding (~2 days)
- Governance participation with voting power

#### The Staking Process

1. **Submission**: Send a BABY staking request through supported wallets
2. **Confirmation**: System confirms receipt of request
3. **Queuing**: Request joins the queue, waiting for the current epoch to end
4. **Funds Status**: Funds remain available in wallet until the epoch ends

#### Slashing Conditions

- Validators can only be slashed for double signing (proposing two different blocks at the same height)
- When slashing occurs, 5% of delegated tokens are slashed, 95% returned to delegator
- All slashing events are recorded on-chain and visible through explorers

#### Fast Unbonding

1. Delegator submits unbonding request, queued for processing at epoch boundary
2. Protocol commits cryptographic hash of chain state to Bitcoin blockchain
3. Required confirmation depth: 300 Bitcoin blocks (~2 days)
4. Once confirmations reach threshold, tokens are automatically released

### Co-Staking Guide

Co-staking allows earning extra rewards by staking both Bitcoin (BTC) and BABY tokens simultaneously.

**Key Benefits:**
- Earn an additional 2.35% annual inflation rewards
- Maximize returns by participating in both validation and finality provision

#### Step-by-Step Guide

**Step 1: Stake Bitcoin (BTC)**
1. Connect wallet to [Babylon dashboard](https://staking.babylonlabs.io/)
2. Choose an active Finality Provider
3. Create a BTC delegation with desired amount
4. Wait for activation: PENDING -> VERIFIED -> ACTIVE

**Step 2: Stake BABY Tokens** (using the SAME BABY address)
1. Ensure same wallet connection as Step 1
2. Choose a CometBFT validator
3. Delegate BABY tokens
4. Verify delegation is active

**Step 3: Understand Co-Staking Rewards**

Formula: `w = min(B_BABY / R, B_BTC)` where R = 20,000 (co-staking factor).

| BTC Staked | Optimal BABY | Co-Staking Weight | Efficiency |
|------------|--------------|-------------------|------------|
| 0.1 BTC | 2,000 BABY | 0.1 BTC-equivalent | 100% |
| 0.5 BTC | 10,000 BABY | 0.5 BTC-equivalent | 100% |
| 1 BTC | 20,000 BABY | 1 BTC-equivalent | 100% |
| 1 BTC | 10,000 BABY | 0.5 BTC-equivalent | 50% |

Reward: `Your Reward = Total Co-Staking Pool x (Your Weight / Total Weight of All Co-Stakers)`

**Step 4: Monitor and Withdraw**

Co-staking rewards are automatically included when withdrawing BTC staking rewards. Click the "Rewards" button in the dashboard.

**Important:** All BABY delegations are summed together for co-staking calculation, regardless of how many validators you delegate to. Diversifying across validators does not reduce co-staking rewards.

## Developer Resources

### Developers Overview

Babylon is a platform for developers to leverage Bitcoin and create unique web3 applications.

#### Pathways

1. **Bitcoin Staking Integration**: Integrate with Babylon's Bitcoin staking protocol, leverage Bitcoin's economic security without bridging or wrapping assets. Key technologies: CosmWasm, IBC, native Bitcoin staking protocols.

2. **Smart Contract Development**: Deploy CosmWasm smart contracts, create decentralized applications with Bitcoin-backed security. Uses Rust-based development (CosmWasm).

3. **Infrastructure and Tooling**: Build monitoring and validation tools, develop Bitcoin timestamping services, design Finality Provider management systems, create explorer tools.

#### Getting Started

1. Explore Documentation: Technical Specifications, Smart Contract Deployment Guides, Protocol Architecture
2. Setup Development Environment: Install Babylon node, configure CosmWasm development tools
3. Explore Babylon Genesis: Chain overview, chain information

### Babylon Genesis Chain

Babylon Genesis is a Cosmos SDK chain, backed by Bitcoin staking, serving as the coordination layer for the Babylon protocol.

| Component | Technology | Version |
|-----------|------------|---------|
| Consensus | CometBFT (a Tendermint fork) | v0.50.9 |
| Framework | Cosmos SDK | v0.50.9 |
| Smart Contracts | CosmWasm | v2.1.3 |
| Relayer | IBC | v1.0.1 |

The chain implements custom modules for Bitcoin staking, checkpointing, and finality.

### Smart Contract Deployment

#### Prerequisites
- Rust (for building CosmWASM contracts)
- Docker (for contract optimization)

#### Deployment Steps

1. **Repository Setup**: Clone the repository with submodules for Babylon core and contract dependencies.

2. **Babylond CLI Installation**: Build and install via `cd babylon && make install`.

3. **Environment Configuration**: Load network-specific variables (chain ID, fee token, RPC/API endpoints).

4. **Wallet Management**: Create test wallet with `babylond keys add test-key --keyring-backend=test`. Fund via testnet faucet.

5. **Contract Building**: Navigate to contract directory and run `cargo run-script optimize`.

6. **Contract Deployment**:
   - Store: `babylond tx wasm store ./artifacts/storage_contract-aarch64.wasm --from=$key --gas=auto --gas-prices=0.002$feeToken --gas-adjustment=1.3 --chain-id="$chainId" -b=sync --yes`
   - Get Code ID: Query `wasm list-code` filtered by your address
   - Instantiate: `babylond tx wasm instantiate $codeID '{}' --from=$key --no-admin --label="storage_contract"`

7. **Contract Interaction**:
   - Save data: `babylond tx wasm execute $contractAddress "$executeMsg"`
   - Query data: `babylond query wasm contract-state smart $contractAddress`

### Simple Staking dApp

A reference implementation of a staking app for completing staking, delegation and unbonding through wallet integration.

- **Testnet**: https://btcstaking.testnet.babylonlabs.io
- **Mainnet**: https://btcstaking.babylonlabs.io
- **Source**: https://github.com/babylonlabs-io/babylon-toolkit/tree/main/services/simple-staking

Key Features: Complete staking workflow, multiple wallet integrations (BTC & Cosmos wallets), secure transaction signing, geographic blockage for compliance, dashboard with staking positions and rewards.

Tech Stack: Next.js 14, Tailwind CSS, TypeScript, React, @babylonlabs-io/wallet-connector, @babylonlabs-io/btc-staking-ts, @cosmjs/stargate.

### Wallet Integration

This guide is designed for wallet providers aiming to integrate with the Babylon Genesis chain.

Two types of integration needed:

1. **Native wallet support of Babylon Genesis chain**: Enable native support including token balances, transfers, and staking operations.
2. **Support of Bitcoin staking**: Participate via web application integration or native wallet integration.

### Bitcoin Wallet Integration

#### Extension Wallets

**Option 1**: Be added to a third party's bitcoin staking website. Integrate with Tomo Wallet Connect.
**Option 2**: Host your own bitcoin staking website using the reference [implementation](https://github.com/babylonlabs-io/simple-staking/) and [TypeScript](https://github.com/babylonlabs-io/btc-staking-ts/) / [Golang](https://github.com/babylonlabs-io/babylon/tree/main/btcstaking/) libraries.
**Option 3**: Develop bitcoin staking as a native feature connecting to Babylon Staking API or your own backend.

#### Mobile App Wallets

**Option 1**: Embed a third-party Bitcoin staking website, ensure wallet interface adheres to [Injectable Wallet interface](https://github.com/babylonlabs-io/wallet-connector).
**Option 2**: Host your own website and embed in mobile app.
**Option 3**: Develop bitcoin staking as a native mobile feature.

#### Hardware Wallets

**Option 1**: Develop bitcoin staking as a native feature.
**Option 2**: Integrate via a compatible software wallet that is bitcoin staking enabled.

### Staking Backend

The Bitcoin Staking Backend is a system designed to facilitate Bitcoin staking operations on the Babylon network. It comprises specialized services that extract, validate, and transform blockchain data from both Bitcoin and Babylon chains.

#### Prerequisites

- Bitcoin Full Node
- Babylon Node
- MongoDB Clusters
- RabbitMQ
- Global Configuration

#### Services (deploy in order)

1. **Staking Indexer**: Monitors both blockchains and processes staking events
2. **Staking Expiry Checker**: Manages expired delegations and state transitions
3. **Staking API Service**: Provides API endpoints for staking operations

### Global Parameters

Global staking parameters for Babylon Phase 1 Mainnet. Content is maintained in the [networks repository](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/parameters/README.md).

### Developer FAQs

**Q: What is Babylon Genesis?**
A: A Cosmos SDK-based blockchain built to be a secure and scalable platform for decentralized applications.

**Q: What programming languages can I use?**
A: Rust (primary for CosmWasm), support for Cosmos SDK-based development tools.

**Q: How do I deploy a dApp on the testnet?**
A: Develop CosmWasm smart contract in Rust, compile to Wasm, deploy using Babylon CLI, interact via Keplr wallet or CLI tools.

**Q: How does Bitcoin enhance my blockchain's security?**
A: Bitcoin provides economic security through staking, slashable safety mechanisms, trustless stake verification, and protection against long-range attacks.

**Q: What development tools are available?**
A: Babylon CLI, CosmWasm development kit, IBC relayer tools, Bitcoin node integration libraries, Keplr wallet integration.

**Q: Is development completely open-source?**
A: Open-source core protocols; Babylon Labs has certain proprietary repositories not yet open-source.

## Operator Guides

### Operators Overview

Babylon Labs offers babylon CLI, babylon node and peripheral services to operators who want to participate in the Babylon network.

#### Node Types

**Full Node**: Downloads entire blockchain history, serves RPC/gRPC requests, can be upgraded to Validator or Finality Provider nodes.

**Babylon Genesis Validator Node**: Proposes new blocks, votes on blocks, secures network through BTC staking, earns rewards and fees.

**Finality Provider Node**: Commits public randomness, signs blocks using EOTS, submits finality signatures, earns commission from delegated stakes.

**Archive Node**: Maintains complete state history for analytics, explorers, historical queries, and API services.

#### Networks
- Phase 1 Mainnet (Locking on Bitcoin Chain)
- Phase 2 testnet (Staking on Babylon Genesis)
- Phase 3 devnet (Bitcoin Staking expansion)

#### Key Management
- Bitcoin schnorr private key (critical for staking and EOTS signing)
- Validator account private key (critical for proposing blocks)
- Finality Provider account private keys (critical for signing finality)

Operators should use hardware security modules (HSMs) when possible.

#### Monitoring & Backup

**Monitoring:** System metrics (CPU, memory, disk, network), node status (sync, block height, peers), validator metrics (consensus participation), finality provider metrics (EOTS status, signatures), API/RPC endpoint health.

**Backups:** Daily state sync snapshots, weekly data archives, configuration file backups, secure key management backups, regular recovery testing.

### Node Installation

The node installation guide is maintained remotely. Content is fetched from the [networks repository](https://github.com/babylonlabs-io/networks/blob/main/bbn-1/babylon-node/README.md).

### Babylon CLI Overview

`babylond` CLI commands reference:

- `add-genesis-account`: Add a genesis account to genesis.json
- `collect-gentxs`: Collect genesis transactions
- `comet`: CometBFT subcommands
- `config`: Utilities for managing application configuration
- `create-bls-key`: Create BLS key pair for checkpointing
- `debug`: Debugging utilities
- `export`: Export blockchain state
- `gen-helpers`: Commands for creating genesis state with Bitcoin staking data
- `gen-tx`: Generate a transaction
- `generate-bls-pop`: Generate a BLS keypair
- `init`: Node initialization
- `keys`: Key management
- `migrate`: Protocol version migration
- `module-hash-by-height`: Get module hash at specific height
- `module-sizes`: Get module sizes
- `prepare-genesis`: Prepare genesis.json file
- `query`: Query the network
- `rollback`: Perform state rollback
- `start`: Run full node with CometBFT
- `status`: Query node status
- `testnet`: Test the application
- `tx`: Send a transaction
- `validate-genesis`: Validate genesis file
- `version`: Print application version

### Validator Setup

A step-by-step guide to becoming a validator on the Babylon mainnet (bbn-1).

**Special Requirements:**
- Must participate in BLS signature voting every epoch
- Need both consensus keys and BLS keys
- Validator activation happens only at epoch boundaries

**Recommended Hardware:**
- CPU: 8 cores (minimum 4)
- RAM: 32GB (minimum 16GB)
- Storage: 2TB SSD
- Network: 1Gbps connection

#### Setup Steps

1. **Install Dependencies**: Go 1.23.1, essential tools
2. **Clone and Build Babylon**: `git checkout v2.1.0 && BABYLON_BUILD_OPTIONS="mainnet" make install`
3. **Initialize Node**: `babylond init $MONIKER --chain-id bbn-1`
4. **Download Network Config**: Genesis file and address book
5. **Configure Network**: Seeds, peers, ports, pruning, gas settings
6. **Create System Service**: systemd service for babylond
7. **Create Wallet**: `babylond keys add $WALLET`
8. **Sync Node**: Download snapshot and start
9. **Setup BLS Keys**: `babylond create-bls-key $WALLET_ADDRESS`
10. **Create Validator**: Create validator.json with pubkey, amount, commission settings, then submit with `babylond tx staking create-validator validator.json`

**Security:**
- Backup priv_validator_key.json, bls_password.txt, node_key.json
- Configure firewall (allow SSH and P2P port only)
- Secure SSH access (disable root login, use key auth)

### Finality Provider Operations

The Finality Provider operations guide is maintained in the [finality-provider repository](https://github.com/babylonlabs-io/finality-provider/blob/main/docs/finality-provider-operation.md).

### FP Registration Guide

#### Phase 1 Finality Providers (Re-registration)

Prerequisites:
- Already registered for the airdrop
- BABY account created and funded
- EOTS key from Phase 1

Steps:
1. Register on Babylon Genesis using `fpd create-finality-provider`
2. Ensure healthy finality voting once in top 60 FPs

#### New Finality Providers

Steps:
1. Create BABY account using `fpd` CLI and fund with BABY tokens
2. Set up Finality Provider node and EOTS manager
3. Initialize EOTS manager and create new EOTS key
4. Register using `fpd create-finality-provider`
5. Begin submitting finality votes once registered

**Version Information:**
- Finality Provider: v1.0.0
- Babylon Genesis node: v1.0.1

### Covenant Emulator

A guide for covenant emulator operators. The detailed documentation is maintained in the [covenant-emulator repository](https://github.com/babylonlabs-io/covenant-emulator).

### Vigilantes

The Babylon network is monitored by Babylon Validators and Vigilantes. They are critical infrastructure participants who maintain synchronization between Bitcoin and Babylon Genesis.

**Core Responsibilities:**
1. Cross-chain relay: Ensures data between Bitcoin and Babylon Genesis are accurate and synchronized
2. Bitcoin Timestamping: Records and verifies Bitcoin block headers on Babylon Genesis
3. Monitor integrity: Maintains reliable and trustless setup of the Babylon protocol

**Prerequisites:**
- A synced Bitcoin full node
- A synced Babylon full node

**Operational Considerations:** Consistent uptime, regular software updates, secure key management, network connectivity.

### Staker CLI

BTC-Staker is a toolset for Bitcoin staking with two components:

1. `stakerd`: Daemon managing connections to Babylon and Bitcoin nodes
2. `stakercli`: CLI for interaction with stakerd (stake, withdraw, unbond, retrieve Finality Providers)

#### Setup

1. Set up Bitcoin node with legacy wallet
2. Install BTC Staker (requires Go 1.21+) from `https://github.com/babylonlabs-io/btc-staker.git`
3. Create Babylon keyring with funds
4. Configure stakerd.conf (Babylon, BTC node, wallet settings)

#### Staking Operations

**Stake Bitcoin:**
```bash
stakercli daemon stake \
  --staker-address <address> \
  --staking-amount 1000000 \
  --finality-providers-pks <fp-pk> \
  --staking-time 10000
```

**Unbond:**
```bash
stakercli daemon unbond \
  --staking-transaction-hash <tx-hash>
```

**Withdraw:**
```bash
stakercli daemon unstake \
  --staking-transaction-hash <tx-hash>
```

### Operator FAQs

**Q: What are the hardware requirements?**
A: At least 8 GB RAM for both Babylon node and Finality Provider. Recommended to run on separate instances.

**Q: What ports should I open?**
A: RPC: 26657, gRPC: 9090, P2P: 26656.

**Q: How can I check my Validator's status?**
A: `babylond q staking validator <your-valoper-address>`

**Q: What should I do if my Validator is jailed?**
A: Check logs, run `babylond tx slashing unjail`, ensure validator is active and signing correctly.

**Q: How do I register my Finality Provider?**
A: Ensure EOTS key exists, run `fpd keys add`, use `fpd create-finality-provider`, start with `fpd start --eots-pk <your-eots-pk>`.

**Q: How do I prevent duplicate finality votes?**
A: Use a single, dedicated Babylon RPC node with transaction indexing enabled.

**Q: What precautions when resetting node?**
A: Always backup `priv_validator_key.json` before any reset. `unsafe-reset-all` may remove BLS keys.

**FP Connection Suggestions:**
- Do not use multiple nodes behind a load balancer
- Always connect to a single, trusted Babylon RPC node
- Enable transaction indexing on your RPC node

## Specifications

### Bitcoin Staking Scripts

Technical Bitcoin script specifications for staking. The detailed specification is maintained in the [Babylon repository](https://github.com/babylonlabs-io/babylon/blob/main/docs/staking-script.md).

### Staking Transactions

Observable Staking Transactions Specification. The detailed specification is maintained in the [Babylon repository](https://github.com/babylonlabs-io/babylon/blob/release/v2.3.x/docs/transaction-impl-spec.md).

## Security

### Audit Reports

Babylon protocol is audited by industry leading web3 security firms.

#### Phase 1 Bitcoin Staking Protocol Audits

- **Coinspect Phase-1 Audit Report**: Source Code Audit (June 2024)
- **Coinspect Phase-1 Incremental Audit Report**: Cap-3 updates (October 2024)
- **Zellic Phase-1 Audit Report**: Source Code Audit (June 2024)
- **Cantina/Sherlock**: Source Code Security Competition (June 2024)

#### Babylon Genesis Chain Audits

- **Coinspect Phase 2 Audit Report**: Babylon Genesis Chain Audit (March 2025)
- **Zellic Babylon Genesis Audit Report**: Babylon Genesis Chain Audit (March 2025)
- **Sherlock Security Review**: Babylon Genesis Chain Audit (March 2025)

#### V2 Upgrade Audits

- **Oak Security GmbH Audit Report**: Babylon Genesis v2 Upgrade (June 2025)
- **Informal Systems Audit Report**: Babylon Genesis v2 Upgrade Final Audit (June 2025)

#### V4 Upgrade Audits

- **Coinspect Babylon Genesis v4 Audit Report** (October 2025)
- **Halborn Babylon Genesis Audit Report** (December 2025)
- **Halborn Babylon Genesis Offchain Programs Audit Report** (January 2026)

#### Frontend Staking Application Audits

- **Halborn Frontend Staking Application Audit Report** (December 2025)

### Bug Bounties

Babylon Labs hosts a bug bounty program for the Babylon Staking Protocol on [Immunefi](https://immunefi.com/bug-bounty/babylon-labs/information/).

## Optional

### Bitcoin Staking Litepaper
Source: https://docs.babylonlabs.io/guides/research/btc_staking_litepaper/

Proof-of-Stake (PoS) chains are secured by capital but capital can be very expensive. Bitcoin
is a Proof-of-Work chain but it is also a $600 Billion asset and most of it is idle capital. We
propose the concept of Bitcoin staking which allows bitcoin holders to stake their idle bitcoins
to increase the security of PoS chains and in the process earn yield. We present a Bitcoin
staking protocol which allows bitcoin holders to trustlessly stake their bitcoins without bridging
them to the PoS chain but yet provides the chain with full slashable security guarantees. The
protocol supports fast stake unbonding to maximize the liquidity for bitcoin holders. Moreover,
the protocol is designed as a modular plug-in for use on top of many different PoS consensus
algorithms and provides a primitive upon which restaking protocols can be built. A system
architecture is proposed for scaling the protocol to many stakers and many PoS chains with
a Bitcoin-staked Babylon Genesis acting as a control plane to synchronize between Bitcoin and
the PoS chains. Bitcoin staking enables an important new use case for Bitcoin and takes a
significant step towards integrating Bitcoin and the Proof-of-Stake economy.

[Read the Paper](/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)

### Bitcoin Timestamping Research Paper
Source: https://docs.babylonlabs.io/guides/research/btc_timestamping/

Bitcoin is the most secure blockchain in the world,
supported by the immense hash power of its Proof-of-Work
miners. Proof-of-Stake chains are energy-efficient, have fast
finality but face several security issues: susceptibility to nonslashable long-range safety attacks, low liveness resilience and
difficulty to bootstrap from low token valuation. We show that
these security issues are inherent in any PoS chain without an
external trusted source, and propose a new protocol, Babylon,
where an off-the-shelf PoS protocol checkpoints onto Bitcoin to
resolve these issues. An impossibility result justifies the optimality
of Babylon. A use case of Babylon is to reduce the stake
withdrawal delay: our experimental results show that this delay
can be reduced from weeks in existing PoS chains to less than
5 hours using Babylon, at a transaction cost of less than 10K
USD per annum for posting the checkpoints onto Bitcoin.

[Read on Arxiv.org](https://arxiv.org/pdf/2207.08392)

### A Bitcoin-Charged Crypto Economy with Trustless Vaults
Source: https://docs.babylonlabs.io/guides/research/btc_trustless_vault/

Bitcoin is by far the largest crypto asset by market capitalization, yet the vast majority of it
remains idle. Today, less than 1% of all bitcoins are bridged to smart contract platforms, where
most decentralized finance (DeFi) activity takes place. A key barrier to greater participation is
that existing Bitcoin bridges are either centralized or rely on significant trust assumptions. In
fact, due to the lack of covenants in the Bitcoin scripting language, there are no known ways to
build trustless Bitcoin bridges.

We bypass this barrier by introducing a different primitive: trustless Bitcoin vaults. Bitcoin
holders deposit their BTC into these on-chain vaults in a self-custodial fashion. The bitcoins in
each vault are tied to a specific smart contract protocol on an external chain. These vaults are
programmable, and withdrawals are permitted only when a zero-knowledge proof of a specific
smart contract state is verified on the Bitcoin chain. Together with an appropriate Bitcoin
scripting design of the vault, this eliminates the need for mutual trust among parties.
We demonstrate how this construction enables the use of native Bitcoin--without wrapping or
bridging--as collateral in many DeFi applications, including lending, stablecoin issuance, and
perpetual DEXs.

Leveraging recent advances in BitVM3, we present experimental results
showing that these vaults can be operated with minimal on-chain overhead--an essential
requirement for scaling trustless Bitcoin-backed DeFi. Bitcoin vaults built on top of the Babylon
Bitcoin staking protocol further improve capital efficiency by allowing staked BTC to act as
collateral in DeFi protocols. We conclude by discussing how trustless Bitcoin vaults significantly
strengthen the existing Babylon ecosystem and the utility of BABY as the token for its
decentralized governance.

[Read the Paper](https://docs.babylonlabs.io/papers/trustless-bitcoin-vaults.pdf)

### Chain Explorers
Source: https://docs.babylonlabs.io/developers/babylon_genesis_chain/explorers/

#### Babylon Genesis Mainnet

Block scanners for Phase 2 Babylon Genesis Mainnet (`bbn-1`).

| Service | URL |
|---------|-----|
| [MintScan](https://www.mintscan.io/babylon) | `https://www.mintscan.io/babylon` |
| [Xangle](https://babylon-explorer.xangle.io/mainnet/home) | `https://babylon-explorer.xangle.io/mainnet/home` |

#### Babylon Genesis Testnet

Block scanners for Phase 2 Babylon Genesis Testnet (`bbn-test-6`).

| Service | URL |
|---------|-----|
| [MintScan](https://www.mintscan.io/babylon-testnet) | `https://www.mintscan.io/babylon-testnet` |
| [Xangle](https://babylon-explorer.xangle.io/testnet/home) | `https://babylon-explorer.xangle.io/testnet/home` |

### Getting Testnet BABYs
Source: https://docs.babylonlabs.io/developers/babylon_genesis_chain/baby_faucets/

A list of faucets is available for developers to claim testnet BABY tokens.

- [Hoodscan.io Babylon Genesis Testnet Faucet](https://faucet.hoodscan.io/)
- [Xangle Babylon Genesis Testnet Faucet](https://babylon-explorer.xangle.io/testnet/faucet)
- [IT Rocket Babylon Genesis Testnet Faucet](https://testnet.itrocket.net/babylon/faucet)

#### HoodScan tBABY Faucet

To claim testnet tokens from the HoodScan tBABY Faucet, you will need to:

1. Create a testnet BABY wallet account to obtain a wallet address.
2. Visit the [HoodScan tBABY Faucet](https://faucet.hoodscan.io/) and in
the chain selection dropdown, select "Babylon Testnet".
3. Select your wallet provider.
4. Click the "Request Tokens" button.

#### Xangle tBABY Faucet

To claim testnet tokens from the Xangle tBABY Faucet, you will need to:

1. Create a testnet BABY wallet account to obtain a wallet address.
2. Visit the [Xangle tBABY Faucet](https://babylon-explorer.xangle.io/testnet/faucet)
3. Enter your wallet address and click the "Request tBABY" button.

#### IT Rocket tBABY Faucet

To claim testnet tokens from the IT Rocket tBABY Faucet, you will need to:

1. Create a testnet BABY wallet account to obtain a wallet address.
2. Visit the [IT Rocket tBABY Faucet](https://testnet.itrocket.net/babylon/faucet)
3. Enter your wallet address and click the "GET TOKENS" button.

Claim Rules: 0.02 tBABY each request and no more than 1 tBABY every 24 Hours per
IP address or wallet address.

Note: These testnet tokens have no real value and are not eligible for mainnet's staking or voting.

### Getting Signet BTCs
Source: https://docs.babylonlabs.io/developers/babylon_genesis_chain/btc_faucets/

Signet BTC is of no actual value and is not redeemable for real BTC. It is used solely for
testing the Babylon Bitcoin Staking Protocol.

Babylon Labs is not a maintainer of the Signet BTC project and has only limited supply
of Signet BTC for testing purposes.

There are several Signet BTC faucets available for developers to claim testnet BTC.

#### HoodScan Signet BTC Faucet

The [HoodScan Signet BTC Faucet](https://faucet.hoodscan.io/) is a simple faucet that
allows developers to claim sBTC.

To claim sBTC, follow these steps:

1. **Create a Signet BTC Wallet**:
   - Set up a Bitcoin wallet that supports Native SegWit (NSW)
   - Copy your NSW Bitcoin wallet address

2. **Access the Faucet**:
   - Visit the [HoodScan Signet BTC Faucet](https://faucet.hoodscan.io/)
   - In the "Select a Chain..." dropdown, choose "Bitcoin"
   - Select "Bitcoin Signet" from the network options

3. **Request Tokens**:
   - Paste your NSW Bitcoin wallet address
   - Click the "Request Tokens" button

The sBTC will be sent to your wallet address shortly after submitting the request.

### Babylon Wallet Setup Guide
Source: https://docs.babylonlabs.io/developers/babylon_genesis_chain/wallet_setup/

#### Overview

Developers can set up a Babylon wallet using two primary methods:
1. Babylon CLI (Recommended for Power Users)
2. Keplr Browser Extension (Easy Setup)

#### Method 1: Babylon CLI Wallet Setup

**Prerequisites**
- Go 1.21+
- Git
- Rust 1.84+

**Installation Steps**

1. Clone the Babylon Repository
```bash
git clone https://github.com/babylonlabs-io/babylon.git
cd babylon
git checkout v1.0.0-rc.3
```

2. Install Babylon Binary
```bash
make install
```

3. Verify Installation
```bash
babylond version
# Expected output: v1.0.0-rc.3
```

4. Create Wallet
```bash
babylond keys add my-babylon-key \
  --keyring-backend file \
  --home /path/to/babylon/home
```

**Security Note:**
- Securely store the generated mnemonic phrase
- This is your ONLY way to recover the wallet

#### Method 2: Keplr Browser Extension

1. Install Keplr Wallet
   - Visit [Keplr Website](https://keplr.app/)
   - Follow browser extension installation instructions

2. Add Babylon Network
   - Open Keplr
   - Navigate to network settings
   - Select "Add Chain"
   - Choose `Babylon Phase 2 Testnet` configuration
   - Click "Save"

3. Create a Wallet
   - Open Keplr
   - Click "Create Wallet"
   - Follow the on-screen instructions

#### Obtaining Test Tokens

For a complete list of available faucets including rate limits and usage instructions, see the [BABY Faucets documentation](/developers/babylon_genesis_chain/baby_faucets).

Quick options:
- [Xangle Testnet Faucet](https://babylon-explorer.xangle.io/testnet/faucet)
- [HoodScan Faucet](https://babylon-testnet.hoodscan.io/faucet)
- [IT Rocket Faucet](https://testnet.itrocket.net/babylon/faucet)

#### Testnet Details
- **Chain ID:** `bbn-test-6`
- **Token Symbol:** BABY
- **Token Denom:** ubbn
- **Network Type:** Cosmos SDK-based

#### Best Practices
- Never share your mnemonic phrase
- Regularly backup wallet credentials
- Use strong, unique passphrases for your keyring

### IBC Relayer Setup Guide
Source: https://docs.babylonlabs.io/operators/babylon_validators/ibc_relayer_setup/

Babylon uses IBC (Inter-Blockchain Communication protocol) to enable cross-chain communication.
To support this capability it relies on relayers, processes that can be run by anyone which constantly scan for outbound packets on one chain and submits these packets alongside corresponding proofs on the destination chain.
This section describes how one can setup a relayer and create new connections between chains.

There are two standard implementations:

- Hermes built in Rust
- Go Relayer built in Go

The following guide explains how to establish IBC connections and relay packets between Celestia Mocha testnet and Babylon testnet networks by using the Hermes relayer.

#### Hermes
Hermes is an open-source Rust implementation of an IBC relayer released as part of the ibc-relayer-cli crate.
It includes a CLI for relaying packets between Cosmos SDK chains, as well as Prometheus metrics and a REST API.

**Prerequisites**
- [Go](https://go.dev/doc/install)
- [Rust](https://rustup.rs/)

Please follow the steps at [Hermes Quick Start](https://hermes.informal.systems/quick-start/) to install Hermes.
Before proceeding, verify that Hermes is installed correctly by running `hermes version`.

#### Configuration

**Prerequisites**
- **Funded** Celestia Mocha account
- **Funded** Babylon testnet account

To acquire testnet tokens for Celestia Mocha, use [Celestia Testnet Faucet bot](https://discord.gg/celestiacommunity).
To get testnet tokens for Babylon testnet, use [Babylon Genesis Testnet Faucet](https://babylon-explorer.xangle.io/testnet/faucet).

**Configure the chains**

After installing Hermes, create `.hermes` folder in your `$HOME` directory and create a config file.

```bash
mkdir $HOME/.hermes
```

Copy `config.toml` file from the `hermes` repository to the `.hermes` folder.

```bash
cp $HOME/hermes/config.toml $HOME/.hermes/config.toml
```

For this tutorial, we will be using the following chains:

- Celestia's mocha-4 testnet
- Babylon's Phase 2 testnet

Edit the Hermes configuration.

```bash
vim $HOME/.hermes/config.toml
```

```toml
[global]
log_level = "info"

[mode.clients]
enabled = true
refresh = true
misbehaviour = true

[mode.connections]
enabled = false

[mode.channels]
enabled = false

[mode.packets]
enabled = true
clear_interval = 100
clear_on_start = true
tx_confirmation = false
auto_register_counterparty_payee = false

[rest]
enabled = false
host = "127.0.0.1"
port = 3000

[telemetry]
enabled = false
host = "127.0.0.1"
port = 3001

[telemetry.buckets.latency_submitted]
start = 500
end = 20000
buckets = 10

[telemetry.buckets.latency_confirmed]
start = 1000
end = 30000
buckets = 10

[[chains]]
id = 'bbn-test-6'
type = "CosmosSdk"
rpc_addr = 'https://babylon-testnet-rpc.polkachu.com'
grpc_addr = 'http://babylon-testnet-grpc.polkachu.com:20690'
rpc_timeout = "10s"
trusted_node = false
account_prefix = "bbn"
key_name = "babylon"
key_store_type = "Test"
store_prefix = "ibc"
default_gas = 100000
max_gas = 4000000
gas_multiplier = 1.1
max_msg_num = 30
max_tx_size = 180000
max_grpc_decoding_size = 33554432
clock_drift = "5s"
max_block_time = "30s"
ccv_consumer_chain = false
memo_prefix = ""
sequential_batch_tx = false

[chains.event_source]
mode = "push"
url = "wss://babylon-testnet-rpc.polkachu.com/websocket"
batch_delay = "500ms"

[chains.trust_threshold]
numerator = "1"
denominator = "3"

[chains.gas_price]
price = 0.01
denom = "ubbn"

[chains.packet_filter]
policy = "allow"
list = [["transfer","channel-20"]]

[chains.packet_filter.min_fees]

[chains.address_type]
derivation = "cosmos"


[[chains]]
id = "mocha-4"
type = "CosmosSdk"
rpc_addr = "https://rpc-celestia-mocha.architectnodes.com"
grpc_addr = "https://grpc.celestia-mocha.com:443"
rpc_timeout = "10s"
trusted_node = false
account_prefix = "celestia"
key_name = "celestia-key"
key_store_type = "Test"
store_prefix = "ibc"
default_gas = 100000
max_gas = 400000
gas_multiplier = 1.5
max_msg_num = 30
max_tx_size = 180000
max_grpc_decoding_size = 33554432
clock_drift = "5s"
max_block_time = "30s"
ccv_consumer_chain = false
memo_prefix = ""
sequential_batch_tx = false

[chains.event_source]
mode = "push"
url = "ws://rpc-mocha.pops.one:26657/websocket"
batch_delay = "500ms"

[chains.trust_threshold]
numerator = "1"
denominator = "3"

[chains.gas_price]
price = 0.1
denom = "utia"

[chains.packet_filter]
policy = "allow"
list = [["transfer", "channel-0"]]

[chains.packet_filter.min_fees]

[chains.address_type]
derivation = "cosmos"
```

**Create/Add relayer wallets**

Now that we have successfully configured our relaying chains, we need to import the wallets that will be used for relaying. Please note that both wallets need to be funded with the native tokens of each chain.

You can use Keplr to create a wallet for Celestia Mocha and Babylon testnet.
You can get testnet tokens from faucets for both testnets via Discord:
Celestia: https://discord.gg/celestiacommunity
Cosmos Hub: https://discord.gg/cosmosnetwork

Add your seed phrase to a `.mnemonic` file and upload it to the server. Do not use wallets for anything else but relaying to avoid running into account sequence errors.

Follow the steps at [Adding Keys to Hermes](https://hermes.informal.systems/quick-start/adding-keys-to-hermes/) to add keys for each chain:

```bash
hermes keys add --chain bbn-test-6 --mnemonic-file <PATH_TO_MNEMONIC_FILE>

hermes keys add --chain mocha-4 --mnemonic-file <PATH_TO_MNEMONIC_FILE>
```

**Verify configuration files**

After editing config.toml and adding wallet keys, run the health check:

```bash
hermes health-check
hermes config validate
```

If everything was set up correctly, you should see output like:

```bash
SUCCESS performed health check for all chains in the config
SUCCESS "configuration is valid"
```

**Create clients**

First, verify that the chains do not have existing clients:

```bash
hermes query clients --host-chain mocha-4 --reference-chain bbn-test-6
```

To create a new client, use the [`create-client`](https://hermes.informal.systems/documentation/commands/path-setup/clients.html#create-client) command:

```bash
hermes create client --host-chain mocha-4 --reference-chain bbn-test-6
```

You should see output like:

```bash
SUCCESS CreateClient(
    CreateClient(
        Attributes {
            client_id: ClientId(
                "07-tendermint-27",
            ),
            client_type: Tendermint,
            consensus_height: Height {
                revision: 4,
                height: 5730919,
            },
        },
    ),
)
```

Note: Make sure that accounts on both chains are funded with the native tokens of each chain.
Otherwise, you will get an error:

```bash
ERROR foreign client error: error raised while creating client for chain mocha-4
```

Create a second client:

```bash
hermes create client --host-chain bbn-test-6 --reference-chain mocha-4
```

**Create a connection**

To create a connection between the two clients run:

```bash
hermes create connection --host-chain mocha-4 --reference-chain bbn-test-6
```

Now that the connection has been established over the clients, we need to create a new channel using an existing connection:

```bash
hermes create channel --a-chain mocha-4 --a-connection connection-654 --a-port transfer --b-port transfer
```

**Configure channels in Hermes**

Now that we have created new connections and opened channels, we need to edit config.toml again and add the newly created channels, or use the already existing ones.

For mocha-4 add:

```toml
[chains.packet_filter]
policy = "allow"
list = [["transfer", "channel-389"]]
```

For bbn-test-6 add:

```toml
[chains.packet_filter]
policy = "allow"
list = [["transfer","channel-20"]]
```

**Start the relayer**

Start the relayer via hermes start

```bash
hermes start
```

### Slashing Protection on Finality Provider
Source: https://docs.babylonlabs.io/operators/finality_providers/slashing_protection/

> Note: This content is fetched from GitHub at build time.
> Remote source: https://raw.githubusercontent.com/babylonlabs-io/finality-provider/refs/heads/main/docs/slashing-protection.md

In the BTC staking protocol, finality providers operate the
Finality Provider Daemon (`fpd`) to send finality votes to Babylon Genesis.
If a finality provider re-uses the same committed randomness
to sign two conflicting blocks on the same height,
their EOTS private key is exposed, leading to the slashing
of their delegations.
Apart from malicious behavior, honest finality providers face
[slashing risks](https://cubist.dev/blog/slashing-risks-you-need-to-think-about-when-restaking)
due to factors like hardware failures or software bugs.
To combat these risks, the finality provider program stack employs
an anti-slashing protection mechanism.

Recall that in our system, the finality provider operation stack involves
two daemons:

1. The EOTS manager daemon (`eotsd`) manages the EOTS key and responds to
signing requests from the finality provider daemon.
2. The finality provider daemon (`fpd`) connects to the Babylon Genesis node
and initiates EOTS signing requests upon a new block to finalize.

The two daemons have different responsibilities to prevent double-signing.
The anti-slashing protections of the two daemons are complementary to each other.
Even if the db file of one daemon is compromised, the protection is still
in effective, and the state will recover after restarting the service.

#### Finality provider daemon protection

**Requirement**:

- The Babylon Genesis node the daemon connects to is trusted and responsive.
- The `finality-provider.db` file is not compromised.

The finality provider daemon ensures that it will never initiate
a signing request for the same height twice if the previous request succeeds.

To achieve this, the daemon does the following:

- Maintains a local state `lastVotedHeight`, which is updated once
a vote submission succeeds, and never votes for a height that is not higher
than `lastVotedHeight`.
- Polls blocks one-by-one in a monotonically increasing order.

Once a finality provider is restarted, it needs to determine which height to
start from, or bootstrapping. The bootstrapping needs to ensure that no blocks
will be missed and voted blocks will not be polled again. The bootstrapping
process is as follows:

1. Query consumer chain for:
   - `lastFinalizedHeight` (defaults to `0` if no blocks are finalized): the
   latest finalized height,
   - `finalityActivationHeight`: the height after which the finality is
   activated, defined as the finality parameters,
   - `highestVotedHeight` (defaults to `0` if no votes exist): the highest
   height for which the given finality provider has ever voted.

2. If local state is empty or broken:
   - Set `lastVotedHeight = lastFinalizedHeight`

3. Compare `lastVotedHeight` and `highestVotedHeight`:
   - If `lastVotedHeight >= highestVotedHeight`
     - `startHeight = lastVotedHeight + 1`
     - Note: this is possible if `highestVotedHeight` has not been updated due to
     execution delay.
   - If `lastVotedHeight < highestVotedHeight`
     - `startHeight = highestVotedHeight + 1`
     - Note: this is possible due to bugs or if the local state is tampered with

4. Start from `max(startHeight, finalityActivationHeight)`

Note that the mechanism shown above is not comprehensive in the sense that
it is still possible that the assumptions listed at the beginning
of the section do not hold, and the assurance might be broken.
One common example is that, during software upgrade,
the Babylon Genesis node might not be responsive. In this case, if the `fpd` is
restarted, it might send duplicate signing requests as the previous ones were
not processed.

Therefore, we also need the protection from the EOTS manager daemon, described
in the next section.

#### EOTS manager daemon protection

**Requirement**:

- The `eots.db` file is not compromised.

The EOTS manager daemon ensures that EOTS signatures will not be signed
twice for the same height. To achieve this, the daemon keeps track of all the
signing histories in the EOTS manager. The signing record is defined below:

```go
type SigningRecord struct {
    Height      uint64
    BlockHash   []byte
    PublicKey   []byte
    Signature   []byte
    Timestamp   time.Time
}
```

For each EOTS signing request, the following checks are performed:

- Check if the height is already signed in the local storage.
  - If yes, check if the signing message in the request matches the previously
  signed message.
    - If yes, return the previous vote.
    - If no, return error with double-signing warning.
  - If no, sign the EOTS signature, save it in the local storage by height,
  and return the vote.

The local storage of the EOTS manager should be backed up periodically, and
corruption checks should be performed before the signing service starts.
Pruning of old records can be done with configurable retention policies.

#### Operation Recommendations

Detailed specifications on the secure operation of the finality provider
program stack can be found in the Finality Provider Operation document.
Here, we list security tips specifically for preventing double-sign:

- Operate your own Babylon Genesis RPC node and securely connect with it
to ensure a trustless setup
- The keyring files or the mnemonic phrases should be backed up and kept safe
- Operate `fpd` and `eotsd` in separate machines connected in a secure
network (config `EOTSManagerAddress` in `fpd.conf`)
- Set up HMAC for authentication between the two daemons.
Details in [HMAC Security](https://docs.babylonlabs.io/operators/finality_providers/hmac_security/)
- Backup the db files for both daemons periodically
(one-hour interval is recommended)

### HMAC Security for Finality Providers
Source: https://docs.babylonlabs.io/operators/finality_providers/hmac_security/

> Note: This content is fetched from GitHub at build time.
> Remote source: https://raw.githubusercontent.com/babylonlabs-io/finality-provider/refs/heads/main/docs/hmac-security.md

This document describes the HMAC (Hash-based Message Authentication Code) authentication system used to secure the
communication between the Finality Provider Daemon (FPD) and the Extractable One-Time Signature Daemon (EOTSD).
HMAC ensures that only authorized requests from FPD are processed by EOTSD, which handles sensitive key operations.

#### Overview

The Finality Provider (FPD) and EOTS Manager (EOTSD) are separate components. EOTSD manages EOTS keys,
generates randomness, and signs EOTS signatures and schnorr signatures, making it a critical security target.
HMAC authentication adds a layer of protection, preventing unauthorized access to these signing capabilities.

#### Security Classification of EOTSD Messages

The following gRPC methods exposed by EOTSD *require* HMAC authentication:

- **`SignEOTS`**
- **`SignSchnorrSig`**
- **`CreateRandomnessPairList`**

The following gRPC method does *not* require HMAC authentication:

- **`Ping`**: Used for health checks and basic connectivity testing.

**Key Management Note:** Key *creation* (e.g., using the `eotsd keys add` command) is handled locally by `eotsd`
and does *not* use gRPC. Therefore, key creation does *not* use or require HMAC authentication.

#### Configuring HMAC Authentication

HMAC authentication is strongly recommended for production deployments. It relies on a shared secret key
(the HMAC key) known to both FPD and EOTSD.

**Generating a Strong HMAC Key**

Generate a cryptographically secure random key (32 bytes is recommended) and encode it using base64.
You can use the `openssl` command:

```bash
# Generate a 32-byte random key and encode it as base64
openssl rand -base64 32
```

Example output: Wt+Nxkn1DpNCFJtxQSxTKoSoKzx1C9XwHTMbT6ir9m0= (Your key will be different).

#### Configuration Methods

**1. FPD Configuration (fpd.conf)**

Set the hmackey option within your fpd.conf file:

```
[metrics]
# ... other settings ...

hmackey=Wt+Nxkn1DpNCFJtxQSxTKoSoKzx1C9XwHTMbT6ir9m0=  # Your base64 encoded key
```

**2. EOTSD Configuration (eotsd.conf)**

Set the hmackey option within your eotsd.conf file:

```
hmackey=Wt+Nxkn1DpNCFJtxQSxTKoSoKzx1C9XwHTMbT6ir9m0=  # MUST match the FPD key, base64 encoded
```

**Important Considerations:**

- Consistency: The HMAC key must be identical for both FPD and EOTSD.
- Security: Never commit the HMAC key to version control. Store it securely, treating it like a private key.
- If No Key is Provided: If no key is set in the configuration, the services will still start, but with gRPC authentication turned off. This is not recommended for production environments.

#### Deployment Best Practices

Separate Machines: For maximum security, run FPD and EOTSD on separate machines. Restrict network access to the EOTSD
machine, allowing connections only from the FPD instance.

Key Rotation: Rotate the HMAC key periodically (e.g., every few months). Generate a new key, update the configuration
files, and restart both services. This requires a brief downtime.

#### Troubleshooting

If you encounter HMAC authentication errors:

1. Key Mismatch: The most common cause is a difference between the HMAC keys configured for FPD and EOTSD.
Double-check that they are identical, including any leading or trailing whitespace.

2. Configuration Issues: Ensure that the HMAC key is properly set in both configuration files.

3. Cloud Secret References: If you're using cloud secret references (AWS, GCP, Azure), ensure they are properly formatted and accessible.

### General FAQs
Source: https://docs.babylonlabs.io/guides/support/faqs/

#### Questions about Babylon's Native Bitcoin Staking

**Will my Bitcoins be bridged or pegged to other blockchains?**

**No**.
Babylon allows Bitcoin holders to stake their
bitcoins without bridging them to other blockchains,
while providing the chain with full slashable security guarantees.

**As a bitcoin staker, do I have to run a validator by myself?**

**No**. Like most PoS systems,
with the Bitcoin staking protocol,
you can delegate your voting power to a validator that you trust.
The validator will usually charge a commission on your staking reward.
If the delegated validator acts maliciously, your stake will also be slashed.
Running a validator by yourself will avoid this trust and commission,
putting both the stake and reward fully under your control.

**When slashing happens, will all my staked bitcoins be burned?**

**Not necessarily**.
Our protocol supports partial slashing.
This means that, when slashing happens,
only a certain portion of the staked bitcoins will be slashed,
with the portion being a parameter of the protocol.

**How many Bitcoin block confirmations are required for my stake to become active?**

**30 BTC block confirmations** are required for your stake to become active,
assuming that the Finality Provider you delegated to is already active and has timestamped randomness.

**What is the minimum staking period?**

The staking period is fixed at **64,000 BTC blocks**, which is roughly **15 months**.
This is currently the only possible staking period on mainnet.

**Is partial unbonding possible for BTC staking?**

**No**, partial unbonding is not supported for BTC staking.
Every BTC stake must be unbonded fully - you cannot unbond just a portion of your staked amount.

**Are there any minimum amount or frequency restrictions for claiming rewards?**

**No**, there are no minimum amount or frequency restrictions for claiming rewards.
You can claim your rewards at any time without any limitations.

Send a [GitHub issue](https://github.com/babylonlabs-io/babylonlabs.github.io/issues) if you would like more questions included in this FAQ.