Overview
Chaos Labs supports listing LBTC on Aave V3’s Ethereum Main instance. Below is our analysis and initial risk parameter recommendations.
Technical Overview
LBTC is a liquid staking token offered by Lombard, representing BTC staked with Babylon. It generates yield from Babylon’s native staking rewards and Lombard Lux, the protocol’s reward system for early adopters.
Depositing and Staking
When depositing on Lombard, users send BTC to a unique SegWit address. Lombard generates a distinct SegWit Bitcoin deposit address for each user, utilizing CubeSigner—a tool that securely stores all keys in dedicated hardware and enables the creation of custom policies around keys usage. Lombard uses it to enforces strict access controls, allowing transactions exclusively with Babylon and requiring multi-party approval (MPA).
Lombard’s architecture centers around the Security Consortium, a distributed network of nodes, each managed by a different organization. When a user deposits BTC, every consortium member independently verifies the transaction on the Bitcoin network.
Once validated, the consortium collectively signs a notarized proof. The user then submits this signed proof to the LBTC smart contract on the Ethereum mainnet, triggering the minting of an equivalent amount of LBTC.
Source: Lombard Documentation
Simultaneously, the notarized proof triggers the staking of the deposited BTC with Babylon. A special transaction is created detailing the BTC amount, the Babylon Staking Contract address, and a timelock that defines the duration of the BTC stake on Babylon and selects finality providers, which are equivalent to validators of PoS networks. The consortium then signs this transaction, and the BTC is deposited into Babylon. For BTC deposits, Babylon uses Bitcoin’s native scripting capabilities to create time-locked UTXO contracts. Once the transaction is received in the contract, the user’s deposited stake will be allocated in the form of voting power to the corresponding finality provider. Additionally validators receive a 3–5% commission from staking rewards.
The Security Consortium also transfers an Extractable One-Time Signature (EOTS) to the finality provider, which serves as proof of ownership of the deposited BTC. When the finality provider participates in finality votes on a PoS network, they use the EOTS for the signatures, demonstrating control over the staked BTC delegated to them by Lombard, without having access to the actual private keys.
Source: Babylon Documentation
Slashing
If a finality provider violates consensus rules, such as double-signing, the EOTS cryptographic mechanism exposes the private key of the contract where the provider’s delegated BTC is locked. This enables anyone on the network to use the key to initiate a slashing transaction on the Bitcoin blockchain. The slashed funds are then transferred to a designated address by the Babylon protocol. While slashing is currently inactive—pending activation during Phase 2—it is expected to follow the ongoing deposit event. No specific public release date for Phase 2 is available.
Importantly, slashing risk for LBTC is significantly mitigated by the following factors:
- For a safety violation to happen in the Babylon protocol, over 1/3rd of the total stake would have to sign two blocks at the same height, hence being considered malicious. Only then a slashing transaction can be initiated.
- Validators cannot be slashed for being offline or inactive, unlike Ethereum. Slashing only applies if a validator actively votes on a duplicated block, meaning Lombard’s staked BTC faces minimal risk of being slashed under normal conditions.
- The
slashing_ratespecified in the latest version of the Babylon parameters on GitHub starts at 10% and can be adjusted through network consensus. Additionally, the slashing mechanism may be set up to lock a portion of the stake into a timelock rather than burning it entirely, further reducing the impact of slashing events.
These structural design choices collectively make the likelihood of slashing for LBTC extremely low.
Unstaking and Withdrawals
A user on Lombard initiates the unstaking process by burning LBTC tokens, triggering a request to the Security Consortium to unstake the corresponding BTC from Babylon. After the 7-day withdrawal period set by the Babylon protocol, and a fixed 0.0001 LBTC Network Security Fee is applied, a bridge contract on Ethereum facilitates the BTC withdrawal using another mechanism called the Bascule Drawbridge. The Bascule Drawbridge verifies the request by checking its internal depositHistory mapping for a corresponding deposit record, ensuring the withdrawal matches a previously validated deposit.
DeFi Vault
User can also take a step further and deposit LBTC to Lombard DeFi Vault to maximize their return. LBTC deposits incur no fees, but a 1.5% annual management fee is applied to vault holdings. Withdrawals can be initiated at any time, with LBTC redeemable after a three-day processing period. During this time, users cannot initiate new withdrawals to ensure orderly processing.
Market Cap and Liquidity
Since its inception, LBTC’s supply and corresponding LTV have shown a steady growth trend. As of the time of writing, the total supply of LBTC has reached 13,626, with a corresponding TVL of $1.357 billion.
LBTC Supply Overtime by Chain
LBTC TVL Overtime
LBTC has demonstrated substantial growth in DEX liquidity over the past four months, with total TVL reaching $72 million, which handles a trade of over 300 LBTC before incurring an 8.5% price impact. The liquidity is primarily concentrated in Curve and Uniswap pools, with most of it paired against WBTC and cbBTC. A smaller portion of liquidity is also paired against eBTC in the Curve BTCfi pool.
Roughly 80% of the LBTC Uniswap liquidity is actively managed by the Lombard DeFi vault, which actively manages the liquidity range on Uniswap V3 by rebalancing between LBTC to WBTC through withdraws from the EtherFi vaults.
Volatility
The LBTC/WBTC ratio has been relatively stable since September, with the largest observed depeg being 54 bps.
Relative to BTC, LBTC has exhibited a 7.66% daily annualized volatility. This has not decreased in the last 30 days, measuring at 9.85%.
LTV, Liquidation Threshold, and Liquidation Bonus
Given the above analysis, we can conclude that the LBTC ecosystem and liquidity show a steady growth trend. However, given the LBTC’s relative novelty and the liquidity remains small compared to the total supply. At this stage, we recommend adopting more conservative initial parameters. Therefore, we suggest a 70% LTV, 75% of LT, and 8.5% of Liquidation Bonus at this point.
Interest Rate Curve
Given the historically low demand for volatile assets to be borrowed except for staking, we recommend setting the Uoptimal at 45% at this moment.
Supply and Borrow Cap
We use our usual supply cap methodology, setting it at 2x the liquidity available beneath the LB price impact. Additionally, we recommend setting the borrow cap at 10% of the supply cap, as we have expected the low borrowing demand for LBTC. Thus, we reached a 800 supply cap and 80 borrow cap.
Oracle Configuration/Pricing
An LBTC/USD market oracle is currently available on Chainlink. However, an LBTC exchange rate is essential to ensure accurate and reliable price determination when slashing is enabled and when the asset begins generating yield.
Given that LBTC is still in Phase 1 and the slashing mechanism is currently not implemented, its risk profile remains low until Phase 2 starts. The temporary absence of slashing introduces the possibility of using a BTC/USD price feed in order to avoid liquidations from peg instability that would have been introduced by using a market rate feed and to maintain higher efficiency within the E-Mode.
A Proof of Reserve oracle feed from RedStone Finance currently exists, with a Chainlink PoR feed expected in Q1 2025. However, PoR feeds also present their own risks. Specifically, mismatches in deposit detection, similar to the Chainlink FBTC case, can artificially inflate prices during normal market conditions due to the time difference between the detection of new BTC backing and the issuance of the respective ERC-20s on Ethereum. When the PoR feed from Chainlink becomes available, the introduction of CAPO will mitigate this risk by capping the upside in a programmatic way determined by the yield accrued.
Moreover, during a slashing event, the BTC/USD oracle feed shares a risk profile similar to that of the PoR feed, assuming sufficient market parameterization. Without such liveness risks under Tendermint BFT consensus coupled with swift, aggressive slashing penalties for malicious behavior, under the assumption that Lombard deliberately acts maliciously, given the tight liquidity range and the expectation that LBTC’s price would rapidly drop to 0.9 BTC, liquidations would freeze at this lower price due to a lack of market liquidity. Under current assumptions, this would leave any position with a health factor higher than ~1.01 (because of the liquidity concentration in a 1% range) effectively frozen. In this event, the remaining liquidatable positions can be internalized by Aave to reduce the accrual of bad debt to the buffer between LTV and post-slashing value.
Given the similarity of risks between the two oracle structures, we recommend adopting a BTC/USD oracle feed. Through the Guardians’ action, the protocol has the ability to freeze the market, to ensure the market’s safety in case of a slashing event. Additionally, if necessary, the protocol can switch to an LBTC/USD market oracle to reprice collateral and induce liquidations if on-chain liquidity is found. This interim solution bridges the gap between the Phase 2 slashing implementation going live, and the Chainlink’s PoR feed becoming operational. To further mitigate risks, we also recommend more restrictive parameters for the E-Mode, increasing the buffer between liquidation triggers and bad debt accrual.
E-Mode
We recommend enabling E-mode upon the choice of BTC/USD price feed or the future release of a robust Chainlink internal exchange rate oracle. Given the initial recommendation for a BTC/USD price feed and the actively managed liquidity from the Lombard DeFi vault, we recommend the following parameters: 84% LTV, 86% LT, and a 3% Liquidation Bonus. Given that the slashing penalty is configured to 10%, under our proposed parameterization users cannot profitably arbitrage from the inflated collateral value in such an adverse scenario occurring.
Specification
Following the above analysis, we recommend the following parameter settings with the use of a BTC/USD oracle:
| Parameter | Value |
|---|---|
| Network | Ethereum |
| Isolation Mode | No |
| Borrowable | Yes |
| Collateral Enabled | Yes |
| Supply Cap | 800 |
| Borrow Cap | 80 |
| Debt Ceiling | - |
| LTV | 70.00% |
| LT | 75.00% |
| Liquidation Bonus | 8.50% |
| Liquidation Protocol Fee | 10% |
| Variable Base | 0.0% |
| Variable Slope1 | 4.0% |
| Variable Slope2 | 300% |
| Uoptimal | 45% |
| Reserve Factor | 50% |
| Stable Borrowing | Disabled |
| Flashloanable | Yes |
| Siloed Borrowing | No |
| Borrowable in Isolation | No |
E-mode
| Parameter | Value | Value |
|---|---|---|
| Asset | LBTC | WBTC |
| Collateral | Yes | No |
| Borrowable | No | Yes |
| Max LTV | 84% | - |
| Liquidation Threshold | 86% | - |
| Liquidation Bonus | 3.00% | - |
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this ARFC.
Copyright
Copyright and related rights waived via CC0