[ARFC] Onboard LBTC on Aave v3 Core Instance

[ARFC] Onboard LBTC on Aave v3 Core Instance

Author: ACI ( Aave Chan Initiative)

Date: 2024-12-10

ARFC has been updated 2024-12-19 with latest Risk Parameters provided by Risk Service Providers.


Summary

This proposal aims to Onboard LBTC the Main Instance and add a WBTC liquid E-Mode. By implementing this change, we seek to enhance capital efficiency for borrowers using LBTC/WBTC as collateral.

TEMP CHECK and TEMP CHECK Snapshot have passed recently.

Motivation

The motivation behind this proposal stems from several key factors:

  • High Utilization: LBTC/WBTC has demonstrated significant usage as collateral for borrowing stablecoins on other platforms.
  • Capital Efficiency: Enabling liquid E-Mode for LBTC/WBTC will allow borrowers to substantially improve their capital efficiency when using this asset as collateral.
  • Controlled Growth: Liquid E-Mode provides a mechanism for more precise control over the growth and borrow demand in relation to the overall stablecoin liquidity within Aave v3 on Core Instance.

By implementing this proposal, we aim to optimize the use of LBTC/WBTC within the Aave ecosystem, attracting more liquidity for the protocol and increasing revenues.

Specification

This proposal will add LBTC/WBTC liquid E-Mode. Risk Parameters have been provided by Risk Service Providers and ARFC has been updated accordingly.

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% -

BTC/USD chainlink price feed

Useful links

BGD. Aave v3.2: Liquid Emodes

ARFC Snapshot

Github

AIP

Disclaimer

This proposal is directly powered by ACI (Aave Chan Initiative). ACI did not received compensation for creation of this proposal.

Next Steps

  1. Publication of ARFC and if positive feedback from Service Providers and Community then escalate Snapshot.
  2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal

Copyright

Copyright and related rights waived via CC0.

2 Likes

In accordance with the 5-day ARFC timeline, we are submitting our interim report on LBTC. We are working to identify a suitable Oracle solution that would enable safe LBTC integration, particularly considering the aggressive parameters associated with E-Mode.

Summary

LBTC is a relatively new asset, launched in September 2024, that currently operates on a points-only system without yield distribution. While the protocol has shown steady growth, reaching $1.5B TVL, its market dynamics and peg stability mechanisms are still being tested. The protocol architecture is designed to accommodate future yield accruals from Babylon staking rewards, though this feature still needs to be activated.

A notable consideration is the protocol’s reliance on CubeSigner - a cloud-based HSM solution that differs from traditional MPC or on-chain multisigs. While built by respected security researchers, this solution has limited DeFi adoption, and we have yet to review it comprehensively. While the team has provided detailed documentation of their security measures, the actual implementation and ongoing operational security cannot be independently verified.

From a market perspective, LBTC faces challenges with limited and concentrated liquidity on Ethereum. There’s also an inherent risk of under-collateralization if Lombard faces slashing penalties in the Babylon Protocol. The protocol maintains sufficient bug bounties ($250K), as does its core dependency Babylon ($1M). Additionally, it features well-segregated smart contract admin access and a 24-hour timelock on critical protocol changes.

Full asset review below

1. Asset Fundamental Characteristics

1.1 Asset

Key Statistics as of December 16th, 2024:

  • Market Cap: $1.5B
  • Circulating Supply: 14,159 LBTC
  • Yield: These are the only points for now, but there are plans for redistributing Babylon staking yield.
  • Launch date: September 5, 2024

LBTC by Lombard Finance is an ERC-20 token representing liquid-staked Bitcoin. It can be minted on various EVM-enabled blockchains, including Ethereum, Base L2, and BNB Smart Chain. The system operates through the Babylon Protocol, where users’ BTC is delegated to finality providers. These providers earn yields by validating PoS chains. Lombard uses a decentralized bridge to liquefy BTC staked in Babylon across different EVM chains. Currently, LBTC holders receive only points, though there are plans to implement a re-pricing model where LBTC’s value will gradually appreciate against BTC through native yield distribution from Babylon Protocol staking rewards.

1.2 Architecture

Overview

