[BTCFi Series 2] The Wave Driving BTCFi: L2s and Babylon Native Staking

Introduction

In recent years, the Bitcoin ecosystem has undergone explosive change. Meta‑protocols like Ordinals and BRC‑20 transformed Bitcoin from “digital gold” into a richer “data layer.” By inscribing arbitrary data such as images and text, we could issue assets and form communities on BTC L1, but the capabilities still fell short compared to other DeFi ecosystems.

These meta‑protocols used the Bitcoin blockchain effectively as a data store, but they could not process complex state management and verification logic purely on‑chain. Balances and transfers for BRC‑20 ultimately live in off‑chain indexers that interpret transactions under their chosen rules. This assumes that indexers share the exact same rules and versions; when that assumption is broken, consistency collapses. The “data innovation” succeeded, but we did not reach smart‑contract‑level guarantees. We need a new execution layer that provides security, finality, and automated verification — not just data anchoring on Bitcoin.

Approaches to BTC L2

As the need for L2s became clear, three broad approaches emerged.

1. Pegged Sidechains: Liquid wraps BTC and moves it to a separate sidechain to gain speed and scalability. However, asset movement and security are managed by a small federation of operators. Even with multisig, this compromises Bitcoin’s core values of decentralization and censorship resistance. The UX and speed, however, are strong.

2. Bitcoin Rollups: Projects like Citrea attempt on‑chain fraud/validity proofs over Bitcoin’s non‑Turing‑complete Script using BitVM. Many BTC L2s anchor validity to Bitcoin by combining ZK rollups with BitVM‑based verification. Still, to bring liquidity into DeFi, these systems generally rely on wrapped BTC (e.g., cBTC), which carries its own trust and bridging constraints.

3. Babylon’s Native Staking: Babylon takes a very different route. Without wrapping or bridging BTC off L1, it uses on‑chain Script plus cryptography to secure external PoS networks via “native staking.” This turns BTC from a passive store of value into productive collateral. Given BTC maximalists’ aversion to custody risk, this is a compelling approach.

Notably, these are not mutually exclusive. They can be synergistic. For example, BOB (Build on Bitcoin), a BitVM‑oriented L2, leverages BitVM’s strength for on‑chain validity while partnering with Babylon to connect L2 transaction finality back to Bitcoin L1. If BitVM strengthens security around wrapped BTC validity, Babylon can underwrite L2 block finality with Bitcoin’s massive security budget. This suggests Babylon is evolving beyond “native staking” into a shared security layer for execution layers on Bitcoin — akin to modular blockchain trends in Ethereum — acting as a gravitational hub for BTCFi.

How Babylon’s Native Staking Works

Babylon’s “native staking” cleverly combines Bitcoin L1 Script with modern cryptography. The core requirement, both for security and for holders, is that each wallet’s BTC does not move off L1; let’s unpack the mechanism.

2.1. Three‑Path Taproot UTXO Design: Babylon staking defines three conditional spending paths inside a Taproot UTXO on Bitcoin L1, allowing BTC to remain in the owner’s wallet on L1 while being staked.

• Timelock Path: After a set number of blocks, the staker can withdraw freely.
• Unbonding Path: Early unbonding before expiry requires, in addition to the staker’s signature, signatures from a covenant‑emulation committee, enforcing protocol‑defined unbonding rules.
• Slashing Path: If a Finality Provider (FP) equivocates (e.g., double signs), a preset portion of BTC is moved to a burn address. This path is enabled via pre‑signatures from the staker, the FP, and the committee.

2.2. EOTS‑Based Slashing: Babylon’s slashing uses Extractable One‑Time Signatures (EOTS) and adaptor signatures. If an FP signs two conflicting messages at the same height, properties of EOTS reveal the FP’s private key, which finalizes a pre‑built slashing transaction that atomically moves a fixed fraction of BTC to a burn address.

This sidesteps some verification limits of Bitcoin L1, but has trade‑offs: only equivocation is slashable. Non‑malicious faults such as downtime or missed votes are not penalized, concentrating operational risk on FPs and making professional key‑management solutions (e.g., Cubist) important.

2.3. Covenant Emulation Committee: Bitcoin Script cannot directly enforce covenants. Babylon augments enforcement with an M‑of‑N multisig committee that pre‑signs transactions to emulate covenant‑like rules for early unbonding and slashing.

This is a pragmatic workaround to Script limits but raises transparency concerns. Without committee co‑signatures, early unbonding is impossible. While the committee cannot seize funds without the staker, collusion to withhold signatures could threaten liveness. Today, committee identities are not publicly disclosed, underscoring the explicit trade‑off: adopting some centralized trust to enable richer functionality while aiming for progressive decentralization.

2.4. Finality via Checkpointing: Babylon’s genesis chain (Cosmos SDK + CometBFT) aggregates validator signatures using BLS and periodically anchors a single aggregated checkpoint signature into Bitcoin L1 via OP_RETURN.

This taps Bitcoin’s security to bolster Babylon’s finality while minimizing on‑chain data. It also explains why BitVM‑based L2s like BOB use Babylon as a finality layer.

Table 2: Key Components of Babylon Native Staking

Economics and Ecosystem Strategy

Babylon aims to be more than a protocol: a hub for mobilizing BTC liquidity in many forms.

3.1. Who Stakes BTC, and Why?

Traditional BTC holders prioritize preserving coin count and shun risk. Babylon enables staking while coins remain in the holder’s L1 wallet, nudging some holders to participate. To broaden access, Babylon supports several channels:

• Individual Investors: Centralized exchanges such as Kraken provide easy access. Without wrapping or bridging, users can stake as simply as a typical PoS asset. Rewards are paid in BABY (and, over time, BSN rewards).
• Institutions: Custodians such as Anchorage and Hex Trust provide regulated, secure channels aligned with institutional needs for compliance and long‑term BTC strategies.

3.2. BSN — Bitcoin Supercharged Network: Babylon’s core business lets PoS chains “buy” Bitcoin’s security. These chains, collectively the BSN, reward Babylon stakers with their native tokens. BSN chains solve cold‑start problems, shorten unbonding, and dramatically raise attack costs.

