# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.b14g.xyz/architecture/self-custodial-bitcoin-staking.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.