BTC.b Technical transition to Lombard architecture

BTC.b, the established BTC asset, is transitioning to Lombard’s architecture and product suite, enabling cross-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 ~$550 million in circulation and deep integrations between Aave, GMX, BENQI, and LFJ. Lombard has acquired BTC.b’s infrastructure and related assets, and 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.

BTC.b will operate solely on Lombard’s transparent, verifiable protocol architecture and will be a next-generation Bitcoin asset built for the decentralized economy – permissionless, custodial and secure. BTC.b will provide institutional-grade security to the on-chain Bitcoin without the institutional gatekeepers.

This transition achieves three goals:

1. Enhanced security: Multi-layer architecture with decentralized validation by a consortium of leading institutions

2. Multi-chain expansion: Native implementation to Ethereum, Katana, MegaETH and Solana in the early stages

3. Improved access: Permissionless mining directly from native BTC via the Lombard app, where it will be accessible alongside LBTC

Which remains 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 are BTC.b’s growth opportunities: new chains, deeper liquidity, expanded DeFi integrations and capabilities, and a cleaner path for builders to integrate native BTC into Apps via Lombard’s SDK.

For users:

• The same sign: Contract address, symbol and name remain identical

• Same support: 1:1 native BTC reserves without remortgaging or staking

• Same balances: All holdings, addresses and wallet integrations are unchanged

• Same integrations: Aave, GMX, BENQI, LFJ and all DeFi protocols will continue to operate normally

For protocols:

• Contract addresses remain unchanged

• Protocols are no longer allowed to call the ‘unwrap’ function on the BTC.b smart contract to roll back to native Bitcoin. Since the BTC.b contract is immutable, a new Lombard contract must be used for this.

  • The previous ‘unpack’ 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 specify the recipient in the ‘redeemForBTC’ function for a newly deployed ‘AssetRouter’ smart contract.

• Standard price feeds will continue to function

• Proof of backup feeds must be updated to Lombard-based feeds, if available through Chainlink

• Existing liquidity pools and credit markets remain unaffected

The BTC.b you own today is the BTC.b you will own once the transition is complete in the fourth quarter. This is an infrastructure upgrade, not a token migration.

What’s new

Multi-chain expansion

In the initial phase, BTC.b will expand beyond Avalanche to Ethereum mainnet, Katana, MegaETH and Solana.

Hit directly

Anyone can mine BTC.b directly from the native Bitcoin via the Lombard App – no middlemen, no KYC, no geo-restrictions (except for sanctioned jurisdictions).

SDK integration

BTC.b joins Lombard’s SDK, allowing developers to offer users:

• Native BTC deposits and one-click Bitcoin access provide access within partner applications

• Native wallet integrations (already live at Binance and Bybit)

• Streamlined deployment by developers

• Uniform vault products for BTC.b and LBTC

Enhanced security architecture

The transition implements a trust-minimized, multi-layered security model described in the next section.

Technical architecture: what is 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 layers of security with decentralized validation and is designed to scale BTC.b across multiple chains while maintaining 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) supports key management

• Security consortium with 15 members and BFT consensus

• Double-layer verification via Cubist Bascule and Lombard Consortium

• Byzantine fault-tolerant Lombard Ledger for traceability and transparency

Current state

New condition

Why this architecture matters

The new security model offers:

• No point of failure: Requires majority consensus among 15 independent validators

• Defense in depth: Four independent layers of security that all need to validate operations

• Transparent verification: Real-time proof of reservation via Chainlink feeds

• Hardware-based security: Key security is rooted in Cubist’s vHSM (FIPS 140 HSM + Nitro Enclave)

• Integrity between chains: Independent verification of collateral in each chain

• Independent third party audits: Security architecture and smart contracts controlled by OpenZeppelin, Veridise and Halborn. All audits are publicly available.

Deep Dive security model

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 manages the Lombard Ledger, a Byzantine fault-tolerant consensus layer that transparently records all protocol operations on-chain.

Each transaction requires majority consensus among the validators, eliminating individual points of failure.

Layer 2: HSM-supported key management

In the new security model, Security Consortium members use Cubist’s CubeSigner platform to manage keys and sign transactions. Unlike 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, the keys remain in Cubist’s secure hardware, which combines FIPS 140 HSMs and Nitro Enclaves to provide enhanced security. In addition, these keys are further locked by multiple security policies, which limit Consortium members to signing only specific types of transactions (for example, coins backed by deposits) that have been approved by a majority of the parties.

Layer 3: Management policy

There are multiple security policies that govern key usage:

• Time slots: Forced 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 Authentication

Two independent systems verify all actions:

• Cubist bascule drawbridge: Checks collateral consistency between Bitcoin and destination chains (Avalanche C-Chain, Ethereum, etc.)

• Chainlink CCIP: Verifies collateral across chains where BTC.b is bridged, providing secure cross-chain messaging and real-time Proof of Reserve verification

This double-verification approach ensures 1:1 support through independent audit layers.

Deposit flow

1. Authenticated deposits: Users deposit BTC to deterministic addresses that encode the EVM destination address on the Avalanche C-Chain. This enables address verification and provides protection against phishing.

2. Consensus Validation: Security Consortium validates and notarizes the deposit transaction via BFT consensus on Lombard Ledger.

3. Double verification: Both Bascule and CCIP independently confirm collateral support.

4. Coins: BTC.b tokens are minted at the user-provided address after all validations have passed.

Recordings (burns) follow the same multi-layer validation process in reverse.

For builders: integration updates

Avalanche Developers

While the contract addresses remain the same, the BTC redemption flow has changed. The previous ‘unwrap’ feature is now deprecated and developers must use the new Lombard adapter for redemptions.

Optional updates:

Core Wallet users

The Lombard SDK will be natively embedded into Core Wallet on day 1, allowing users to get BTC.b on Core Wallet.

New integrations

The Lombard SDK provides easy integration for protocols, wallets and platforms:

Timeline

Current status: Migration is underway and testing and security audits are underway

Expected launch: Q4 2024

Transition process:

1. Completion of final security audits

2. Mainnet deployment and verification period

3. Seamless transition with minimal downtime for the user

4. Post-launch monitoring and support

Both the Lombard and Avalanche teams will provide regular updates through official channels once milestones are reached. Subscribe to official channels for detailed progress updates.

BTC.b will continue to serve as Avalanche’s main Bitcoin bridge as it grows into a true multi-chain Bitcoin asset, with institutional-level security and permissionless access.

Frequently asked questions

Do I need to do anything with my BTC.b? No. Your tokens remain unchanged and require no action.

Will there be downtime? The transition is designed for a seamless transition with minimal disruption to transfers or integrations. It is expected that creating and redeeming BTC.b will only be unavailable for a maximum of 2 hours. In the event that a transaction is sent during the transfer, users will experience a small delay and will not have to worry about losing any funds.

What should I do if I have BTC.b in a lending protocol? Your positions will continue as normal. Protocol integrations are not affected.

Where can I get technical support? Talk to Lombard representatives via Discord or the intercom function on the website.

If you have any questions about this transition, please contact Lombard via Discord or the intercom function on the website. For questions about collaboration, visit lombard.finance.