Examples highlight the potential:

• Osmosis: As a condition for becoming BSN, proposes distributing 50% of taker fees from Babylon‑ecosystem assets to Finality Providers (FPs). This is a concrete model for “purchasing PoS security” and a likely revenue lane for Babylon.
• Sui: Shows Babylon’s modularity by integrating with Sui’s DAG‑based consensus — the protocol is not tied to any one stack.
• BOB (Build on Bitcoin): A BitVM rollup using Babylon for finality. BOB expands liquidity via Babylon‑backed LSTs and anchors stability in Babylon’s security.

3.3. Activating LSTs: Capital Efficiency: Staked BTC is illiquid during lockup. Lombard issues an LST, LBTC, backed 1:1 by Babylon‑staked BTC with rewards accruing. Users can then deploy LBTC across DeFi — collateral, lending, LPing — maximizing capital efficiency.

Table 3: Comparison by Partner/Channel

Challenges Ahead for Babylon

Babylon is clearly innovative, but several challenges remain.

4.1. Technical/Operational Risk: EOTS‑based slashing imposes strong penalties for double signing, meaning FPs face immediate slashing due to key mishandling or software bugs. Operational robustness directly ties to asset safety, making professional key management (e.g., Cubist) essential.

4.2. UX/Transparency: Unbonding Confusion: A key advantage is “fast unbonding.” Official docs cite 301 blocks (~50 hours), while partners like Kraken and Hex Trust indicate ~7 days or 1,008 blocks. Beyond documentation timing, CEXs may add internal delays for liquidity or security. Unbonding parameters are protocol‑level and can change via BABY governance, creating unpredictability that harms UX and highlights tension between technical transparency, commercial partnerships, and governance policy.

4.3. Full‑Stack Vision: Beyond staking, Babylon aims to support EVM and host BTC‑native DeFi apps — a “full‑stack BTCFi hub.” This puts Babylon in more direct competition with Ethereum L2s and demands attracting significant liquidity and developers.

Conclusion

Babylon has awakened BTC’s liquidity and productivity — “capital that moves security/rewards without moving coins (no bridge).” This paradigm turns BTC into productive capital.

By keeping BTC on L1 and combining EOTS slashing, native Script, and a pragmatic external committee, Babylon opens a door to “Bitcoin DeFi” previously thought impossible — likely a major catalyst for the ecosystem.

But key gaps remain:

• Technical Transparency: Publish a decentralization roadmap and identities for the covenant committee to progressively reduce centralized trust assumptions.
• Operational Resilience: Broaden secure key‑management options for institutional and individual FPs to reduce operational risk.
• Predictable UX: Clarify unbonding parameters and reward policies to reduce confusion.

Babylon is becoming a core of BTCFi. For its full vision to become reality, progress on decentralization, transparency, and user experience must accompany the technical breakthroughs.

[BTCFi Series 2] BTCFi를 이끄는 물결: L2, 그리고 Babylon Native Staking

서론

최근 몇 년간 비트코인 생태계는 폭발적인 변화를 겪었다. 오디널스(Ordinals)와 BRC-20 같은 메타프로토콜은 비트코인을 단순한 ‘디지털 금’에서 더 많은 것을 담을 수 있는 ‘데이터 레이어’로 탈바꿈 시켰다. 비트코인에 이미지나 텍스트 같은 임의의 데이터를 기록함으로써, BTC L1에서 자산과 커뮤니티를 이룰 수 있었지만, 다른 DeFi 생태계에 비해서는 많이 부족했다.

메타프로토콜은 비트코인 블록체인을 데이터 저장소로는 효과적으로 활용했지만, 복잡한 상태 관리(state management)와 검증 로직을 온체인에서 처리하지 못했다. BRC-20의 잔고나 거래 내역 같은 ‘상태’는 결국 오프체인에 존재하는 인덱서가 각자의 규칙에 따라 해석했다. 이는 인덱서들 간에 동일한 규칙과 버전을 사용한다는 암묵적인 신뢰를 가정했고, 이 신뢰가 깨질 경우 데이터의 일관성이 보장되지 않는다는 문제를 남겼다. ‘데이터의 혁신’까지는 성공했지만, 스마트 컨트랙트 수준에는 도달하지 못했다. 결국, 비트코인의 단순히 데이터를 앵커링하는 것을 넘어 보안과 최종성, 자동화된 검증을 제공하는 새로운 실행 레이어가 필요하다는 결론에 다다른다.

BTC L2를 위한 다양한 접근

L2의 필요성을 느낌에 따라 크게 세 가지 방법을 시도하고 있다.

1. 페그드(Pegged) 사이드체인: 리퀴드(Liquid)는 비트코인을 ‘래핑(wrapping)‘하여 별도의 사이드체인으로 옮긴 뒤 빠른 속도와 확장성을 확보한다. 하지만 이 모델은 자산의 이동과 보안을 소수의 운영자(Federation)가 관리한다. 다중 서명(multisig)을 사용한다고 하더라도, 비트코인의 핵심 가치인 탈중앙화와 검열 저항성에는 반한다. 다만, UX와 속도는 챙길 수 있었다.

2. 비트코인 롤업(Bitcoin Rollups): 시트리아(Citrea) 같은 프로젝트는 비트코인 L1의 튜링 불완전한 스크립트 위에서 BitVM을 통해 사기증명 같은 온체인 검증을 시도한다. ZK 롤업을 전면에 내세우면서 BitVM 기반 검증을 결합하여 유효성 증명을 비트코인에 앵커링하는 방법인데, 대부분의 BTC L2가 이 방식을 채택한다. 하지만 이 방식 역시 유동성을 확보하고 디파이에 활용하기 위해 cBTC와 같은 래핑된 토큰을 사용해야 한다는 한계가 존재한다.

