> For the complete documentation index, see [llms.txt](https://docs.b14g.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.b14g.xyz/architecture/self-custodial-bitcoin-staking.md).

# Self-Custodial Bitcoin Staking

## **Overview**

**Self-Custodial BTC Staking** is the foundation of b14g’s BTCFi architecture. It allows Bitcoin holders to **stake their BTC directly from their own wallets** to secure Bitcoin-aligned chains — without wrapping, bridging, or giving up custody.

This mechanism combines Bitcoin’s **native timelock script** with staking proofs verification on connected networks, creating the first truly **trustless, yield-generating** staking model for BTC.

**Key Feature:**

* Your BTC never leaves Bitcoin.
* The yield you earn comes from providing real economic security to Bitcoin-aligned networks.

***

## **How It Works**

### **1. Timelock Mechanism**

A **Bitcoin Timelock** is a feature that allows you to lock your Bitcoin based on time-based conditions. Think of it like a digital “safe”, you can put your BTC inside and set a rule that says *“only open at 3PM today”* or *“open in 5 hours”*

Timelocks are an important part of how **self-custodial Bitcoin staking** or **cross-chain security mechanisms** work. They make sure that your BTC stays locked and provable on the Bitcoin network during a staking or bonding period, and automatically becomes spendable again when that period ends.

#### Types of Timelocks: CLTV vs CSV

Bitcoin supports two main types of timelock scripts: **CLTV** (CheckLockTimeVerify) and **CSV** (CheckSequenceVerify). They both restrict when BTC can be spent, but they work in slightly different ways.

<figure><img src="/files/3s8CgrKhyjaHZO9forzi" alt=""><figcaption></figcaption></figure>

| Feature                                                   | CLTV (CheckLockTimeVerify)                                                                                                                                                                                                                                                          | CSV (CheckSequenceVerify)                                                                                                                                                                                                                                                                                                                           |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **How Time is Measured**                                  | <p>Absolute. Targets a fixed point in the future.<br><br>Example: <em>"The door opens at 9:00 AM on July 4th"</em></p>                                                                                                                                                              | <p>Relative. Measures time based on how long after a previous event.<br><br>Example: "<em>The secondary door opens 48 hours after the primary door successfully opened</em>"</p>                                                                                                                                                                    |
| **Enforcement**                                           | Prevents the transaction from being confirmed **until that exact time or block height has passed.**                                                                                                                                                                                 | Prevents the transaction from being confirmed until a specific **duration has passed since the previous one was confirmed.**                                                                                                                                                                                                                        |
| **Example Use Case**                                      | <p>Lock BTC with a rule: “<em>This BTC can only be spent after block 900,000.</em>”<br><br>Before that block, any attempt to move it will be rejected.</p>                                                                                                                          | <p>Lock BTC with a rule: “<em>This BTC can only be spent after 1,008 blocks (\~7 days) once the unbonding transaction is confirmed.”</em><br></p><p>The countdown begins once the unbonding is confirmed.</p>                                                                                                                                       |
| <mark style="color:blue;">**Functional Advantage**</mark> | <mark style="color:blue;">Best for</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**fixed deadlines,**</mark> <mark style="color:blue;"></mark><mark style="color:blue;">useful when you want a transaction to occur only after a specific block or time.</mark> | <mark style="color:blue;">Best for</mark> <mark style="color:blue;"></mark><mark style="color:blue;">**stringing together chains of transactions**</mark><mark style="color:blue;">, setting relative locks on unconfirmed or unbroadcast transactions, and ensuring they confirm in the expected order regardless of when they’re executed.</mark> |
| **Simple Analogy**                                        | An absolute lock is like scheduling one email to send at 9:00 AM on July 4th.                                                                                                                                                                                                       | A relative lock is like setting up an entire chain of emails where Email 2 sends 48 hours after Email 1 is opened, no matter when Email 1 was originally created.                                                                                                                                                                                   |

### **2. Staking Process Overview**

{% stepper %}
{% step %}
**User initiates lock**

A BTC holder creates a timelock transaction to lock BTC for a defined duration. During this time, the BTC is completely unspendable.

When creating the timelock transaction, metadata is embedded to:

* Indicates which validator/finalty provider you want to support
* Specifies a PoS chain-compatible address (e.g., EVM, CosmWasm, etc.) to receive rewards.

*Note on Integrations: Depending on the POS chain's design and types of timelocks, some integrations may require the user to construct additional transactions to define more complex logic, such as:*

* *Slashing conditions*
* *Early unbonding rules*
  {% endstep %}

{% step %}
**Proof Registration**

Once your lock is confirmed on Bitcoin, a proof of lock is submitted to the PoS chain’s staking contract by a relayer or verifier. This registers the user’s BTC stake on the target chain.
{% endstep %}

{% step %}
**Reward Accrual**

Once registered, the user begins earning yield according to the network’s reward mechanism. Rewards are distributed to the address provided at the beginning of lock inititation.
{% endstep %}

{% step %}
**Unlock**

When the timelock expires, the BTC becomes spendable again on Bitcoin mainnet. To continue staking, a new timelock must be created.\
Note: *Some integrations allow early unbonding depending on the PoS chain’s specific design.*
{% endstep %}
{% endstepper %}

***

## **Integration**

Self-custodial BTC staking serves as a shared primitive across multiple networks. Each chain implements its own integration logic based on its consensus design and staking framework.

<table><thead><tr><th width="112"></th><th>Core Chain Integration</th><th>Babylon Integration</th></tr></thead><tbody><tr><td>Timelock Mechanism</td><td>CLTV Timelock</td><td>CSV Timelock</td></tr><tr><td>BTC Role</td><td>Strengthens Core chain’s Satoshi-Plus consensus by anchoring validator security to Bitcoin.</td><td>Provides economic security for Babylon’s finality providers that timestamp and finalize other blockchains.</td></tr><tr><td>Proof Registra-tion</td><td>Verified through Core’s BTC staking Relayers</td><td>Verified through Babylon’s Vigilante BTC Staking Trackers</td></tr><tr><td>Reward Token</td><td><strong>CORE</strong></td><td><strong>BABY</strong></td></tr><tr><td>Slashing</td><td>Not applicable. No slashing risk for BTC stakers.</td><td>Yes, capped at <strong>0.1%</strong> of the staked amount to deter malicious behavior.</td></tr><tr><td>Liquidity</td><td>BTC is <strong>locked</strong> until the timelock expires and only becomes spendable afterward.</td><td>Users can <strong>unbond early</strong> before the timelock ends, but must wait for a 1008-block delay (~7 days) before their BTC becomes spendable again.</td></tr><tr><td>Reward Multiplier</td><td>Boosted rewards apply when users <strong>dual-stake BTC and CORE</strong>.<br><br>If you only have BTC, you can match with CORE stakers on <a href="/pages/Ek3yiwB0cixkhyUpfYgi">b14g’s Merge Marketplace</a> and share boosted rewards. </td><td>Boosted rewards apply when users <strong>co-stake BTC and BABY</strong>.<br><br>If you only have BTC, you can match with BABY stakers on <a href="/pages/M85FKJOCNgCDdM91nMLT">b14g’s Merge Marketplace</a> and share boosted rewards.</td></tr></tbody></table>

b14g standardizes this process through a unified interface, letting BTC holders stake once and participate across multiple Bitcoin-aligned chains.

{% content-ref url="/pages/ebRI8nxHXRaO24b9TjXP" %}
[Self-custodial BTC Staking (Core chain)](/products/for-btc-holders/self-custodial-btc-staking-core-chain.md)
{% endcontent-ref %}

{% content-ref url="/pages/mAcVX1VM3RPRCh6uJhk5" %}
[Self-custodial BTC Staking (Babylon)](/products/for-btc-holders/self-custodial-btc-staking-babylon.md)
{% endcontent-ref %}

***

## **Benefits**

| Benefit                     | Description                                                               |
| --------------------------- | ------------------------------------------------------------------------- |
| **True Self-Custody**       | Your BTC never leaves your wallet or the Bitcoin chain.                   |
| **Earn Real Yield**         | Rewards come from real network security, not unsustainable yield farming. |
| **Cross-Chain Flexibility** | Same BTC lock can be used across different BTCFi networks.                |
| **Transparent & Auditable** | All staking proofs and rewards visible on-chain.                          |

Self-Custodial BTC Staking is the core primitive of the **b14g BTCFi architecture**.

It connects Bitcoin’s native security with emerging L1 and L2 ecosystems — enabling BTC holders to earn yield while maintaining full control of their assets.
