Bitcoin to Avalanche: How BTC.b Is Minted and Redeemed

Bridging Bitcoin to Avalanche deposits BTC through Lombard’s bridge and mints BTC.b, an Avalanche token backed by the deposited bitcoin. The BTC itself does not move onto the C-Chain, Avalanche’s EVM-compatible network. Instead, the holder receives a token that can interact with Avalanche contracts while redemption depends on the bridge and its backing.

The route has changed. Since January 28, 2026, Lombard handles Avalanche’s Bitcoin bridge, and Avalanche says the original Bitcoin bridge infrastructure has been wound down. The older bridge used Intel SGX enclaves and Warden nodes; those mechanics no longer describe the live service. For a separate route map of RenBridge and its current status, see RenBridge routes and what still works.

What happens when BTC is bridged to Avalanche?

The BTC deposit is verified before BTC.b is minted to the destination address. In practice, the user selects BTC.b and Avalanche in Lombard’s interface, specifies an amount and destination, then sends native BTC through the deposit flow. Once the Bitcoin transaction has the required confirmations and the bridge’s validation checks pass, the equivalent BTC.b is issued on Avalanche. BTC.b is designed to be backed one-to-one by native bitcoin.

This is a lock-and-mint arrangement at the asset level: native BTC backs a token representation on another chain. It is not a Bitcoin transaction that Avalanche validators execute, and Avalanche consensus does not verify the Bitcoin deposit by itself. Bridge infrastructure must observe and validate activity across both networks, then authorize the Avalanche-side issuance.

BTC.b is an ERC-20-style token on Avalanche’s C-Chain. That makes it usable by compatible wallets, decentralized exchanges, lending markets and other smart contracts. It can be transferred like other C-Chain tokens, but its market value and redemption depend on the bridge’s backing and operation. Its token balance is not the same thing as holding spendable BTC directly on Bitcoin.

How does BTC.b get back to Bitcoin?

Returning BTC.b to Bitcoin requires redemption through the bridge. The user submits BTC.b for a burn or equivalent redemption action, and the bridge releases native BTC to the specified Bitcoin address after validating the request. The token is removed from circulation as the corresponding BTC leaves the bridge’s reserves, preserving the intended one-to-one relationship.

The two legs have separate costs and failure points. The Bitcoin deposit requires a Bitcoin transaction fee and time for confirmations. The Avalanche-side transaction uses AVAX for gas unless the interface or another mechanism covers it. On redemption, the Avalanche transaction must succeed, and the Bitcoin payout must be processed. Congestion, an invalid destination, or a delayed bridge operation can extend the wait. A failed transaction on one chain does not automatically reverse a completed transaction on the other; recovery depends on the bridge’s procedures.

BTC.b can also move from Avalanche to other chains where Lombard supports it. That is a different operation from redeeming to native Bitcoin: current Lombard documentation describes cross-chain BTC.b transfers as burn-and-mint transfers secured by Chainlink CCIP, with a separate monitoring and security-consortium layer. For BTC.b, transfers between supported non-Ethereum chains route through Ethereum. The route and fee shown in the interface therefore matter; a token arriving on another chain is still BTC.b, not native BTC on Bitcoin.

What risks and checks matter before bridging?

The practical trade is access to Avalanche applications in exchange for added dependencies. A BTC.b holder relies on the Bitcoin deposit and payout process, bridge controls and the Avalanche token contract. Using BTC.b in a lending market or pool adds that application’s own smart-contract, liquidity and liquidation risks. If BTC.b trades below BTC, the gap can reflect redemption friction, market depth or concern about the bridge; it does not change the token’s stated backing mechanism.

• Check that the asset is BTC.b and the destination is Avalanche C-Chain. Similar tickers on other networks may be different tokens.
• Use the current bridge interface and inspect the destination address, amount and fees before approving transactions.
• Keep AVAX available for C-Chain gas after the deposit, unless the interface explicitly covers it.
• For redemption, verify the Bitcoin address format and any minimums or processing requirements shown by the service.

Do not send BTC to the old Avalanche Bitcoin bridge addresses. Avalanche’s support notice says that infrastructure has been wound down and warns against using those addresses. Use the live Lombard flow and its support path for current deposits and redemptions.

For most users, the decision is straightforward: bridge only the amount needed for a specific Avalanche use, and account for gas, redemption time and the bridge’s trust assumptions. BTC.b makes Bitcoin exposure composable on Avalanche, but it remains a claim mediated by bridge infrastructure rather than native BTC on the Bitcoin network.