The architecture operates across three layers: EVM smart contracts on PoS chains, the Babylon Protocol, and the Bitcoin chain. The Security Consortium coordinates these layers - independent organizations that verify and sign critical operations like BTC staking/unstaking in Babylon and LBTC minting/burning on supported chains (Ethereum, Base, and BNB Smart Chain). The Security Consortium functions as a decentralized state machine using the Raft Algorithm for consensus. Members share a Threshold Key, requiring signatures from at least 2/3 of members to validate operations that can be verified through the LombardConsortium contract.


Source: Lombard documentation, December 16th, 2024

BTC to LBTC staking process:

  1. The Security Consortium uses CubeSigner to generate a secure deposit address for user’s BTC
  2. Once BTC is deposited and verified, the Security Consortium signs the deposit using their threshold key
  3. The signed payload is recorded on the Babylon chain, providing proof for LBTC minting
  4. The user can then mint LBTC by submitting the proof to the LBTC ERC-20 contract in a trustless way


Source: Lombard Finance documentation, December 10th, 2024

Within the Babylon Protocol ecosystem, the Security Consortium manages BTC delegation to Lombard’s finality provider service. As a finality provider - analogous to a validator in the Babylon Protocol - Lombard helps secure the network and generates yield returns through the protocol’s native staking mechanism.

Babylon Protocol

The Babylon Protocol enables Bitcoin staking across three chains:

  1. Bitcoin chain: Where BTC collateral is locked
  2. Babylon chain: Tracks staking balances
  3. Target PoS chain: Enforces consensus rules

The slashing mechanism uses Schnorr signatures that could reveal stakers’ private keys. When slashing conditions are met, these keys are exposed on the Babylon chain, allowing any party to spend the slashed BTC from the corresponding UTXO.

Unlike typical PoS chains, the protocol enables near-instant bonding and unbonding. This is possible because Bitcoin’s Proof-of-Work security makes long-range attacks impractical - creating alternate forks requires competing with the main chain’s hash rate, making such attacks prohibitively expensive compared to PoS systems, which are essentially costless.

EVM Smart Contracts

The EVM part of the architecture is made of the following contracts:

  • LBTC ERC-20: the ERC-20 token contract for LBTC, which also allows for minting and burning LBTC by users.
  • Consortium’s Governance: the governance contract, an Ownable2StepUpgradeable contract which simply holds the public key part of the thresholdKey, which is needed to verify signatures from the Security Consortium onchain.
  • Proxy Upgrade Timelock: a 1 day Timelock for contract upgrades that controls the LBTC ERC-20 and Consortium’s Governance contracts.
  • Bascule Drawbridge: A redundant security component of the architecture that reports the state of the Bitcoin network, more specifically BTC deposits and withdrawals in Babylon, onchain. It is managed by the Cubist organization independently from the Security Consortium.

Bitcoin

Stakers deposit their BTC at specific addresses on the Bitcoin chain. Although the user technically retains ownership over the funds, transfers are restricted by a pre-defined set of UTXOs to spend the deposited BTC using the Bitcoin Script language, also known as Bitcoin covenants. The BTC can either be spent after a given time has expired (the unstaking delay) or sent to a burn address in case of slashing right away. The user is responsible for paying the Bitcoin network fee upon deposit and withdrawal. If the stake is withdrawn prematurely — before the unstaking delay has expired — an additional fee will be charged to the balance of the BTC deposited.

1.3 Tokenomics

Although Lombard Finance offers LUX tokens to incentivize users to hold LBTC, LUX currently has no economic value or utility within the Lombard Finance ecosystem. LUX points are not transferable and, therefore, not tradable for now.

1.3.1 Token Holder Concentration


Source: Etherscan, December 4th, 2024

Here are the top 5 holders of LBTC:

The sixth-holder is a Safe that holds 3% of the LBTC supply. Several other EOAs have holdings greater than 1% of the total supply. Although the top-5 DeFi contracts in which LBTC is deposited obfuscate the source of the LBTC deposits and could hide some whale holders, the distribution of LBTC appears to be spread out across the market.

2. Market Risk

2.1 Liquidity


Source: Cowswap, December 16th, 2024