3. 바빌론의 네이티브 스테이킹: 바빌론은 이들과는 완전히 다른 방식을 내세웠다. 비트코인을 L1에서 래핑하거나 브릿징하지 않고, 온체인 스크립트만으로 다른 PoS 네트워크의 보안을 강화하는 ‘네이티브 스테이킹’을 구현했다. 비트코인을 ‘저장 수단’에서 ‘생산적 담보’로 전환하는 새로운 패러다임인 셈이다. BTC 맥시들이 가장 두려워 하는 것이 Custody 이슈임을 감안할 때, 이는 혁신적인 접근이다.

흥미로운 점은, 이들이 서로 경쟁하는 관계가 아니라는 것입니다. 오히려 각자의 기술적 강점을 보완하며 시너지를 내는 중요한 흐름이 포착됩니다. 예를 들어, BitVM 기반의 L2 롤업인 BOB(Build on Bitcoin)는 자산의 **유효성(Validity)**을 온체인에서 검증하는 BitVM의 강점을 활용하면서도, 바빌론과의 파트너십을 통해 L2 트랜잭션의 **최종성(Finality)**을 비트코인 L1에 연결합니다. BitVM이 래핑된 BTC의 보안을 강화한다면, 바빌론은 L2의 블록 최종성을 비트코인의 막대한 보안 예산으로 보증하는 역할을 수행하는 것입니다. 이는 바빌론이 단순히 ‘네이티브 스테이킹 프로토콜’을 넘어, 비트코인 위에 구축되는 다양한 **실행 레이어(Execution Layer)**를 위한 **공유 보안 레이어(Shared Security Layer)**로 진화하고 있음을 보여줍니다. 이더리움 생태계에서 ‘모듈러 블록체인’이 등장했듯, 바빌론은 비트코인 생태계의 모듈러화를 앞당기는 중력 중심이 되고 있습니다.

표 1: BTC 스케일링 솔루션 스펙트럼 비교

Deep dive into Babylon

바빌론의 ‘네이티브 스테이킹’이라는 혁신은 비트코인 L1의 스크립트 기능과 암호학적 기법을 기발하게 조합했다. 보안적으로도, 그리고 홀더 관점에서도 가장 중요한 문제는 각 지갑의 비트코인을 움직이지 않는 것인데, 그 기술을 자세히 알아볼 필요가 있다.

2.1. BTC UTXO 3-경로 구조와 탭루트(Taproot)의 역할 바빌론의 스테이킹은 비트코인 L1의 탭루트(Taproot) UTXO에 세 가지의 조건부 인출 경로(Spending Path)를 정의한다. 이 방식으로 BTC는 L1에, 지갑에 그대로 남은 채 스테이킹될 수 있다.

• Timelock Path: 일정 기간(블록 수)이 지나면 스테이커가 BTC를 자유롭게 인출할 수 있는 가장 기본적인 경로.

• Unbonding Path: 만료 전에 BTC를 조기 언본딩하고자 할 때 사용하는 경로, 스테이커의 서명 외에 커버넌트 에뮬레이션 위원회의 서명을 필요로 한다. 프로토콜이 정한 언본딩 절차를 강제할 수 있게 한다.

• Slashing Path: 파이널리티 프로바이더(FP)의 악의적인 행위(예: 이중 서명)가 감지될 경우, 정해진 비율의 BTC가 소각 주소로 이동하는 경로. 이 경로는 스테이커, FP, 그리고 위원회의 사전 서명을 통해 활성화된다.

2.2. EOTS 기반 슬래싱: 즉각적인 응징의 기술 바빌론의 슬래싱 메커니즘은 EOTS(Extractable One-Time Signatures)와 어댑터 서명(Adaptor Signatures)이라는 독특한 암호학적 기법에 기반한다. FP가 동일한 블록 높이에 두 개의 상충되는 메시지에 서명하는 이중 서명 행위(equivocation)를 저지르면, EOTS의 특성상 서명에 사용된 FP의 개인 키가 노출된다. 이 키를 이용해 미리 준비된 슬래싱 트랜잭션이 완성되고, 정해진 비율의 BTC가 소각 주소로 이동하는 원자적인(atomic) 절차가 진행된다.

이 기술은 온체인에서 직접적인 검증이 어려운 비트코인 L1의 한계를 깨는 방법이지만, 한계도 있다. 이중 서명에 대해서만 슬래싱을 가하며, 다운타임(downtime)이나 투표 누락과 같은 비악의적 오류에는 페널티를 부과하지 않기 때문인데, 이는 운영적 리스크를 FP에 집중시키며, Cubist 같은 전문 키 관리 솔루션을 필요로 하게 한다.

2.3. 커버넌트 에뮬레이션 위원회: 탈중앙화와 기능성 사이의 타협점 비트코인 L1은 튜링 불완전한 스크립트 언어의 한계로 인해, 트랜잭션이 특정 규칙을 준수하도록 강제하는 ‘커버넌트(Covenant)’ 기능을 직접 구현할 수 없다. 바빌론은 이 문제를 해결하기 위해 소수의 위원회(Committee)가 사전 서명을 제공하여 커버넌트 기능을 모방하는 M-of-N 멀티시그니처 방식을 사용한다. 위원회는 언본딩과 슬래싱 트랜잭션이 프로토콜의 규칙을 따르는지 확인하는 역할을 한다.

이러한 설계는 비트코인 스크립트의 한계를 해결하기 위한 현실적인 선택이지만, 동시에 중요한 투명성 문제를 야기한다. 위원회의 서명이 없으면 조기 언본딩이 불가능해기 때문이다. 물론, 위원회가 스테이커의 동의 없이는 자산을 탈취할 수 없지만, 위원회가 담합하여 서명을 거부하면, 시스템의 **생동성(Liveness)**이 위협받을 수 있다. 게다가, 현재 이 위원회 구성원의 신원은 공식적으로 공개되지 않았다. 이는 바빌론이 ‘탈중앙화’라는 비트코인의 핵심 가치를 지향하면서도, 복잡한 기능을 구현하기 위해 중앙화된 신뢰 가정을 도입했다는 명확한 트레이드오프를 보여준다.

2.4. 블록 확정성(Finality)의 비밀: 체크포인팅 바빌론 제네시스 체인(Cosmos SDK 기반)은 CometBFT를 사용하며, 바빌론 검증자들이 생성한 블록 서명을 BLS 서명 집계(Aggregation) 를 통해 단일 서명으로 만든다. 이 집계 서명은 비트코인 L1의 OP_RETURN 필드에 체크포인트(Checkpoint)로 기록된다.

