BTC Restaking (Babylon)
The x/babylon module is designed to integrate QoreChain with the Babylon Protocol to inherit Bitcoin's proof-of-work finality guarantees. Through BTC restaking, QoreChain would gain a secondary finality layer backed by Bitcoin's hashrate — without requiring any changes to the Bitcoin protocol itself.
The Babylon integration is specified, but its transactions are not enabled on the live networks: the module is disabled in the genesis configuration (enabled = false), has no transaction service, query service, CLI or REST routes, and no IBC channel to Babylon is open on either network. This is unchanged on mainnet (v3.2.4) and testnet (v3.2.6) (checked 23 October 2026 on both, and again on 27 October 2026 for the testnet's IBC state: the node answers no babylon query, the only IBC channel on either network is the testnet's single test channel to a chain with ID provider, and the qor_getBTCStakingPosition method is not served). Everything below describes the intended design; the message names, REST paths and CLI commands are not available today.
Overview
Babylon Protocol enables proof-of-stake chains to leverage Bitcoin's security through a timestamping and checkpointing mechanism. QoreChain's integration works as follows:
- BTC stakers lock Bitcoin in Babylon staking transactions and register their positions on QoreChain.
- Epoch checkpoints from QoreChain are periodically relayed to Babylon, which timestamps them on Bitcoin.
- Finality inheritance: Once a QoreChain epoch is checkpointed on Bitcoin, the state covered by that epoch inherits Bitcoin's proof-of-work finality guarantees.
This provides a defense against long-range attacks and equivocation that is anchored to Bitcoin's accumulated hashrate rather than relying solely on QoreChain's own validator set.
BTC Staking Positions
Users would register BTC staking positions on QoreChain by submitting a MsgBTCRestake transaction that references a Bitcoin staking transaction.
Registration Requirements
| Parameter | Value | Description |
|---|---|---|
| Minimum stake | 100,000 satoshis (0.001 BTC) | Minimum BTC required per staking position |
| Unbonding period | 144 BTC blocks (~1 day) | Waiting period before staked BTC can be withdrawn |
| Checkpoint interval | Every 10 QoreChain epochs | How often state is checkpointed to Babylon |
Staking Position Structure
Each BTC staking position tracks the following on-chain state:
| Field | Description |
|---|---|
staker_address | QoreChain address of the staker (qor1...) |
btc_tx_hash | Bitcoin transaction hash of the staking transaction |
amount_satoshis | Amount of BTC staked in satoshis |
status | Position lifecycle state: active, unbonding, or withdrawn |
staked_at | Timestamp of position registration |
unbonding_height | Block height at which unbonding was initiated (if applicable) |
validator_addr | QoreChain validator address this stake is delegated to |
Registration Flow
- Create BTC staking transaction — On the Bitcoin network, create the BTC staking transaction.
- Submit MsgBTCRestake on QoreChain — On QoreChain, submit
MsgBTCRestakewithbtc_tx_hash,amount, andvalidator. - Position recorded — The position is recorded on-chain as "active".
Epoch Checkpoints
QoreChain's epoch state roots are periodically checkpointed to Bitcoin through the Babylon relay chain.
Checkpoint Flow
- Submit checkpoint — A QoreChain validator submits
MsgSubmitBTCCheckpointcontaining the epoch number, BTC block hash, BTC block height, and QoreChain state root. - IBC relay — The checkpoint data is relayed to the Babylon chain via IBC.
- Timestamping on Bitcoin — Babylon includes the checkpoint in a Bitcoin transaction, anchoring QoreChain's state to Bitcoin's blockchain.
- Confirmation — Once the Bitcoin transaction is confirmed, finality flows back through Babylon to QoreChain.
- Finalization — The checkpoint status transitions from
pendingtoconfirmedtofinalized.
Checkpoint Structure
| Field | Description |
|---|---|
epoch_num | QoreChain epoch number being checkpointed |
btc_block_hash | Bitcoin block hash containing the checkpoint |
btc_block_height | Bitcoin block height |
state_root | QoreChain state root at the epoch boundary |
submitted_at | Timestamp of checkpoint submission |
status | Checkpoint state: pending, confirmed, or finalized |
Epoch Snapshots
At each checkpoint boundary, an epoch snapshot captures aggregate network state:
| Field | Description |
|---|---|
total_staked | Total BTC staked across all positions (satoshis) |
active_positions | Number of active staking positions |
validator_count | Number of validators with BTC-backed delegations |
block_height | QoreChain block height at snapshot |
Secondary Finality Layer
The Babylon integration provides a secondary finality guarantee that complements QoreChain's native consensus finality:
| Finality Layer | Source | Speed | Security |
|---|---|---|---|
| Primary | QoreChain Consensus Engine | ~3 seconds | Backed by QOR stake + PQC signatures |
| Secondary | Babylon + Bitcoin | ~60 minutes | Backed by Bitcoin's cumulative hashrate |
The secondary layer is particularly valuable for:
- Long-range attack prevention: Even if an attacker accumulates significant QOR stake, they cannot rewrite history that has been checkpointed on Bitcoin.
- Cross-chain bridge security: Bridge operations involving large values can wait for Bitcoin-level finality before releasing funds.
- Institutional confidence: The Bitcoin timestamp provides an independently verifiable proof of QoreChain's state history.
Configuration
| Parameter | Default | Description |
|---|---|---|
enabled | false | Master switch for BTC restaking features |
min_stake_amount | 100,000 satoshis | Minimum BTC per staking position |
unbonding_period | 144 BTC blocks | BTC-denominated unbonding duration |
checkpoint_interval | 10 epochs | Epochs between Babylon checkpoints |
babylon_chain_id | bbn-1 | Chain ID of the connected Babylon network |
Events
The module emits the following on-chain events:
| Event Type | Attributes | Description |
|---|---|---|
btc_restake | staker, btc_tx_hash, amount, validator | New BTC staking position registered |
btc_unbond | staker, amount | BTC staking position entered unbonding |
btc_checkpoint | epoch, checkpoint_id | Epoch checkpoint submitted to Babylon |
babylon_epoch_complete | epoch | Babylon epoch finalized with Bitcoin timestamp |
API Endpoints (planned)
None of the endpoints or commands in this section is served or available on the live networks today.
REST
| Method | Endpoint | Description |
|---|---|---|
| GET | /babylon/v1/staking/{address} | Get BTC staking positions for an address |
| GET | /babylon/v1/checkpoint/{epoch} | Get checkpoint data for a specific epoch |
| GET | /babylon/v1/params | Get module configuration parameters |
JSON-RPC
Not served yet: no released node build serves the
qor_JSON-RPC namespace, so this call returns-32601(method not found) on every public endpoint today. See theqor_namespace.
| Method | Parameters | Description |
|---|---|---|
qor_getBTCStakingPosition | address (string) | Returns the BTC staking position for the given QoreChain address |
CLI Commands (planned)
Query Commands
# Query BTC restaking configuration
qorechaind query babylon config
# Query a staking position by address
qorechaind query babylon position <staker-address>
Transaction Commands
# Register a BTC restaking position
qorechaind tx babylon restake \
--btc-tx-hash <hash> \
--amount-satoshis <amount> \
--validator <qorvaloper1...> \
--from <key-name>
# Submit a BTC checkpoint
qorechaind tx babylon submit-checkpoint \
--epoch <epoch-number> \
--btc-block-hash <hash> \
--btc-block-height <height> \
--state-root <root> \
--from <key-name>