According to Cowswap, a price impact of 7% corresponds to $35.8M of available liquidity (365 BTC).

2.1.1 Liquidity Venue Concentration

Here are the main liquidity venues for LBTC on Ethereum:

2.1.2 DEX LP Concentration

Here is the DEX LP concentration for each of the top 4 liquidity pools:

Analysis shows significant liquidity concentration among a few wallets, including those directly linked to Lombard Finance (such as the LBTC BoringVault), while smaller liquidity providers are notably absent.

2.2 Volatility


Source: Coingecko, December 4th, 2024

LBTC experienced typical post-launch volatility during August and September 2024, followed by gradual stabilization. Notable price movements include:

  • Early October: Positive deviation reaching +0.5% above peg
  • November 21-22, 2024: Brief negative deviation of -0.2%, quickly corrected by market participants

These minor price variations can be attributed to emerging DeFi opportunities for LBTC.

2.3 Exchanges

LBTC is not yet listed on any centralized exchanges, despite Binance Labs’ investment in Lombard Finance.

2.4 Growth

As of December 3, 2024, 11,423 BTC staked into Lombard Finance, spread across 17,607 holders. The TVL has steadily increased since deployment from ~$200M to close to $1.5B.


Source: DefiLlama, December 12th, 2024

LBTC’s $1.5B TVL comprises nearly half of Babylon’s TVL, demonstrating significant protocol synergy.

3. Technological Risk

3.1 Smart Contract Risk

The protocol’s source code is publicly available on github.com/lombard-finance. A total of 3 audits were performed, with the first 2 completed before the protocol launch. The overall conclusions were positive, with a few severe issues identified:

  • Halborn V0 (August 5, 2024): 10 findings total - 1 high risk, 2 low risk. No critical risks were found.
  • Veridise V0 (August 21, 2024): 10 findings total - 1 medium risk, 4 low risk. No critical or high risks were found.
  • Halborn V1.5 (October 10, 2024): 7 findings total - 1 medium risk, 3 low risk. No critical or high risks were found.

Since LBTC is built on BabylonLabs’ infrastructure, the security of the underlying protocol is also relevant. An audit conducted by Zellic (report) on June 28, 2024, identified 4 findings: 1 medium risk, 1 low risk, and 2 informational issues. No critical or high risks were found.

3.2 Bug Bounty Program

There is an Immunefi bug bounty offered by Lombard Finance with a maximum reward of $250k, active since September 4, 2024. Three smart contracts are in scope:

BabylonLabs also provides an Immunefi bug bounty since September 16, 2024, with a maximum reward of $1M for critical issues on blockchain/DLT code, and a maximum reward of $100k for critical issues found on websites and applications.

3.3 Price Feed Risk

A Chainlink LBTC/BTC price feed is available. This feed reports the secondary market price of LBTC on Ethereum.

3.4 Dependency Risk

Bitcoin

The Bitcoin chain is a protocol dependency since LBTC is a liquid staking token (LST) that represents a locked BTC on the Bitcoin chain. However, this dependency can be considered safe due to Bitcoin’s market cap’s economic security and proven PoW algorithm.

Babylon Protocol

Lombard Finance relies on the Babylon protocol to offer LBTC and acts as a finality provider within the Babylon protocol. The BTC deposited into Lombard Finance to mint LBTC is used to validate PoS chains in the Babylon Protocol. Lombard receives rewards through yield on this BTC but is also at risk of being slashed if it does not perform its duties as expected. If slashing occurs, the LBTC minted through Lombard Finance would become under-collateralized, resulting in financial losses for protocol users.

CubeSigner from Cubist

Lombard Finance relies on CubeSigner from Cubist. In this SaaS remote-signing solution, signing keys are kept in special hardware devices called HSMs (Hardware Security Modules) operated by Cubist in the Cloud. Signing keys are accessed through specific software policies. This security solution differs from onchain multisigs like Safe and MPC (Multi-Party Computation) solutions, where signing keys are split, and signatures are constructed using cryptographic methods.

While onchain multisigs are transparent, both MPC wallets and solutions like CubeSigner obfuscate the security measures in place and the list of authorized users. The Lombard documentation mentions different policies, such as the need for authorizations from multiple users, restrictions on the kind of transactions that can be signed, and a timelock. The specific details of those security policies are kept private.