이는 비트코인의 막대한 보안을 활용하여 바빌론 체인의 최종성을 확보하는 동시에, 온체인에 기록해야 하는 데이터(바이트)를 최소화하는 효율적인 방법이다. 앞서 언급한 BOB와 같은 BSN들이 바빌론을 최종성 레이어로 활용하는 이유도 여기에 있다.

표 2: 바빌론 네이티브 스테이킹 기술 상세

바빌론의 경제적·생태계 확장 전략

바빌론은 단순히 기술적 프로토콜을 넘어, 비트코인 유동성을 다양한 형태로 활용하는 거대한 생태계의 중심축을 목표로 한다.

3.1. BTC는 누가, 왜 스테이킹하는가?

통상적으로 BTC 홀더는 BTC 갯수를 지키는 것을 가장 우선시 한다. 리스크를 테이킹하지 않으려고 하고, 사서 모으기만 하는 자산으로 여긴다. 바빌론은 BTC를 지갑에 머물게 하면서 스테이킹할 수 있게 해주었고, 덕분에 일부 홀더를 움직일 수 있었다. 바빌론은 스테이킹 접근성을 높이기 위해 다양한 노력을 기울이고 있다.

• 개인 투자자: 크라켄(Kraken) 등 중앙화된 거래소(CEX)를 통해 쉽게 접근할 수 있다. BTC를 래핑하거나 브릿지하는 복잡한 과정 없이, 마치 일반적인 PoS 자산을 스테이킹하듯 간단하게 참여할 수 있다. 보상은 BABY 토큰(및 향후 BSN 보상)으로 지급된다.

• 기관 투자자: 앵커리지(Anchorage), 헥스 트러스트(Hex Trust)와 같은 전문 커스터디 사업자들은 기관 고객들을 위한 안전하고 규제 친화적인 채널을 제공한다. 보안, 컴플라이언스, 그리고 장기적인 BTC 홀딩 전략을 중시하는 기관의 니즈를 충족한다.

3.2. BSN(Bitcoin Supercharged Network)의 등장: 보안 예산의 외부화 바빌론 프로토콜의 핵심 비즈니스는 PoS 체인들이 비트코인의 막대한 보안을 ‘구매’할 수 있게 해주는 것이다. 이를 BSN(Bitcoin Supercharged Network)이라 칭하는데, BSN은 그 대가로 네이티브 토큰을 바빌론 스테이커에게 보상으로 지급한다. BSN은 ‘콜드 스타트’ 문제를 해결하고, 언본딩 시간을 단축하며, 공격 비용을 기하급수적으로 높이는 이점을 얻는다.

몇 가지 파트너십 사례를 보면 이 모델의 잠재력을 명확히 알 수 있다.

• 오스모시스(Osmosis): BSN이 되는 조건으로, 바빌론 생태계 자산에서 발생하는 테이커 수수료의 50%를 파이널리티 프로바이더(FP)에게 보상으로 분배하는 경제 모델을 제안했다. 이는 ‘PoS 보안 구매’의 구체적인 예시이며, 향후 바빌론이 BSN으로부터 프로토콜 수수료를 얻는 주요 경로가 될 것이다.

• 수이(Sui): 수이의 독특한 DAG 기반 컨센서스와 바빌론 프로토콜의 모듈성이 결합된 사례다. 이는 바빌론이 특정 기술 스택에 국한되지 않고 다양한 PoS 체인과 호환될 수 있음을 보여준다.

• BOB(Build on Bitcoin): BitVM 기반 롤업이 바빌론을 최종성 레이어로 활용하는 사례다. BOB는 Babylon-backed LSTs를 통해 생태계 유동성을 확장하고, 바빌론의 보안을 통해 그 안정성을 확보하는 전략을 취한다.

3.3. 유동성 스테이킹 토큰(LST)의 활성화 바빌론의 또 다른 중요한 축은 자본 효율성 극대화다. 스테이킹된 BTC는 락업 기간 동안 유동성이 묶인다는 단점이 있다. Lombard는 이 문제를 해결하기 위해 바빌론 스테이킹을 기반으로 LBTC라는 유동성 스테이킹 토큰(LST)을 발행한다. LBTC는 1:1 BTC 담보를 가지며, 스테이킹 보상이 누적되는 구조다. 이를 통해 사용자들은 락업된 BTC를 디파이(DeFi)에서 담보, 대출, 유동성 공급 등 다양한 용도로 활용할 수 있게 되어 자본 효율성을 극대화할 수 있다.

표 3: 바빌론 파트너/채널별 접근법 비교

바빌론이 마주한 문제들

바빌론은 분명 혁신이다. 하지만 아직 해결해야할 몇 가지 과제가 있다.

4.1. 기술적·운영적 리스크 바빌론은 EOTS 기반 슬래싱 메커니즘을 통해 이중 서명에 대한 강력한 페널티를 부과한다. 그러나 이는 파이널리티 프로바이더(FP)가 키 관리 및 소프트웨어 오류로 인한 이중 서명 시 즉각적인 슬래싱 위험을 안게 됨을 의미한다. 이는 운영의 안정성이 곧 자산의 안전과 직결된다는 것을 의미하며, Cubist와 같은 전문 키 관리 솔루션의 도입이 필수적이다.

4.2. UX/투명성 리스크: 혼란스러운 언본딩 파라미터 바빌론의 핵심 강점 중 하나는 ‘빠른 언본딩’이다. 공식 문서에 따르면 현재 언본딩 시간은 301 블록(평균 약 50시간)으로 안내되고 있지만, 크라켄(Kraken)이나 헥스 트러스트(Hex Trust) 같은 주요 파트너사의 안내는 약 7일 또는 1,008 블록을 명시하고 있다. 이는 단순히 문서 업데이트 시점의 차이일 수도 있지만, 그 이상의 의미를 담고 있다. CEX는 내부 유동성 관리나 보안을 위해 프로토콜의 최소 언본딩 시간 외에 자체적인 지연 시간을 추가했을 가능성이 높다. 또한, 언본딩 기간은 프로토콜의 파라미터이며 BABY 토큰 홀더들의 거버넌스 결정에 따라 언제든지 변경될 수 있다. 사용자 경험(UX) 측면에서 이러한 예측 불가능성은 혼란을 야기할 수 있으며, 이는 기술적 투명성이 상업적 파트너십과 거버넌스 정책의 복잡성과 충돌하는 지점이다.

