BTC.b, the established BTC asset is transitioning to Lombard’s architecture and product suite, enabling multi-chain expansion and deeper DeFi integrations. Your tokens, balances, and integrations remain unchanged. No action required from holders, and optional actions for protocols.
Overview
BTC.b has been a cornerstone of Avalanche DeFi since 2022, with ~$550M in circulation and deep integrations across Aave, GMX, BENQI, and LFJ. Lombard has acquired the infrastructure and related assets of BTC.b, and the Lombard Protocol will assume responsibility for BTC.b’s bridge operations and security architecture while maintaining full continuity for existing users and integrations. BTC.b will first transition to the same trusted architecture as LBTC, before Lombard coordinates its distribution and integration across select chains and leading DeFi protocols.
Operating exclusively on Lombard’s transparent, verifiable protocol architecture, BTC.b will be a next-generation Bitcoin asset built for the decentralized economy—permissionless, non-custodial, and secure—BTC.b will bring institutional-grade security to onchain Bitcoin without the institutional gatekeepers.
This transition accomplishes three goals:
-
Augmented Security: Multi-layered architecture with decentralized validation by a consortium of leading Institutions
-
Multi-Chain Expansion: Native deployment to Ethereum, Katana, MegaETH and Solana in its initial phase
-
Improved Access: Permissionless minting directly from native BTC through the Lombard App, where it’ll be accessible alongside LBTC
What Stays the Same
For users and protocols, the immediate reality is simple: BTC.b remains the same token, and balances, addresses, and integrations remain unchanged. What changes is BTC.b’s growth opportunities: new chains, deeper liquidity, expanded DeFi integrations and opportunities, and a cleaner path for builders to integrate native BTC into Apps through Lombard’s SDK.
For Users:
-
Same token: Contract address, symbol, and name remain identical
-
Same backing: 1:1 native BTC reserves with no rehypothecation or staking
-
Same balances: All holdings, addresses, and wallet integrations unchanged
-
Same integrations: Aave, GMX, BENQI, LFJ, and all DeFi protocols continue operating normally
For Protocols:
-
Contract addresses remain unchanged
-
Protocols must no longer call the ‘unwrap’ function on the BTC.b smart contract to withdraw to native Bitcoin. As the BTC.b contract is immutable, a new Lombard contract must be used for this purpose.
-
The previous ‘unwrap’ function expected BTC to be withdrawn to a specific address generated by Core Wallet from the same seed as the Avalanche address.
-
Lombard requires you to explicitly provide the recipient in the ‘redeemForBTC’ function to a newly deployed `AssetRouter` smart contract.
-
-
Standard price feeds continue functioning
-
Proof of reserve feeds will need to be updated to Lombard-based feeds when available from Chainlink
-
Existing liquidity pools and lending markets unaffected
The BTC.b you hold today is the BTC.b you’ll hold once the transition completes in Q4. This is an infrastructure upgrade, not a token migration.
What’s New
Multi-Chain Expansion
In its initial phase, BTC.b will expand beyond Avalanche to Ethereum mainnet, Katana, MegaETH and Solana.
Direct Minting
Anyone can mint BTC.b directly from native Bitcoin through the Lombard App—no intermediaries, no KYC, no geographic restrictions (except for sanctioned jurisdictions).
SDK Integration
BTC.b joins the Lombard’s SDK, enabling developers to offer users the following:
-
Native BTC deposits & one-click Bitcoin yield access within partner applications
-
Native wallet integrations (already live with Binance and Bybit)
-
Streamlined developer implementation
-
Unified vault products across BTC.b and LBTC
Augmented Security Architecture
The transition implements a trust-minimized, multi-layered security model detailed in the next section.
Technical Architecture: What’s Changing
The current Avalanche bridge uses Intel SGX enclaves with a Warden network to index Bitcoin and coordinate transactions. The new architecture implements multiple independent security layers with decentralized validation, and is designed to scale BTC.b across multiple chains while preserving verifiability and operational discipline.
Architecture Comparison
Current Model (Avalanche Bridge):
-
SGX enclave-based key isolation
-
Warden network for multi-party approval
-
Centralized bridge operations
New Model (Lombard Protocol):
-
Hardware Security Module (HSM) backed key management
-
15-member Security Consortium with BFT consensus
-
Dual-layer verification through Cubist Bascule and Lombard Consortium
-
Byzantine fault-tolerant Lombard Ledger for traceability and transparency
Current State
New State
Why This Architecture Matters
The new security model provides:
-
No single point of failure: Requires majority consensus across 15 independent validators
-
Defense in depth: Four independent security layers that must all validate operations
-
Transparent verification: Real-time Proof of Reserve through Chainlink feeds
-
Hardware-based security: Security of keys is rooted in Cubist’s vHSM (FIPS 140 HSM + Nitro Enclave)
-
Cross-chain integrity: Independent collateral verification on every chain
-
Independent third-party audits: Security architecture and smart contracts audited by OpenZeppelin, Veridise, and Halborn. All audits are publicly available .
Security Model Deep Dive
Layer 1: Decentralized Validation
The Security Consortium replaces the Warden network with 15 independent digital asset institutions including OKX, Galaxy, DCG, Wintermute, Figment, Kiln, Antpool, F2Pool, and Kraken. This Proof-of-Authority network operates the Lombard Ledger, a Byzantine fault-tolerant consensus layer that records all protocol operations transparently onchain.
Every transaction requires majority consensus among validators, eliminating single points of failure.
Layer 2: HSM-Backed Key Management
In the new security model, the Security Consortium members use Cubist’s CubeSigner platform to manage keys and sign transactions. Unlike in the previous model, where SGX enclaves were used to reconstruct keys and coordinate Warden approvals, Consortium members sign transactions but never have access to secret key material. Instead, keys remain in Cubist’s secure hardware, which combines FIPS 140 HSMs and Nitro Enclaves to provide enhanced security. Moreover, these keys are further locked down by multiple security policies, which restrict the Consortium members to only signing specific types of transactions (e.g., mints backed by deposits) approved by a majority of the parties.
Layer 3: Governance Policies
Multiple security policies govern key usage:
-
Timelocks: Enforced delays for sensitive operations
-
Multi-Party Approval (MPA): Multiple consortium members must approve every transaction and policy change
-
Transaction restrictions: Keys can only sign specific pre-approved transaction types
Layer 4: Independent Bridge Verification
Two independent systems verify all operations:
-
Cubist’s Bascule Drawbridge: Verifies collateral consistency across Bitcoin and destination chains (Avalanche C-Chain, Ethereum, etc.)
-
Chainlink CCIP: Verifies collateral across chains where BTC.b is bridged, by providing secure cross-chain messaging and real-time Proof of Reserve verification
This dual-verification approach ensures 1:1 backing through independent auditing layers.
Deposit Flow
-
Authenticated Deposits: Users deposit BTC to deterministic addresses that encode their destination EVM address on the Avalanche C-Chain. This enables address verification and provides phishing protection.
-
Consensus Validation: Security Consortium validates and notarizes the deposit transaction through BFT consensus on Lombard Ledger.
-
Dual Verification: Both Bascule and CCIP independently confirm the collateral backing.
-
Minting: BTC.b tokens are minted to the user’s specified address after all validations pass.
Withdrawals (burns) follow the same multi-layer validation process in reverse.
For Builders: Integration Updates
Avalanche Developers
Whilst contract addresses remain the same, the BTC redemption flow has changed. The previous `unwrap` function is now depreciated and developers must use the new Lombard adapter for redemptions.
Optional updates:
Core Wallet Users
The Lombard SDK will be embedded natively within Core Wallet on Day 1, enabling users to get BTC.b on Core Wallet.
New Integrations
The Lombard SDK provides simple integration for protocols, wallets, and platforms:
Timeline
Current Status: Migration underway with testing and security audits in progress
Expected Launch: Q4 2024
Transition Process:
-
Final security audits completion
-
Mainnet deployment and verification period
-
Seamless cutover with minimal user-facing downtime
-
Post-launch monitoring and support
Both Lombard and Avalanche teams will provide regular updates through official channels as milestones are completed. Subscribe to official channels for detailed progress updates.
BTC.b will continue serving as Avalanche’s primary Bitcoin bridge while expanding to become a truly multi-chain Bitcoin asset with institutional-grade security and permissionless access.
FAQ
Do I need to do anything with my BTC.b? No. Your tokens remain unchanged and require no action.
Will there be any downtime? The transition is designed for seamless cutover with minimal interruption to transfers or integrations. It is expected that minting and redeeming BTC.b will not be possible for up to 2 hours only. In the instance that a transaction is sent during the cutover users will experience a slight delay, and should not worry about loss of funds.
What if I have BTC.b in a lending protocol? Your positions continue normally. Protocol integrations are unaffected.
Where can I get technical support? Speak to Lombard representatives via Discord, or the Intercom feature on the website.
For questions about this transition, contact Lombard via Discord, or the Intercom feature on the website. For partnership inquiries, visit lombard.finance.