This remote-signing SaaS represents a serious centralization vector, with a third-party business entity controlling who can access the keys and when. This solution’s service availability and uptime guarantees are not publicly documented, introducing potential operational risks.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

Lombard Finance Ltd operates the lombard.finance interface without FCA authorization or regulation, as stated in their Terms of Service. This means users do not receive standard UK regulatory protections. The company explicitly states it does not provide financial services, brokerage, or custody.

Access is restricted to qualified entities, including companies or partnerships with ÂŁ5M+ in share capital/assets, trusts holding ÂŁ10M+ in cash/investments, or professional crypto traders operating for business purposes, as detailed in the UK Residents Notice.

The platform maintains compliance through a risk monitoring framework powered by TRM blockchain intelligence tools to prevent sanctioned address interactions.

Their points program operates under strict limitations outlined in the Legal Notice. Points cannot be monetized, transferred, converted to tokens/assets, traded, or used as collateral. Lombard Finance does not commit to future token issuance.

The platform prohibits participation from U.S. persons (including citizens, residents, and entities), those in sanctioned jurisdictions, and areas where digital asset activities are not permitted. While Anchorage Digital provides custodial services for Babylon staking, the extent of integration with Lombard’s platform remains to be clarified.

4.2 Access Control Risk

4.2.1 Contract Modification Options

Controlling wallets

Here are the two main contracts powering LBTC onchain:

The Proxy Upgrade Timelock is a 24-hour Timelock with the following roles:

The Timelock is therefore controlled by:

  • An EOA, whose key is held by CubeSigner from Cubist.
  • A 3/5 Safe multisig also referenced as the treasury by the LBTC ERC-20 contract, as it receives LBTC minting and burning fees.

Both the 3/5 Safe multisig and the EOA can propose and cancel transactions, but only the multisig can execute the changes.

The Bascule Drawbridge contract 0xc750eCAC7250E0D18ecE2C7a5F130E3A765dc260 provides redundant transaction validation by independently tracking deposits and withdrawals. This contract operates under Cubist’s direct control through their CubeSigner key management infrastructure.

Critical contract functions

We list the critical functions that each contract exposes.

LBTC ERC-20:

  • An ERC20PausableUpgradeable that can be paused by the pauser role assigned to a 2/8 Safe multisig, meaning that all LBTC transfers would be paused. The Proxy Upgrade Timelock can transfer the pauser role to another wallet.
  • The Proxy Upgrade Timelock can toggle the isWithdrawalsEnabled boolean variable, hence disabling the redumption of LBTC for BTC on the Bitcoin chain.
  • The Consortium’s Governance and the Bascule Drawbridge contracts can be updated by the Proxy Upgrade Timelock.
  • The deposit and burn commissions can be updated by the Proxy Upgrade Timelock.

Consortium’s Governance:

  • The thresholdAddr variable, which contains the address that generates the consortium signatures, can be updated by the Proxy Upgrade Timelock.

4.2.2 Timelock Duration and Function

Contract upgrades must go through a 24-hour Timelock based on the TimelockController contract from OpenZeppelin.

4.2.3 Multisig Threshold / Signer identity

Lombard implements CubeSigner from Cubist, an enterprise-grade remote-signing solution, which maintains confidentiality of signing thresholds and signer identities through sophisticated obfuscation protocols. Under a comprehensive non-disclosure agreement (NDA), Lombard has provided detailed documentation of their security frameworks. While these frameworks outline robust safeguards and compliance with industry standards, their actual implementation and adherence cannot be independently verified due to the proprietary nature of the system. The implementation includes alleged redundant backup systems with independent recovery protocols to mitigate potential risks associated with third-party service disruptions or system failures.

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters

Parameters will be presented jointly with @ChaosLabs.

Price feed Recommendation

We are unable to identify a suitable oracle at this time. Currently, Chainlink’s LBTC/BTC price feed on Ethereum mainnet relies on secondary market prices, which is not suitable for this application due to relatively low liquidity and manipulation risks.