4.3. 풀 스택(Full-Stack) 비전의 도전 과제 바빌론은 단순한 스테이킹 프로토콜을 넘어, EVM(Ethereum Virtual Machine)을 지원하고 , BTC 기반 디파이 앱을 직접 호스팅하는 ‘풀 스택 BTCFi 허브’를 목표로 한다. 이는 결국 바빌론이 이더리움 L2 생태계와 직접적으로 경쟁해야 함을 의미하며, 막대한 유동성과 개발자 생태계를 성공적으로 끌어와야 하는 도전 과제를 안게 됨을 의미한다.

결론

바빌론은 그 비트코인이라는 자본의 유동성과 생산력을 깨웠다. 움직이지 않고(브릿지 無) 움직이는 자본(보안·리워드)“이라는 새로운 패러다임은 비트코인을 생산적 자본으로 전환하는 핵심적인 기술이다.

바빌론은 BTC를 L1에 보존한 채 EOTS 기반 슬래싱과 네이티브 스크립트, 그리고 외부 위원회라는 현실적인 타협을 통해 이전에 불가능했던 ‘비트코인 디파이’의 문을 열었다. 이는 비트코인 생태계의 성장에 중요한 촉매제가 될 것이다.

하지만 몇 가지 문제가 남았다.

• 기술적 투명성: 커버넌트 위원회 구성원의 탈중앙화 로드맵과 신원 공개를 통해 중앙화된 신뢰 가정을 점진적으로 해소해야 한다.

• 운영의 안정성: 기관 및 개인 파이널리티 프로바이더를 위한 보안 및 키 관리 솔루션의 대중화를 통해 운영 리스크를 완화해야 한다.

• 예측 가능한 UX: 혼선을 초래하는 언본딩 파라미터와 보상 정책에 대한 명확한 안내로 사용자 경험을 개선해야 한다.

바빌론은 BTCFi의 중심이 되고 있다. 하지만 바빌론이 꿈꾸는 BTCFi와 그 비전이 현실이 되려면, 기술적 혁신을 넘어 탈중앙화, 투명성, 그리고 사용자 경험이라는 근본적인 숙제를 풀어내야 할 것이다.

[Serie BTCFi 2] La ola que impulsa BTCFi: L2 y el staking nativo de Babylon

Introducción

En los últimos años, el ecosistema de Bitcoin ha vivido un cambio explosivo. Metaprotocolos como Ordinals y BRC‑20 transformaron a Bitcoin de un simple “oro digital” en una “capa de datos” más expresiva. Al inscribir imágenes o textos, fue posible crear activos y comunidades en BTC L1; aun así, en comparación con otros ecosistemas DeFi, se quedaba corto.

Estos metaprotocolos aprovecharon la blockchain de Bitcoin como almacén de datos, pero no resolvieron en cadena la gestión de estados complejos ni la verificación. El “estado” de BRC‑20 —saldos o transferencias—, en última instancia, vive en indexadores off‑chain que interpretan las transacciones según sus propias reglas. Esto supone confiar implícitamente en que todos los indexadores usan exactamente las mismas reglas y versiones; cuando esa confianza se rompe, deja de haber consistencia. Se logró una “innovación de datos”, pero no garantías al nivel de contratos inteligentes. En conclusión, más allá de anclar datos en Bitcoin, hace falta una nueva capa de ejecución que aporte seguridad, finalidad y verificación automatizada.

Enfoques diversos para L2 de Bitcoin

La necesidad de L2 dio pie, a grandes rasgos, a tres vías.

1. Sidechains con peg (Liquid, etc.): envuelven (“wrapping”) BTC y lo mueven a una sidechain para ganar velocidad y escalabilidad. Sin embargo, el movimiento de activos y la seguridad quedan en manos de una federación reducida de operadores. Aun con multisig, choca con los valores de descentralización y resistencia a la censura de Bitcoin. A su favor: mejor UX y velocidad.

2. Rollups en Bitcoin (Citrea, etc.): sobre el Script no turing‑completo de L1, intentan verificación on‑chain (p. ej., pruebas de fraude) mediante BitVM. Combinan pruebas ZK con verificación basada en BitVM para anclar la validez en Bitcoin; muchos L2 siguen esta vía. Aun así, a menudo requieren BTC envuelto (como cBTC) para llevar liquidez a DeFi, con las limitaciones asociadas.

3. Staking nativo de Babylon: un enfoque distinto. Sin envolver ni puentear BTC fuera de L1, refuerza la seguridad de redes PoS externas con Script on‑chain: convierte BTC de “reserva” a “colateral productivo”. Dado que los maximalistas temen la custodia, es una aproximación especialmente atractiva.

Un punto clave: no compiten entre sí, sino que pueden complementarse. Por ejemplo, BOB (Build on Bitcoin), un L2 orientado a BitVM, explota la verificación on‑chain de validez a la vez que, mediante su alianza con Babylon, conecta la finalidad (finality) de las transacciones L2 con Bitcoin L1. Si BitVM fortalece la validez de BTC envuelto, Babylon puede garantizar la finalidad de los bloques L2 con el enorme “presupuesto de seguridad” de Bitcoin. Así, Babylon está evolucionando de un protocolo de staking nativo a una capa de seguridad compartida (Shared Security Layer) para capas de ejecución sobre Bitcoin, acelerando una “modularización” del ecosistema al estilo de Ethereum.

Tabla 1: comparativa del espectro de soluciones de escalado de BTC

Conclusión

