Overview
Chaos Labs recommends listing the asset on the Ethereum Core instance, subject to the implementation of an accurate Proof of Reserve. While BTC.b is already listed on the Avalanche instance, the recommendation has been made under a different infrastructure configuration. In October 2025, Lombard acquired BTC.b with the intent to partially upgrade its infrastructure and integrate it into its broader product suite. The announcement has outlined substantial changes to the smart contract implementation on the BTC.b hosting networks, along with upgrades to the underlying reserve structure. In this analysis, we explore the changes that have been enacted during the transition.
Technical Architecture
BTC.b is a wrapped Bitcoin token originally launched in 2022 by Ava Labs. It had broad DeFi integrations on the Avalanche chains, including Aave deployment, at the time of its acquisition by Lombard Finance in October 2025.
The asset operates as a permissionless, non-custodial BTC representation on EVM chains. Users deposit native BTC on the Bitcoin network and receive BTC.b on supported chains at a 1:1 ratio. Reserve integrity is verified on-chain via Chainlink Proof of Reserve, with an independent confirmation layer provided by Cubist Bascule.
In terms of current supply distribution, the asset remains heavily concentrated on Avalanche, where it first launched, and its total circulating supply is approximately 3,477 BTC.b.
The fee structure of BTCB.b is minimal by design: minting carries a flat fee cap (currently equivalent to approximately 29 satoshis, or ~$0.02), while redemptions apply a flat burn-side fee of 0 satoshis plus a commission of 10,000 satoshis (~$6.50) to cover BTC-side transaction costs.
The system’s security model rests on three independent components operating in concert:
The Lombard Security Consortium is a CometBFT-based coordination layer operated by 15 independent digital asset institutions. Members include OKX, Galaxy, DCG, Wintermute, Amber Group, Figment, P2P, Kiln, Kraken, Antpool, and F2Pool, among others. The Consortium contract functions as an epoch-based weighted multi-signature verifier: each validator holds an address and a weight, and proof-based mints require aggregated ECDSA signatures meeting a two-thirds quorum threshold. Validator set rotations are themselves consortium-attested, preventing unilateral changes to the signer set. BTC deposits are accepted after 6 confirmations.
Cubist CubeSigner underpins key management, providing HSM-backed signing where key material is never exposed to operators and all signing actions are policy-constrained.
Cubist Bascule Drawbridge serves as an independent verification layer, confirming that BTC deposits are observed on-chain before authorizing mints, and verifying token burns before authorizing BTC payouts on redemption. Note that, as of recent configurations, the Bascule check address is set to null on Ethereum, meaning this verification layer is currently disabled on that deployment.
A Trustless Relayer automates monitoring and operational execution steps but is scoped to operational roles only, with no elevated privileges.
Reserves and Backing
Before the acquisition of BTC.b by Lombard, a proof of reserves for the asset had existed, which outlined the BTC locked on the Bitcoin network associated with BTC.b backing. The dynamics can be observed in the upper section of the attached plot. On January 28th Lombard team has effectively migrated the reserves from bc1q…9u90 to bc1q…zuke.
As the transition of reserves finalized, the question regarding the separation of said reserves with regard to Lombards distinct products became central, as the assets exhibit substantially different risk profiles. Specifically, LBTC represents staked BTC, while BTC.b does not imply similar staking-specific risks. Therefore, the question of the separation of reserves presents a central issue in our assessment.
Reserve Segregation
In order to independently assess the composition of Lombard reserves with respect to staking activity, we have used the Proof-of-Reserve contract on Base, which exposes the list of bitcoin addresses and respective owner public keys. Using getPoRAddressListLength() we identified the total number of bitcoin addresses and collected relevant addressStr and rootPkId utilizing the getPoRAddressSignatureMessages function. The resulting set has contained approximately 27,000 unique bitcoin addresses and 2 distinct root public key ids. The verified cumulative sum of the addresses’ balances matched against the Proof-of-Reserve. Nevertheless, this confirmation speaks only to the totality of reserves and does not, in itself, provide insight into their composition; whether BTC.b and LBTC reserves are held in segregated addresses or share a common pool. The latter scenario would imply that a portion of the BTC nominally backing BTC.b could be actively staked on Babylon which would contradict BTC.b’s expected risk profile.
We used the known migration address bc1q…zuke, which, as mentioned previously, has received the consolidated BTC.b reserves on January 28th during the transition to Lombard architecture, as a primary anchor to identify the majority of reserves attributable to the BTC.b backing. The fact that approximately 3385 out of 3542 BTC.b reserves were allocated in a single address directly implied that the remaining BTC.b reserves, if any, would be distributed across a relatively small number of additional addresses. This substantially narrowed the problem: any address in the reserve pool carrying a balance exceeding 200 tokens could be directly attributed to LBTC staking activity rather than BTC.b backing.
To further validate this attribution, we cross-referenced the large reserve addresses against the voting power of Lombard-associated finality providers on the Babylon protocol. Finality providers publish their aggregate delegated BTC as voting power, which we matched against the balances of addresses exceeding the 200 BTC threshold. The aggregate voting power of Lombard-associated finality providers aligned with the balances of these addresses, confirming that they are actively participating in Babylon staking and are attributable to LBTC exclusively.
| Label |
Expected Balance |
Observed Balance |
Address Number |
Addresses |
| BTC.b |
3,542 |
3,556 |
4 |
bc1q…zuke, bc1p…a8lj, bc1q…j3gp, bc1q…gzk8 |
| Lombard x Figment |
3,001 |
3,001 |
1 |
bc1p…tpj6 |
| Lombard x P2P |
2,502 |
2,501 |
1 |
bc1p…37fl |
| Lombard x Klin |
2,202 |
2201 |
1 |
bc1p…d0kj |
| Lombard x Galaxy |
2,701 |
2,701 |
4 |
bc1p…50n2, bc1p…ktz2, bc1p…kd8d, bc1q…aywm |
| Lombard |
364 |
364 |
26,952 |
bc1q…txum, bc1q…wmhg, bc1q…7dej, …. |
As the table illustrates, the observed balances across identified address sets align closely with the voting power reported by each Lombard-associated finality provider, with discrepancies of less than 1 BTC in all cases. The BTC.b reserves are concentrated across 4 addresses totaling approximately 3,556 BTC, consistent with the reported supply. The remaining large-balance addresses map cleanly to individual Lombard staking providers, with the residual addresses collectively accounting for the 363 BTC attributed to the Lombard Finance finality provider. Taken together, this confirms that BTC.b and LBTC reserves are not commingled. While directly verifying the staking status of individual Bitcoin addresses is non-trivial, the conclusion follows from a simpler observation: the aggregate voting power across all Lombard-associated finality providers is fully accounted for by the identified LBTC reserve addresses, leaving no residual delegation capacity that could implicate the BTC.b reserve addresses. The BTC collateralizing BTC.b is therefore demonstrably unstaked, consistent with its intended design and backing.
Mint and Redeem
BTC.b exists on two chains under distinct contract architectures. On Ethereum, BTC.b (0xB0F7...7072) is Lombard’s NativeLBTC contract, an upgradeable ERC-20 with Consortium proof validation, redemption logic, and role-based mint/burn authority. On Avalanche, BTC.b (0x152b...3E50) is the legacy Avalanche Bridge token with a bridgeRoleAddress pattern, where a single address, specifically Lombard’s BridgeTokenAdapter (0x85D1...e4d2), holds mint and burn authority. Both chains share a common infrastructure layer: the AssetRouter (0x9eCe...021ac), the Mailbox (0x9646...3fc0), and the Lombard Consortium’s off-chain Ledger. A keeper EOA (0xCd1b...c01b) batches most mint operations on both chains.
Three distinct domains produce mint and redeem transactions for BTC.b:
- Native Bitcoin deposits/withdrawals,
- Internal Lombard asset conversions between BTC.b and StakedLBTC (LBTC
- Cross-chain transfers via Chainlink CCIP
Native BTC Minting
The primary minting path on both chains is direct, after a user deposits BTC on Bitcoin L1 to a pre-specified address, Lombard’s validates a deposit proof, and BTC.b is minted.
On Ethereum, the keeper calls batchMintV1WithFee(bytes[] payload, bytes[] proof, bytes[] feePayload, bytes[] userSignature) directly on the BTC.b token contract. Each payload encodes a BTC deposit record; the contract validates the Consortium proof, confirms the mint through the Bascule drawbridge (0xC3ec...38eD), and mints BTC.b to the depositor. A mint commission, which is capped by a configurable maximum and confirmed the user, is deducted and routed to the Lombard treasury (0x251a...4892). Users can also submit proofs themselves via mintV1(bytes payload, bytes proof) without a keeper. The MintProofConsumed payload contains the BTC deposit txid, confirming the deposit. On Avalanche, the same flow routes through the BridgeTokenAdapter contract. The keeper calls batchMintV1(bytes[] payload, bytes[] proof) on the adapter, which validates the Consortium proof, confirms via the Bascule (0x10fa...23ad), and calls mint() on the BTC.b token using its mint authority.
Native BTC Redemption
Redemptions to the Bitcoin network follow different paths on each chain but converge on the same infrastructure: the AssetRouter contract dispatches a GMP message through the Mailbox to the Lombard Ledger’s Assets module, the Consortium authorizes custody release, and native BTC is sent to the user’s specified Bitcoin address.
On Ethereum, the user calls redeemForBtc() directly on the BTC.b token contract, which internally delegates to the AssetRouter. The event traces show MessagePaid and MessageSent on the Mailbox, a Transfer minting a neglibile fee to the Lombard treasury, and a Transfer burning BTC.b from the user. On Avalanche, the users call redeemForBtc directly on the AssetRouter, with fromToken set to the BridgeTokenAdapter (0x85D1...).
The difference in interfaces reflects the underlying contract architecture. On Ethereum, Lombard deployed BTC.b from scratch inheriting functionality from NativeLBTC with role-based access control (MINTER_ROLE granted to multiple addresses) and a native redeemForBtc() that delegates internally to the AssetRouter. On Avalanche, BTC.b is an immutable contract token with a single bridgeRoleAddress that holds exclusive mint and burn authority, Lombard’s BridgeTokenAdapter now occupies that role. Users therefore call redeemForBtc on the AssetRouter (with fromToken set to the BridgeTokenAdapter), and the adapter exercises its bridgeRoleAddress authority to execute the burn on the user’s behalf.
BTC.b and LBTC Conversion
The AssetRouter also mediates conversions between BTC.b and StakedLBTC via the Lombard Ledger’s BTC Staking module (0x89E3...C23A). Such operations typically occur in two steps: the user burns one asset, and a GMP message is sent to the Ledger, which produces a release message that a keeper (or the user) subsequently delivers to mint the other asset.
To swap BTC.b into LBTC the user calls deposit on the AssetRouter with toToken set to the LBTC contract. BTC.b is burned and a GMP message is dispatched to the Ledger’s BTC Staking module. The Ledger processes the conversion and produces a release message, which the keeper delivers via batchMintWithFee on the AssetRouter to mint LBTC. The user deposits BTC.b in 0x8dfb...476a , where BTC.b is burned, MessageSent is emitted to the module, MessageDelivered also is emitted by the same module 0x89E3..., and finally, LBTC is minted to the same user.
To perform an inverse operation users call redeem on the LBTC contract, which routes through the AssetRouter to burn LBTC and send a GMP to the Ledger. The Ledger produces a BTC.b release message, delivered via mint or batchMint on the AssetRouter.
Additionally, two redeemForBtc calls were observed on the Ethereum AssetRouter (0x97a7b6f1..., 0xc7e85c29...), both with fromToken = LBTC. These are direct LBTC to native BTC redemptions bypassing BTC.b entirely, routing through the same Assets module (0x8BF7...) used for BTC.b redemptions. Notably, no BTC.b to native BTC redemptions have ever been processed through the Ethereum AssetRouter.
Cross-chain bridging via Chainlink CCIP
BTC.b can be bridged between Ethereum and Avalanche via Chainlink CCIP. Such transactions typically originate with the user calling ccipSend on the chain’s CCIP Router. The token flows through a 4-hop burn path: User → LombardTokenPool → BridgeTokenAdapter (Avalanche only) → BridgeV2 (0x451c...0A2D) → burn. Additionally, two parallel messaging systems process the transaction: CCIP carries the cross-chain token message, while BridgeV2 simultaneously sends a Lombard GMP message through the Mailbox to the destination chain’s BridgeV2 to keep bridge state in sync. The payloadHash is identical on both chains, linking the operations. On the destination, the Chainlink DON calls transmit on the OffRamp, which routes through the LombardTokenPool to deliver the Lombard GMP and mint BTC.b.
Risk Parameters
The risk parameters proposed for BTC.b on the Core instance are derived from those currently active on the Avalanche instance, where the asset has accumulated approximately 2,400 BTC in supplied reserves. Given that BTC.b continues to represent a fully-backed, non-staked bridged claim on Bitcoin, the transition to Lombard’s infrastructure does not materially alter the asset’s underlying risk profile. The reserve structure remains intact, as confirmed by our analysis above, and the smart contract changes introduced by Lombard have been subject to independent security audits. Accordingly, we propose an LTV of 70.00%, a Liquidation Threshold of 75.00%, and a Liquidation Penalty of 6.50%.
Liquidity
At the time of writing a sell order of 170 BTC.b for USDT would incur a conservative slippage of 2%. The majority of BTC.b exit liquidity is currently allocated across a Uniswap v4 pool , Curve V2 pool with respective TVLs of $11.8 and $2.5 million.
Pricing
We recommend pricing BTC.b using a BTC/USD price feed, consistent with the oracle configuration used for other BTC-denominated assets on the Aave V3 Core instance. Given that BTC.b represents a 1:1 bridged claim on Bitcoin, no additional exchange rate adapter is required.
Specification
| Parameter |
Value |
| Asset |
BTC.b |
| Isolation Mode |
No |
| Borrowable |
No |
| Collateral Enabled |
Yes |
| Supply Cap |
600 |
| Borrow Cap |
- |
| Debt Ceiling |
- |
| LTV |
73% |
| LT |
78% |
| Liquidation Penalty |
7.5% |
| Liquidation Protocol Fee |
10.00% |
| Variable Base |
- |
| Variable Slope1 |
- |
| Variable Slope2 |
- |
| Uoptimal |
- |
| Reserve Factor |
- |
| Stable Borrowing |
Disabled |
| Flashloanable |
Yes |
| Siloed Borrowing |
No |
| Borrowable in Isolation |
No |
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this recommendation.
Copyright
Copyright and related rights waived via CC0