A key consideration is the availability of an internal exchange rate oracle that accurately tracks both the ratio between Bitcoin held for Ethereum and LBTC minted on Ethereum and potential slashing events in the Babylon Protocol. Chainlink’s planned Proof of Reserve (PoR) feed in Q1 2025 could address this requirement, pending confirmation it will exclusively track Ethereum-destined Bitcoin. Alternatively, deploying an internal exchange rate system remains viable, though this requires significant contract modifications.

Either solution would protect against market manipulation and slashing events, which is critical for the proposed E-Mode integration. Following implementation, the CAPO adapter is recommended for additional security.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

2 Likes

@LlamaRisk, could you guys confirm whether you think…

  1. It would be safer to start with an LBTC listing, then wait for growth before turning on E-mode?
  2. Whether you think it would be safe to turn on E-mode for other BTC collateral first, including cbBTC and tBTC?

Expanding E-mode with an asset launched 3 months ago which doesn’t allow BTC redemption seems dangerous, especially when there are multiple safer options already supported by Aave?

1 Like

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_rate specified 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

2 Likes

Having discussed the Oracle options at length with @ChaosLabs, I’m happy to report we are in support of the recommended parameters.

5 Likes

Thank you @LlamaRisk and @ChaosLabs for your feedback.
Proposal has been updated.
Also it has been escalated to ARFC Snapshot, vote will start tomorrow, we encourage everyone to participate.

1 Like

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching both Quorum and YAE as winning option, with 745.7K votes.

Therefore [ARFC] Enable LBTC/WBTC liquid E-Mode on Aave v3 Core Instance has PASSED.

Next step will be the publication of an AIP for final confirmation and enforcement of the proposal.

LBTC (Lombard) technical analysis

Summary

This is a technical analysis of all the smart contracts of the LBTC asset and main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Lombard team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.


Analysis

LBTC is a wrapped version of BTC on EVM chains backed by 1:1 BTC reserves, staked in Babylon: users stake their BTC through Babylon and receive 1:1 LBTC that can seamlessly integrate into DeFi applications.

LBTC is also a yield-bearing token, which continues to accrue staking rewards from its staked BTC. Users can also burn LBTC and receive the BTC on Bitcoin.



For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

  • A recommendation of pricing strategy to be used in the integration asset <> Aave.
  • Any miscellaneous aspect of the code we can consider of importance.
  • Analysis of the access control (ownerships, admin roles), the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

Criticality Description
CRITICAL Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW It can cause system malfunctions, but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.

Risk Description
:green_circle: The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
:yellow_circle: The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
:red_circle: The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

  • The upgradeability admin of the LBTC system is a Timelock (Lombard Timelock) with a 24-hour delay period.
  • It uses an OZ transparent proxy pattern for proxies. Non-upgradable contracts, like the Bascule Drawbridge (technically external to LBTC), use OZ contract extensions, such as Access Control with role-based, Pausable, and the Math library.
  • LBTC also includes of off-chain modules divided into:
    • A consortium system for management across the BTC transactions, where the participants (consortium nodes) perform validations and sign transactions for stake/unstake from Babylon, or mint/burn LBTC across the EVM chains. The consortium generates BTC wallets and verifies deposits before signing any data that confirms the transaction.
    • The so-called CubeSigner hardware manages the keys of the BTC wallets. It protects the keys to be extracted, restricts which transactions can be signed by whom, requests a 3-of-5 approval (MPA) from the consortium members to be validated, and timelocks the keys to safeguard multiple transactions to be signed.
    • A general backend that tracks addresses with staked BTC listens to user transactions and communicates with the consortium by requesting the deposit/withdrawal data be signed, depending on the user’s action.

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with LBTC.



LBTC

The so-called Liquidity BTC is an upgradeable ERC20 contract in which users can mint and burn LBTC, representing 1:1 of their staked BTC, and bridge it across supported EVM chains.

Its access control is managed through role-based permissions using OZ Ownable2StepUpgradeable and a custom pauser role mechanism.