Babylon ha despertado la liquidez y productividad del capital llamado Bitcoin. Un nuevo paradigma —“capital que no se mueve (sin puente), pero se mueve (seguridad, recompensas)”— convierte BTC en capital productivo.

Al mantener BTC en L1 y combinar slashing EOTS, Script nativo y un comité externo pragmático, Babylon ha abierto la puerta a un “DeFi sobre Bitcoin” que antes parecía imposible: un potencial catalizador para el crecimiento del ecosistema.

Pero quedan tareas pendientes:

• Transparencia técnica: publicar una hoja de ruta de descentralización y la identidad de los miembros del comité de covenant para reducir progresivamente los supuestos de confianza centralizados.
• Resiliencia operativa: ampliar opciones seguras de gestión de claves para proveedores de finalidad institucionales y particulares, reduciendo el riesgo operativo.
• UX predecible: clarificar parámetros de unbonding y políticas de recompensas para evitar confusiones.

Babylon se está convirtiendo en el núcleo de BTCFi. Para que su visión se materialice, además de los avances técnicos, deben progresar la descentralización, la transparencia y la experiencia de usuario.

#[BTCFi シリーズ 2] BTCFi を動かす波：L2 と Babylon ネイティブ・ステーキング

序論

近年、ビットコインのエコシステムは爆発的な変化を遂げました。Ordinals や BRC‑20 といったメタプロトコルは、ビットコインを単なる「デジタル・ゴールド」から、より豊かな「データ・レイヤー」へと拡張しました。画像やテキストなど任意データのインスクリプションにより、BTC L1 上で資産やコミュニティを形成できるようになりましたが、他の DeFi 圏と比べると機能面ではまだ不足がありました。

これらメタプロトコルは、ビットコインを効果的なデータ保管庫として活用する一方で、複雑な状態管理や検証ロジックをフルオンチェーンで扱うことはできません。BRC‑20 の残高や移転といった「状態」は最終的にオフチェーンのインデクサが各自のルールに基づき解釈します。インデクサ間で同一仕様・同一バージョンであることを暗黙に仮定しており、その前提が崩れると一貫性は失われます。データ面の革新は成功しましたが、スマートコントラクト級の保証には至っていません。単なるデータのアンカリングを超えて、セキュリティ・ファイナリティ・自動検証を提供する新たな実行レイヤーが必要です。

BTC L2 へのアプローチ

ニーズの高まりとともに、概ね 3 つの流派が現れました。

1. ペグ型サイドチェーン: Liquid は BTC をラップしてサイドチェーンへ移し、スピードと拡張性を得ます。ただし、資産移転とセキュリティは少数のフェデレーションが管理します。マルチシグがあっても、脱中央性と検閲耐性というビットコインの核に反します。UX と速度は優秀です。

2. ビットコイン・ロールアップ: Citrea などは、BitVM を用いてビットコイン L1 の非チューリング完全な Script 上で不正/有効性証明を志向します。ZK ロールアップと BitVM 検証を組み合わせて有効性を L1 にアンカリングしますが、DeFi で流動性を得るには cBTC などラップド BTC に依存する制約があります。

3. Babylon のネイティブ・ステーキング: BTC を L1 から動かさず、オンチェーン Script と暗号技術だけで外部 PoS のセキュリティを強化します。BTC を「価値保蔵」から「生産的な担保」へ転換する発想です。カストディ・リスクを嫌う BTC マキシにとっても理にかなうアプローチです。

これらは競合ではなく、補完し合い得ます。例として、BitVM 指向 L2 の BOB は、BitVM のオンチェーン有効性検証を活かしつつ、Babylon と組んで L2 のトランザクション・ファイナリティをビットコイン L1 に接続します。BitVM がラップド BTC の有効性面を強化し、Babylon が L2 ブロックの最終確定をビットコインの巨額なセキュリティ予算で下支えする構図です。Babylon は単なる「ネイティブ・ステーキング」に留まらず、ビットコイン上の実行レイヤーに対する共有セキュリティへと進化し、モジュラー化の重心になりつつあります。

Babylon ネイティブ・ステーキングの仕組み

Babylon は、ビットコイン L1 の Script と暗号技術を巧みに組み合わせています。最重要要件は、ホルダーの BTC が L1 から動かないこと。その仕組みを見ていきます。

2.1. 3 つの Taproot UTXO 経路: Taproot UTXO 内に条件付きの支出経路を 3 つ定義し、BTC を L1 のままステーキング可能にします。

• Timelock 経路: 所定ブロック経過後、自由に引き出し可能。
• Unbonding 経路: 期限前の解約にはステーカー署名に加え、規約エミュレーション委員会の署名が必要で、プロトコル既定の解約手順を強制。
• Slashing 経路: FP（Finality Provider）が同高度で二重署名などの背信行為を行った場合、あらかじめ定めた割合の BTC をバーンアドレスへ移動。

2.2. EOTS によるスラッシング: EOTS（Extractable One‑Time Signatures）とアダプタ署名を用い、FP が矛盾署名を行うと秘密鍵が露見し、事前構築のスラッシュ TX が原子的に発動します。

この手法は L1 の検証制約を迂回しますが、二重署名のみが対象で、ダウンタイムや投票漏れ等の非悪意的障害は罰しません。運用リスクが FP に集中するため、Cubist などの専門的な鍵管理が重要です。

2.3. 規約エミュレーション委員会: Bitcoin Script には Covenant を直接強制する機能がなく、M-of-N マルチシグの委員会が事前署名でルール執行を補完します。早期解約やスラッシュ TX に委員会共同署名が関与します。

これは現実的解決策ですが、透明性の課題を伴います。委員会署名なしでは早期解約は不可能で、委員会が結託し署名を拒めば Liveness が損なわれ得ます。現時点で委員会メンバーの身元は公表されておらず、機能性のために限定的な信頼を導入する明示的トレードオフです。

2.4. チェックポイントによるファイナリティ: Cosmos SDK + CometBFT を用いる Babylon ジェネシス・チェーンは、BLS 集約で検証者署名をひとつにまとめ、OP_RETURN を介してビットコイン L1 に定期的にアンカーします。

これにより、オンチェーンデータを最小化しつつ、ビットコインのセキュリティで Babylon の最終性を強化します。BOB のような BitVM 系 L2 が Babylon をファイナリティ・レイヤーとして使う理由です。

表 2: Babylon ネイティブ・ステーキングの主構成

経済・エコシステム戦略

Babylon は単なるプロトコルを超え、BTC 流動性を多面的に動員するハブを目指します。

3.1. 誰が、なぜ BTC をステークするのか

伝統的に BTC ホルダーは枚数保全を重視し、リスクを避けます。Babylon は BTC を L1 に留めたままステーキングできるため、参加のハードルを下げます。アクセス手段は次のとおりです。

• 個人投資家: Kraken などの CEX で簡単に参加可能。ラップやブリッジ不要で、一般的な PoS と同様の UX。報酬は BABY（将来的に BSN 報酬も）。
• 機関投資家: Anchorage や Hex Trust 等のカストディが、規制・セキュリティ要件に沿ったチャネルを提供。

3.2. BSN（Bitcoin Supercharged Network）: PoS がビットコインのセキュリティを「購入」し、対価として自チェーンのトークンを Babylon ステーカーへ配分。コールドスタートの解消、短いアンボンディング、攻撃コストの大幅上昇といった利点を得ます。

例:

• Osmosis: BSN 化の条件として、Babylon 生態系資産由来のテイカー手数料の 50% を FP に配分する提案。PoS セキュリティ購入の具体像であり、Babylon の収益線になり得ます。
• Sui: DAG ベース合意との結合は、Babylon のモジュール性とスタック非依存性を示します。
• BOB: BitVM ロールアップが Babylon を最終性レイヤーとして活用。Babylon バックの LST で流動性を拡大し、Babylon のセキュリティで安定性を確保。

3.3. LST による資本効率: ロック中の BTC は不流動です。Lombard は Babylon ステークを裏付けとする 1:1 担保の LBTC を発行し、報酬を蓄積。ユーザーは LBTC を担保・貸付・LP などに活用し資本効率を最大化できます。

表 3: パートナー/チャネル別の比較

Babylon の課題

Babylon は革新的ですが、課題も残ります。

4.1. 技術/運用リスク: EOTS ベースのスラッシュは二重署名に厳罰を科すため、鍵管理やソフト不具合に起因するスラッシュ・リスクを FP が負います。運用堅牢性が資産安全と直結し、専門鍵管理（例: Cubist）が重要です。

4.2. UX/透明性: アンボンディングの混乱: 公式は 301 ブロック（約 50 時間）とする一方、Kraken や Hex Trust は約 7 日または 1,008 ブロックと案内。CEX の内部流動性/セキュリティ要件に伴う遅延や、ガバナンスによるパラメータ変更可能性が UX の予見性を損ね、技術的透明性・商業パートナー・ガバナンス方針の緊張関係を浮き彫りにします。

4.3. フルスタック構想: EVM 支援や BTC ネイティブ DeFi のホスティングまで視野に入れると、ETH L2 との競争が一段と直接的になり、流動性・開発者誘致が鍵となります。

結論

Babylon は「ブリッジなしで、セキュリティ/報酬という意味で資本を動かす」ことで、BTC の流動性と生産性を呼び覚ましました。BTC を生産的資本へ転換するパラダイムです。

BTC を L1 に留め、EOTS・ネイティブ Script・外部委員会という現実的妥協を組み合わせることで、「ビットコイン DeFi」への扉を開きました。

残る課題:

• 技術的透明性: 委員会メンバーの開示と分散化ロードマップで、中央集権的信頼を漸進的に解消。
• 運用安定性: 機関/個人 FP 向けの安全な鍵管理の普及で運用リスクを軽減。
• 予見可能な UX: アンボンディング/報酬ポリシーの明確化で混乱を低減。

Babylon は BTCFi の中核になりつつあります。そのビジョンを実現するには、技術革新に加えて、分散化・透明性・ユーザー体験での前進が不可欠です。

#[BTCFi 系列 2] 推动 BTCFi 的浪潮：L2 与 Babylon 原生质押

引言

近几年，比特币生态发生了剧烈变化。Ordinals、BRC‑20 等元协议把比特币从“数字黄金”拓展为更具表现力的“数据层”。通过铭刻任意数据（图片/文本），我们可以在 BTC L1 上发行资产、凝聚社群，但整体能力仍弱于其他 DeFi 生态。

这些元协议把比特币很好地用作数据存储，但无法在链上处理复杂的状态管理与验证逻辑。BRC‑20 的余额与转账最终由链下索引器按各自规则解释。这隐含假设索引器使用完全一致的规范与版本；一旦破裂，一致性即失。数据层的创新是成功的，但距离智能合约级别的保证仍有差距。我们需要的不只是锚定数据，而是能提供安全性、最终性与自动化验证的执行层。

面向 BTC L2 的路径

随着需求升温，大致形成三类路径。

1. 挂钩侧链：Liquid 将 BTC 包装后转移到侧链，获得速度与扩展性。但资产迁移与安全由少数联盟管理。即便有多签，也削弱了比特币去中心化与抗审查的核心价值。其优点是 UX 与速度突出。

2. 比特币 Rollup：如 Citrea，试图在比特币非图灵完备的 Script 上通过 BitVM 实现链上欺诈/有效性证明。许多 BTC L2 结合 ZK Rollup 与 BitVM 验证，把有效性锚定到 L1。但要进入 DeFi 场景，往往仍需依赖 cBTC 等包装资产，带来信任与跨链限制。

3. Babylon 原生质押：不包装、不跨链，把 BTC 留在 L1，仅依靠链上 Script 与密码学为外部 PoS 提供安全。这把 BTC 从“存储价值”转化为“生产性抵押”。考虑到 BTC 极端主义者对托管风险的厌恶，这是一条颇具吸引力的路线。