Permission Owner functions Criticality Risk
proxy Admin → LombardTimeLock upgradeAndCall() CRITICAL :green_circle:
general owner: LombardTimelock transferOwnership(), renounceOwnership(), toggleWithdrawals(), changeConsortium(), changeBascule(), transferPauserRole(), CRITICAL :green_circle:
general owner: LombardTimelock addDestination(), removeDestination() HIGH :green_circle:
pauser: Safe 2-of-8 pause(), unpause() HIGH :green_circle:
general owner: LombardTimelock changeDepositAbsoluteCommission(), changeDepositRelativeCommission(), changeTreasuryAddress(), changeBurnCommission(), changeDustFeeRate(), changeNameAndSymbol() MEDIUM :green_circle:

Access Control

  • The owner (Lombard Timelock) can add and remove supported chains via the addDestination(chain) and removeDestination(chain) functions.
  • The owner can change the contract’s ERC20 name and symbol via the changeNameAndSymbol(name, symbol) function.
  • The owner can enable/disable withdrawals via the toggleWithdrawals() function.
  • The owner can update the fees on LBTC operations (burn and bridge) by calling the changeBurnCommission(fee), changeDustFeeRate(fee), changeDepositAbsoluteCommission(fee), and changeDepositRelativeCommission(fee) functions.
  • The owner can update the consortium, bascule drawbridge, treasury, and pauser addresses via the changeConsortium(address), changeBascule(address), changeTreasuryAddress(address), and transferPauserRole(address) functions.
  • The pauser role can pause and unpause the contract via the pause() and unpause() functions.

Mint and Burn

  • Minting LBTC starts with the user sending their BTC to a staking address managed by the consortium. Once the deposit is confirmed by the consortium and reported in the bascule drawbridge, the user receives encoded data with uint256 chainId, address to, uint64 amount, bytes32 txId, uint32 index, and the keccak256 hash of the data signed by the Consortium threshold key.
    Right after, With this data in hand, the user can finally initiate the mint via the mint(data, signature) function. Internally, it verifies if the signature is signed by the consortium address in the _checkAndUseProof() function, stores it to avoid replay attacks, and confirms in the bascule bridge.
  • The user initiates the unstake of their BTC by calling the redeem(BTCAddress, amount) function, which checks internally if the BTCAddress is valid and if the amount is not below the dust amount set by the owner.
    Then, the backend listens to the burn event and informs the consortium about the unstake. The consortium validates the request and builds the BTC transaction so the CubeSigner can sign the transaction with the consortium members to transfer the BTC to the user’s address.
    The unstaking period lasts 9 days on Babylon and Lombard.

Bridging

  • Users can bridge their LBTC to supported chains (currently mainnet, Binance Smart Chain, Base, and Corn) via the depositToBridge(chain, address, amount) function. Internally, it checks if the chain is supported and discounts the bridge fee before burning the tokens. Then, the backend listens to the bridge event and communicates to the consortium so it can validate, report to the bascule drawbridge, and provide data with uint256 chainId, address to, uint64 amount, bytes32 txId, uint32 index, and the keccak256 hash of the data signed by the Consortium threshold key.
    On the destination chain, the user, with this data in their hands, finalizes the bridge by claiming their tokens via the withdrawFromBridge(data, signature) function. This function internally checks if the data is correct and the signature is from the consortium address in the _checkAndUseProof() function.
    Finally, it is double-confirmed in the bascule bridge, and the tokens are sent to the user.
    In the case of the Corn blockchain, the tokens are locked on the source chain and minted on the destination chain.

LombardConsortium

It’s an upgradeable ERC1271 contract that verifies signatures for a given hash.
Responsible for checking whether the hash is signed by a threshold address stored in the contract. It is upgradeable by the Lombard Timelock.


Permission owner functions Criticality Risk
proxy admin → LombardTimelock upgradeAndCall() CRITICAL :green_circle:
general owner: LombardTimelock transferOwnership(), renounceOwnership(), changeThresholdAddr(), HIGH :green_circle:

  • The contract owner (LombardTimelock) can set a different threshold address by calling the changeThresholdAddr(address) function.
  • This contract mainly validates signatures via the isValidSignature(hash, signature) function. It validates via ECDSA recovery if the hash signed by the signature is equivalent to the threshold address.


Bascule Drawbridge