它们并非彼此竞争，反而可以形成协同。以 BOB（Build on Bitcoin）为例：这是一条以 BitVM 为核心的 L2，一方面用 BitVM 做链上有效性验证，另一方面通过 Babylon 把 L2 交易的最终性连接回比特币 L1。可以理解为：BitVM 加强对包装 BTC 的有效性与安全性，Babylon 用比特币庞大的安全预算为 L2 区块的最终性背书。Babylon 正在从“原生质押协议”走向“执行层的共享安全层”，类似以太坊世界里的模块化趋势，成为 BTCFi 的引力中心。

Babylon 原生质押的机制

Babylon 巧妙结合比特币 L1 的 Script 与现代密码学。对安全与持币者来说，核心就是 BTC 不离开 L1。其机制如下。

2.1. 三路径 Taproot UTXO：在 Taproot UTXO 内预置三条条件支出路径，使 BTC 保持在 L1/钱包中即可完成质押。

• Timelock 路径：达到区块高度后可自由提取。
• Unbonding 路径：到期前的提前解锁需要质押者签名外，另需“契约仿真委员会”签名，用以强制执行协议解绑规则。
• Slashing 路径：若最终性提供者（FP）被检测到双签，按预设比例把 BTC 发送至销毁地址。该路径通过质押者、FP 与委员会的预签名启用。

2.2. 基于 EOTS 的惩罚：利用 EOTS（可提取一次性签名）与适配器签名，若 FP 在同一高度对相互冲突消息签名，其私钥会被推导暴露，从而完成预构建的惩罚交易，原子性地把固定比例的 BTC 发送到销毁地址。

此法绕开了比特币 L1 的某些验证限制，但也有取舍：仅对“双签”惩罚，停机、漏投等非恶意故障不处罚，令运维风险集中在 FP，需要专业密钥管理（如 Cubist）。

2.3. 契约仿真委员会：由于 Script 无法原生强制执行 Covenant，Babylon 采用 M-of-N 多签委员会的预签名来模拟执行规则（提前解锁与惩罚均需其共同签名）。

这是务实的权衡，但带来透明度问题。没有委员会的共同签名，无法提前解锁；若委员会合谋拒签，系统活性可能受威胁。目前委员会成员身份未公开，这意味着为增强功能而引入有限信任的明确权衡，同时应规划逐步去中心化。

2.4. 通过检查点实现最终性：Babylon 创世链（Cosmos SDK + CometBFT）使用 BLS 聚合把验证者签名合并为单一签名，并通过 OP_RETURN 定期锚定到比特币 L1。

这既最小化链上数据，又借助比特币安全性增强 Babylon 的最终性。也因此，像 BOB 这样的 BitVM L2 会把 Babylon 作为最终性层。

表 2：Babylon 原生质押的关键组件

经济与生态策略

Babylon 的目标不止是协议本身，更是动员 BTC 流动性的生态枢纽。

3.1. 谁会质押 BTC？为何质押？

传统 BTC 持有者强调保有数量、厌恶风险。Babylon 让 BTC 留在 L1 钱包里即可质押，从而降低参与门槛。主要通道如下：

• 个人投资者：通过 Kraken 等 CEX 便捷参与。无需包装或跨链，体验类似普通 PoS 质押。奖励以 BABY（未来也可能有 BSN 奖励）计。
• 机构投资者：Anchorage、Hex Trust 等托管机构提供安全、合规的通道，契合机构的长期持币与合规需求。

3.2. BSN（Bitcoin Supercharged Network）：Babylon 让 PoS 链“购买”比特币安全；这些链向 Babylon 质押者分发其原生代币为回报。BSN 获得冷启动、缩短解锁、显著抬高攻击成本等益处。

示例：

• Osmosis：作为加入 BSN 的条件，提议把 Babylon 生态资产的 50% 接单费分配给 FP。这是“购买 PoS 安全”的具体模式，也可能成为 Babylon 的收入路径。
• Sui：与 Sui 的 DAG 共识对接，体现了 Babylon 的模块化与技术栈无关性。
• BOB：BitVM Rollup 把 Babylon 作为最终性层；通过 Babylon 支持的 LST 扩大全链流动性，并以其安全性保障稳定性。

3.3. LST 激活资本效率：质押 BTC 在锁定期内缺乏流动性。Lombard 基于 Babylon 质押发行 1:1 抵押的 LBTC，并累积收益。用户可以将 LBTC 用作抵押、借贷、做市等，从而最大化资本效率。

表 3：按伙伴/通道的比较

Babylon 面临的挑战

Babylon 具有显著创新性，但仍有若干挑战。

4.1. 技术/运营风险：EOTS 基惩罚对双签实施严厉处罚，意味着由于密钥管理或软件失误，FP 可能遭遇即时惩罚。运维稳健性与资产安全直接相关，专业密钥管理（如 Cubist）至关重要。

4.2. 体验/透明度：解锁参数的困惑：官方称当前解锁约为 301 个区块（约 50 小时），而 Kraken、Hex Trust 等伙伴提示为约 7 天/1,008 区块。除去文档时效差异，CEX 可能出于内部流动性或安全管理而额外增加延迟。解锁期是协议参数，可由 BABY 治理调整，因此存在不可预期性，损害用户体验，也暴露技术透明度、商业合作与治理政策之间的张力。

4.3. 全栈愿景：Babylon 计划支持 EVM 并托管 BTC 原生 DeFi 应用，成为“全栈 BTCFi 中心”。这将更直接地与以太坊 L2 竞争，需要吸引充足的流动性与开发者。

结论

Babylon 唤醒了 BTC 的流动性与生产力——“币不动桥不跨，但安全/收益在动”的新范式，把 BTC 变为生产性资本。

通过让 BTC 留在 L1，再结合 EOTS 惩罚、链上 Script 与务实的外部委员会，Babylon 打开了此前难以想象的“比特币 DeFi”大门，或将成为生态的重要催化剂。

但仍需补足：

• 技术透明：披露契约委员会、推进去中心化路线，以逐步消解集中式信任假设。
• 运营稳健：推广机构/个人 FP 的安全密钥管理，降低运维风险。
• 可预期体验：明确解锁参数与奖励政策，减少困惑。

Babylon 正成为 BTCFi 的核心力量。要让愿景真正落地，除了技术突破，也必须在去中心化、透明度与用户体验上持续推进。