The Bascule is a non-upgradeable contract responsible for registering deposits with unique deposit IDs and validating them when users request to mint LBTC or redeem BTC. It uses an OZ roles-based access control.

Important to highlight is designed to be a third-party extra security layer (on top of the consortium), and it is controlled by a separate team and infrascture: Cubist.

Permission owner functions Criticality Risk
DEFAULT_ADMIN_ROLE: EOA 0xC8bd…0889 (MPC by Cubist) grantRole(), revokeRole(), setMaxDeposits(), updateValidateThreshold() MEDIUM :yellow_circle:
DEPOSIT_REPORTER_ROLE: EOA 0xfa70…B3fe reportDeposits() MEDIUM :green_circle:
WITHDRAWAL_VALIDATOR_ROLE: LBTC contract validateWithdrawal() MEDIUM :green_circle:
VALIDATION_GUARDIAN_ROLE: not assigned updateValidateThreshold() MEDIUM :green_circle:

Access Control

  • Permissions in the contract are divided into DEFAULT_ADMIN_ROLE, PAUSER_ROLE, DEPOSIT_REPORTER_ROLE, WITHDRAWAL_VALIDATOR_ROLE, and VALIDATION_GUARDIAN_ROLE, with the DEFAULT_ADMIN_ROLE as responsible for setting the other roles.
  • The DEFAULT_ADMIN_ROLE (EOA 0xC8bd…0889) can set the maximum number of deposits that can be reported at once by calling the setMaxDeposits(value) function.
  • The PAUSER_ROLE (EOA 0x1E07…32aC) can pause or unpause the contract via the pause() and unpause() functions.
  • The VALIDATION_GUARDIAN_ROLE (not assigned) can update the withdrawal validation threshold via the updateValidateThreshold(value) function. However, the validation guardian role can only increase the threshold (validate fewer deposits), and its role is renounced right after execution, while the default admin can lower the threshold.

Validation Process

  • The DEPOSIT_REPORTER_ROLE (EOA 0xfa70…B3fe) is the main responsible for reporting all BTC deposits into the stake addresses via the reportDeposits(reportId, depositIDs[]). Internally, it verifies whether the number of reported deposits exceeds the maximum set and whether each depositID wasn’t previously reported.
  • The WITHDRAWAL_VALIDATOR_ROLE (LBTC contract) verifies the user’s deposit transaction status via the validateWithdrawal(depositID, amount) function. It checks whether the depositID has already been withdrawn and whether the amount is above the threshold.


Miscellaneous

  • The system has multiple security reviews: one on its V1 release by Halborn and Veridise and another on its V2 release by OpenZeppelin and Veridise. The reports can be found here.
  • A Chainlink PoR (Proof of Reserve) is on the works (HERE). Additionally, the system has a RedStone’s Proof of Reserves oracle on mainnet, Base, and BSC, updated every 24 hours or if it deviates more than 1%. The PoRs can be visualized on their Dune reserves page.
  • Because BTC is built on top of Babylon, it’s important to mention that slashing events can occur if validators take bad actions, such as double-signing. Slashing is not currently live but will be implemented in the future Babylon phase roadmap.


Asset pricing

Even if more an aspect to analyse on the side of the risk providers, secondary market pricing is not really recommended from our side, given that the asset has very thin liquidity and consequently, risk of manipulation.
Therefore, as we think the asset security is robust enough, pricing based on BTC/USD seems reasonable.

Complementary, we think the following aspects are very important to consider on the final listing risk parameters:

  • At the moment, the asset doesn’t accrue rewards, but it will in the future (depending on the activation of the mechanism on Babylon). It is very important to monitor this, as the usage of a BTC/USD price feed will misprice the asset when rewards are enabled. Worth to mention that if only used as collateral, using BTC/USD with rewards enabled would only undervalue the asset, technically only hurting users borrowing against LBTC and not suppliers.
  • The redeeming time from LBTC to BTC is relatively long, so liquidation bonus (in any e-mode) should be high enough to always keep liquidations profitable. Especially in e-mode/default combinations with no correlation, like LBTC collateral and stablecoins borrowings.


Conclusion

We think LBTC doesn’t have any problem in terms of integration with Aave, and there is no major technical blocker for listing.

3 Likes