[ARFC] Enable eBTC/WBTC liquid E-Mode on Aave v3 Core Instance

[ARFC] Onboard eBTC on Aave v3 Core Instance

Author: ACI ( Aave Chan Initiative)

Date: 2024-12-10

ARFC updated 2025-03-26 with latest Risk Parameters provided by Risk Service Providers.


Summary

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

Both TEMP CHECK and TEMP CHECK Snapshot have passed recently.

Motivation

The motivation behind this proposal stems from several key factors:

  • High Utilization: eBTC/WBTC has demonstrated significant usage as collateral for borrowing stablecoins on the platform.
  • Capital Efficiency: Enabling liquid E-Mode for eBTC/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.
  • Enhanced Borrowing Capacity: This change will enable users to borrow larger amounts of other stablecoins against their eBTC/WBTC collateral, potentially increasing platform utilization and revenue.

By implementing this proposal, we aim to optimize the use of eBTC/WBTC within the Aave ecosystem, attracting more liquidity.

Specification

This proposal will add eBTC/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 No
Collateral Enabled Yes
Supply Cap 750
Borrow Cap -
Debt Ceiling -
LTV 67%
LT 72%
Liquidation Bonus 10%
Liquidation Protocol Fee 10%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -

E-mode

Parameter Value Value
Asset eBTC WBTC
Collateral Yes No
Borrowable No Yes
Max LTV 83% -
Liquidation Threshold 85% -
Liquidation Bonus 3.0% -

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 escalate this proposal to ARFC Snapshot if there’s positive feedback.
  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.

1 Like

In accordance with the 5-day ARFC timeline, we are submitting our interim report on eBTC. Similarly to our comment for LBTC, and given that eBTC is largely backed by LBTC, we are working to identify a suitable Oracle solution that would enable safe integration, particularly considering the aggressive parameters associated with E-Mode. We’ve also identified some key concerns that warrant further consideration before supporting onboarding.

Summary

eBTC is primarily backed by LBTC through Lombard, with WBTC and cbBTC as additional collateral types that users can deposit to mint eBTC. The pricing mechanism assumes equal price correlation across these collateral assets at a 1:1 minting ratio, creating exposure if any collateral asset depegs or experiences volatility. LBTC lacks a pricing mechanism to reflect potential slashing events in the Babylon Protocol.

The collateral structure consists of over $700M held in the “BoringVault,” managed by Veda and Seven Seas, with more than $500M restaked across Symbiotic and Karak for yield generation. This asset is conceptually similar to weETH. Key considerations include a concentration in liquidity venues and addresses, a developing governance system needing further decentralization, and additional risks from multiple yield generation protocols. Protocol-controlled liquidity forms the vast majority of Curve and Balancer liquidity pools, with the EtherFi team committing to maintain these positions long-term.

The system is also prone to operational risks from EtherFi Foundation multisig management. The absence of timelock protection in eBTC contracts is concerning, though a 24-hour timelock has been promised. The recent unannounced removal of FBTC as accepted minting collateral raises additional governance concerns. While eBTC governance operates independently through Veda, separate from the EtherFi Foundation, the timelock owner shares significant overlap with EtherFi Foundation signatories, raising centralization concerns.

Click to expand asset analysis

1. Asset Fundamental Characteristics

1.1 Asset

Key Statistics (as of December 16, 2024):

  • Circulating Supply: 6,706 eBTC
  • Market Cap: $710M
  • Current Yield: Point-based distribution
  • Launch Date: August 18, 2024

eBTC is an ERC-20 token backed by Lombard Finance’s LBTC that enables dual yield on Bitcoin through staking via Babylon Labs and restaking through Symbiotic and Karak. Yields are currently distributed as points that convert to token airdrops each season.

Users can stake WBTC (0.4% fee), LBTC, or cbBTC to receive eBTC. The WBTC fee covers unwrapping costs to LBTC. A 7-day withdrawal period is an additional safety mechanism implemented by Veda Labs.

On December 4, the admin removed the ability to mint eBTC with FBTC without notice or explanation.


Source: Etherscan, December 16th, 2024

The token utilizes a multi-layered rewards system combining points from Babylon, Lombard, Symbiotic, EtherFi, Veda, Karak, and planned EigenLayer integrations. Points accrue based on deposit amounts and platform-specific multipliers.

Contract: 0x657e8C867D8B37dCC18fA4Caead9C45EB088C642

eBTC has integrated with major DeFi protocols, including Balancer, Curve, and Gearbox, and has established connections to platforms like Avalon, Equilibria, and Sturdy. The ecosystem continues expanding, with planned Uniswap pool integration and network expansion to Base and Arbitrum.

1.2 Architecture

Users can mint eBTC permissionlessly through the EtherFi dApp with a minimum stake of 0.01 BTC. The system uses BoringVault, developed by Seven Seas, which issues receipt tokens (eBTC) for deposited BTC.

BoringVault Architecture. Source: Veda

The BoringVault architecture consists of four main components:

  1. BoringVault (0x657e8C867D8B37dCC18fA4Caead9C45EB088C642): Core minimalist contract that delegates functionality to external contracts. Users interact through the Teller, while the Manager handles rebalancing.
  2. Teller (0x458797a320e6313c980c2bc7d270466a6288a8bb): Manages deposits/withdrawals with MEV protection through:
  3. Accountant (0x1b293DC39F94157fA0D1D36d7e0090C8B8B8c13F): Handles share pricing with safeguards:
    • Offchain exchange rate calculation
    • Rate/bound limiting
    • Automatic pausing on violations
    • Current 1:1 exchange rate with ±0.5% change limit
  4. Lens (0x5232bc0F5999f8dA604c42E1748A13a170F94A1B): Provides read-only access to vault data and status

The vault currently holds $190M in collateral, split between BoringVault and restaking on Symbiotic/Karak platforms.

1.3 Tokenomics

The total supply of eBTC is not fixed as more eBTC can be permissionlessly minted based on the demand from users staking LBTC, wBTC, and cbBTC on EtherFi. eBTC is held by 4,572 unique addresses.

EtherFi’s primary token is ETHFI, whose supply is capped at 1B and is used as the governance token for the protocol.

1.3.1 Token Holder Concentration

eBTC Top 100 Token Holders. Source: Etherscan, December 13th, 2024.

The top 5 holders of eBTC are:

  • 0x8bc93498b861fd98277c3b51d240e7E56E48F23c: 35.4% of the total supply and is restaked into Corn eBTC Silo.
  • 0x7aCDF2012aAC69D70B86677FE91eb66e08961880: 27.1% of the total supply and is restaked into Pendle’s eBTC pool.
  • 0x9d8f9295268674332A108eD7D2f537413FC8b9Ea: 6.1% of the total supply and is held by an EOA.
  • 0xb99a2c4C1C4F1fc27150681B740396F6CE1cBcF5: 5.9% of the total supply and is held by an EOA.
  • 0xADB34945d76062BA60c12F2a556096f201C55c01: 3.7% of the total supply and is restaked into Hourglass’s eBTC vault.

The top 10 holders control a significant 85.8% of the supply. When considering the top 100 holders, this concentration increases to 97.9%.

2. Market Risk

2.1 Liquidity

eBTC/ETH swap with <7.5% price impact. Source: CoW Swap Router, December 13th, 2024.

Using CoW Swap on Ethereum, a user can swap up to 73 eBTC (approximately $7.33 million) for ETH in a transaction with less than 7.5% price slippage.

2.1.1 Liquidity Venue Concentration

All eBTC liquidity pools on Ethereum. Source: GeckoTerminal, December 13th, 2024.

Curve and Balancer on Ethereum are the only on-chain markets for eBTC. The total liquidity in eBTC pools on the Ethereum Network is $17M, and almost 80% is in Curve liquidity pools, followed by Balancer V2.

2.1.2 DEX LP Concentration

The DEX liquidity concentration for the three eBTC pools:

The liquidity in the DEX pools is fully concentrated in the hands of a few wallets, which include an LBTC Boring Vault and two multisigs.

The concentration of liquidity on Curve and Balancer is attributed to protocol-supplied liquidity, which the EtherFi team has assured is stable and will not be removed. Additionally, they are actively working on further liquidity incentivization for Curve and Balancer to drive more eBTC/WBTC pool deposits.

2.2 Volatility

eBTC to BTC Chart. Source: Coingecko, December 13th, 2024.

eBTC’s price has frequently deviated from Bitcoin by more than 2%. Over the past month, it has consistently traded at a slight discount, averaging approximately 0.996 BTC per eBTC. This slight deviation, averaging 0.4%, is within acceptable bounds and does not present a significant risk to the holders.

The slight depeg of eBTC can be attributed to low liquidity in the Curve Tri BTC-Fi pool and underdeveloped arbitrage opportunities, primarily due to eBTC’s absence on CEXs, especially following Bitcoin’s rapid price movement after November 10.

2.3 Exchanges

eBTC is exclusively traded on decentralized exchanges and is not currently listed on any centralized exchange.

2.4 Growth

eBTC total supply in USD. Source: Dune, December 13th, 2024.

The total eBTC supply has grown to ~6576 eBTC ($667M) from zero in just 118 days since listing on August 18, 2024. About 4323 eBTC ($434M), 66% of the total supply, is in DeFi protocols, accruing more yield for the holders.

Some recent incentives for staking eBTC:

  • “The 12 Days of Hayes,” from December 11 through December 22, 2024, rewards eBTC stakers with ETHFI worth over $3M.
  • “The Golden Bull Event,” from November 20 through December 3, 2024, rewarded eBTC stakers with ETHFI worth over $2M plus 4x Lombard Lux points.

These events are a part of EtherFi’s Season 4 incentives. However, users must hold the staked amount in their wallets until the end of Season 4, i.e., January 31, 2025, to be eligible for rewards.

3. Technological Risk

3.1 Smart Contract Risk

Macro and Spearbit (Cantina) have audited the Seven Seas’ BoringVault contract. Seven Seas is a prominent DeFi vault builder, managing a TVL of $2.5 billion across their vaults. Following is an aggregation of the issues found by the Audit team.

  • Macro (March 20th, 2024)
Severity Count Acknowledged Won’t Do Addressed
Medium 4 - - 4
Low 4 1 - 3
Code Quality 4 1 - 3
Informational 2 - - -
  • Macro (April 22nd, 2024)
Severity Count Acknowledged Won’t Do Addressed
Informational 1 1 - -
Severity Count Acknowledged Won’t Do Addressed
Medium 8 2 - 6
Low 7 6 - 1
Informational 13 7 - 6

The presence of these audits goes some distance in mitigating smart contract risk.

3.2 Bug Bounty Program

EtherFi has a Bug Bounty program with ImmuneFi where anyone can get rewards up to $200,000 depending on the severity of the threat they found. The list of smart contracts included in the scope can be found here.

3.3 Price Feed Risk

eBTC is permissionlessly minted at a 1:1 exchange rate for each collateral (LBTC, WBTC, and cbBTC), assuming equal price correlation across all collateral types. This creates potential risk if any collateral assets experience depegging or significant price fluctuations. Additionally, the Accountant contract (prices BoringVault shares) relies on WBTC as the base asset for pricing, meaning that eBTC’s value is directly correlated 1:1 with WBTC.

3.4 Dependency Risk

The dependency risk is relatively high due to the interconnected reliance on Lombard Finance, Babylon, and the restaking protocols. Any failure in these systems could cascade and impact eBTC’s stability and value.

Veda and Seven Seas Vault
The functioning and security of eBTC are heavily reliant on the technology and infrastructure provided by Veda and Seven Seas. All collateral assets deposited to mint eBTC are stored within the Veda and Seven Seas-powered Boring Vault. This introduces a dependency risk, as any technological failures, vulnerabilities, or operational issues within these systems could jeopardize the safety of the collateral backing eBTC.

Lombard & Babylon Impact
Babylon provides the PoS staking infrastructure. LBTC is a Bitcoin LST, the primary collateral deposited to mint eBTC. If Lombard Finance does not perform its role effectively as a finality provider, it could fail to ensure the security of the staked LBTC within Babylon’s framework. This could lead to vulnerabilities in the staking process, resulting in slashing or other disruptions that would affect the value and stability of LBTC, and these issues could propagate to eBTC.

Collateral Risk
eBTC’s minting is backed by LBTC, wBTC, and cbBTC, which introduces a dependency risk. Negative events such as governance missteps, ecosystem disputes, depegs of WBTC or cbBTC, or slashing risks for LBTC could undermine the collateral backing eBTC, posing significant risks. Additionally, it takes 7 days to withdraw eBTC and reclaim the underlying collateral on the EtherFi dApp, which introduces a liquidity risk. This time delay increases the potential for volatility and risk exposure during market stress or protocol failure periods.

Restaking Protocol Risk
eBTC’s underlying collateral is sent to restaking protocols such as Symbiotic, Karak, and EigenLayer to earn additional yield and points, which enhances the value proposition for eBTC holders. However, this introduces risk as the collateral is exposed to the risks associated with these restaking protocols. Any vulnerabilities or failures within these protocols, such as slashing events, protocol exploits, or mismanagement, could directly affect the staked assets, including the LBTC backing eBTC.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

EtherFi is decentralized under DAO governance. ETHFI is the governance token with a total supply capped at 1B. Regarding the governance of eBTC, EtherFi has clarified that the EtherFi Foundation’s bylaws are separate from the eBTC deployment, which is managed in collaboration with Veda. Therefore, decisions related to eBTC fall outside the scope of EtherFi governance. The Mainnet Vault Controller multisig, which oversees the eBTC deployment, has a 4/6 threshold.

The EtherFi Foundation oversees the governance decisions by implementing two roles:

  • Proposers: Submits proposals for protocol changes and initiates community votes. For the EtherFi Foundation, EtherFi SEZC (The Labs Entity) is the current proposer in the first phase of progressive governance. As the DAO matures, additional proposers will be added.
  • Multisig Committee: Implements decisions and maintains security by handling emergency action. The Multisig Committee for EtherFi Foundation is a 4/7 Safe multisig.

EtherFi manages delegation through Agora, with Proposers reviewing delegation requests and initially nominating active community members and early adopters. Only delegates can participate in the governance process, limiting the voting supply to just 2.78M ETHFI out of 1B. According to the Governance Roadmap, more community members will gradually join the delegation process as the protocol expands. The voting period lasts 4 days, and the quorum required to pass a proposal is 1M ETHFI.

Concentrated Voting Power
Governance participation is currently restricted to delegates, representing only 2.78M ETHFI from a total supply of 1B. Within this, a single delegator, sassal.eth holds over 50% of the votable supply (1.57M ETHFI) and could pass proposals single-handedly since it’s above the quorum limit of 1M ETHFI. This undermines the principle of decentralized governance and poses a risk of unilateral decision-making even among the trusted chosen group of delegators.

Limited Diversity in Proposals
The governance structure grants Proposers exclusive authority to submit new proposals, limiting the broader community’s ability to initiate governance changes. Proposers need more diversity, as seen on the governance forum, where only two users have submitted proposals. This concentration suggests limited participation in shaping protocol changes and raises concerns about the inclusivity and representativeness of the governance process.

Legal Commentary

The Risk Disclosure Statement is an integral part of ether.fi Terms of Use outlines key risks associated with using ether.fi website and services. Gazde Finance SEZC, a Special Economic Zone Company established under Cayman Islands law, offers these services. While the disclosure highlights several risks, it acknowledges that the information provided is not exhaustive and does not capture every factor users should consider before engaging with the platform.

One significant provision clarifies that the company does not act as a custodian or manager of user assets to generate staking rewards. Instead, the responsibility for generating staking rewards rests solely with the users. The company has no influence or control over the staking rewards determined by the underlying blockchain protocol or network, which remain subject to change at any time without prior notice.

Furthermore, the statement emphasizes that the company does not offer or facilitate financial services or products. This delineation reinforces ether. fi’s position as a facilitator of decentralized interactions rather than a provider of regulated financial services. Finally, the document warns that the level of consumer protection afforded to users may vary significantly based on their jurisdiction.

Additionally, the information received from the EtherFi team clarifies that the pricing plan stipulated by the Terms of Use does not currently apply to eBTC. No fees associated with eBTC accrue to ether.fi or Veda, and holders earn 100% of the points accrued to the asset (including Lombard, Babylon, and any additional Ethereum restaking points). The updated pricing plan will be introduced once eBTC begins accruing restaking yield.

4.2 Access Control Risk

4.2.1 Contract Modification Options

Controlling Wallets

Here are the two main contracts powering eBTC onchain:

The BoringVault contract which is the same as eBTC ERC-20 has the following components:

We can see that the core components of the BoringVault/eBTC ERC-20 contract are managed through Roles Authority, controlled by the 4/6 Safe multisig.

The Hook is another important contract that allows the share pausing inside the BoringVault or implement lock periods. In this case, the hook contract is the same as the Teller’s.

Criticial Contract Functions

List of some criticial functions that each contract exposes.

eBTC ERC-20/BoringVault:

  • The Hook contract, identified as the Teller contract, can pause or enforce a lock period on shares within the BoringVault. The shareLockPeriod is set to 0, and isPaused is set to False.
  • The Accountant contract is responsible for determining the exchange rate (getRate) used to price BoringVault shares, which is used by the Teller contract. Currently, the exchange rate is set to 1, with bounds defined by allowedExchangeRateChangeUpper and allowedExchangeRateChangeLower, permitting a fluctuation of ±0.5%. The accountantState includes critical controls such as isPaused, which can halt the contract, temporarily suspending BoringVault deposits and withdrawals until reactivated by the Roles Authority contract. Additionally, it specifies a 3/5 Safe multisig payout address for collecting management and performance fees, which are currently set to zero.

Roles Authority:

4.2.2 Timelock Duration and Function

No Timelock is currently present on the contracts powering eBTC. However, the EtherFi team has assured us they’ll implement a 24-hour timelock on the admin contracts powering EtherFi contracts within the next few days.

4.2.3 Multisig Threshold / Signer identity

eBTC’s owner is the burn address. From all the information gathered so far, the eBTC ecosystem is controlled by this 4/6 Safe multisig, with the Roles Authority contract managing the key components of BoringVault.

Multisig Address: 0xCEA8039076E35a825854c5C2f85659430b06ec96

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, if applicable.

Price feed Recommendation

To be provided.

Overview

Chaos Labs supports listing eBTC on Aave V3’s Ethereum Main instance. Below is our analysis and initial risk parameter recommendations.

Technical Overview

eBTC is Ether.fi’s BTC-backed LRT, intended to generate dual yield through LBTC’s staking in Babylon, and further restaking in Eigen Layer, Symbiotic, and Karak. Currently, users are able to deposit LBTC, cbBTC, and WBTC, though WBTC carries a 0.4% deposit fee. The token, like LBTC, does not currently generate staking or restaking yield; instead, it receives a variety of points from associated protocols.

The token utilizes Veda’s BoringVault, which has previously been audited by 0xMacro and Cantina. One of the most critical factors to the asset’s listing on Aave is its withdrawal procedure; as stated in eBTC’s documentation, there is a 7-day withdrawal period, though “most withdrawals will complete well before this maximum window.”

As explained in Veda’s documentation, its Atomic Queue allows “users to request swaps between an ERC20 offer asset and an ERC20 want asset. Then, at any point in time until a deadline specified by the user, a solver can fulfill a batch of requests to take offer assets in exchange for want assets.” In other words, users who wish to withdraw are submitting limit asks that can be filled by a user entering the vault, meaning that withdrawals usually do not take the full withdrawal period.

The data below shows the duration for withdrawals to be processed after request, with the size of the circle representing the summed amount and the y-axis representing the number of withdrawals at each given hour interval.

The eBTC token contract currently holds 1,666 LBTC, 22 WBTC, 6 cbBTC, and tokens representing 4,250 LBTC deposited in Karak and 620 LBTC deposited in Symbiotic. Etherfi recently removed FBTC from the whitelisted collateral list. Hence, eBTC is not mintable against it anymore.

Market Cap and Liquidity

eBTC’s market cap has grown rapidly, reaching over $650M.

However, relative to this market cap, its on-chain liquidity is scarce. It has three main pools on Curve, paired with WBTC/LBTC, WBTC, and tBTC, respectively. The chart below shows the total BTC wrapper liquidity paired with eBTC on DEXes.

Given the withdrawal setup described in the technical section, this lack of DEX liquidity will limit our recommended supply cap and potential cap increases.

Volatility

The asset has demonstrated a somewhat unstable peg against WBTC, with a multi-day depeg at the end of November in both of its Curve pools. The asset fell to 0.989 WBTC in its eBTC/WBTC pool and in the BTC Fi pool, representing a 1.11% deviation from the underlying value. It has also previously demonstrated a slight upward deviation during the second half of October reaching 1.004 WBTC. While eBTC displayed peg instability, the pool quickly reverted to 1, showing mean reversion tendencies.

Relative to BTC, it has displayed a 30-day annualized volatility of 19.66%, up from its 14.71% since launch.

LTV, Liquidation Threshold, and Liquidation Bonus

Given the novelty of the asset coupled with the aggregated Oracle implementation assumptions described below, we recommend a 10% liquidation bonus, an LTV of 67%, and an LT of 72%, the former slightly higher and the latter two lower than other BTC wrappers listed on Aave.

Supply and Borrow Cap

Chaos Labs’ typical approach to setting initial supply caps involves setting the supply cap to 2x the liquidity available under the Liquidation Bonus. Following this approach, we recommend setting the supply cap to 80 eBTC. Given limited likely borrow use cases, we recommend setting the borrow cap to 10% of this value.

Interest Rate Curve

We anticipate limited initial demand for eBTC. As such, we recommend setting the UOptimal at 45% to reflect expected utilization rates. We recommend aligning its IR curve with cbBTC, ensuring the asset can be borrowed at lower utilization levels, but discouraging borrowing above UOptimal.

Oracle Configuration/Pricing

As displayed in the token’s AccountantWithRateProviders contract, eBTC’s current exchange rate relative to LBTC (set as the base asset) is 1. This is as expected; the underlying assets and various deposits do not yet earn yield. However, when yield is activated, it will be critical to use eBTC’s exchange rate to augment the oracle used for LBTC. The exchange rate of eBTC to LBTC can be obtained through the function getRateInQuote by providing the contract address of LBTC as quote. As such, this listing follows the conditions posed in the LBTC listing. We recommend using temporarily conservative parameters for the eBTC E-mode until an LBTC Proof of Reserves feed from Chainlink is available in q1 2025.

E-Mode

As displayed above, eBTC has, at times, traded at a slight discount relative to WBTC. However, with the pricing mechanism described in detail in the LBTC proposal, it is possible to mitigate liquidations of eBTC-collateralized WBTC debt positions that would otherwise occur because of these secondary market deviations. As previously mentioned, the lack of a Chainlink Proof of Reserve feed leads us to recommend conservative E-Mode parameters. Specifically, an LB of 3%, with an LTV and LT set to 83% and 85%, respectively.

Specification

Following the above analysis, we recommend the following parameter settings with the proposed oracle configuration:

Parameter Value
Network Ethereum
Isolation Mode No
Borrowable Yes
Collateral Enabled Yes
Supply Cap 80
Borrow Cap 8
Debt Ceiling -
LTV 67%
LT 72%
Liquidation Bonus 10%
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 eBTC WBTC
Collateral Yes No
Borrowable No Yes
Max LTV 83% -
Liquidation Threshold 85% -
Liquidation Bonus 3.0% -

CAPO Configuration

While EBTC does not currently generate yield, we recommend a somewhat conservative CAPO that can be adjusted once we are able to analyze its rewards distributions.

maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
7.50% monthly 14 days

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

We support the proposed parameters and plans regarding oracle choice.

2 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.

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

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

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

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

eBTC (Ether.fi) technical analysis


Summary

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

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Ether.fi 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

eBTC is a BTC liquid restaking token allowing users to earn staking and restaking yield across DeFI applications.
eBTC is backed by LBTC, wBTC, and cbBTC, restaked partially or totally in Eigen Layer, Symbiotic, and Karak, with rewards coming from Babylon.
eBTC uses as the core smart contract the BoringVault by Veda, but with the access control of the system majorly managed by Ether.fi itself.



Summarised architecture high-level


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

  • Mechanism to update the exchange rate of the asset with the underlying/s.
  • 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) and 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 main contracts are non-upgradable, using solmate Auth pattern for access control and LayerZero contracts for bridging.
  • The general admin of the system is an Authority contract controlled by a 5-day Timelock.





Contracts

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



eBTC (BoringVault)

The eBTC contract (BoringVault) is a simple contract holding the deposited assets through the Teller contract. It has functionalities for a Manager to send arbitrary calls (but pre-whitelisted) via the eBTC contract, mainly used for rebalancing strategies. It’s a non-upgradable contract with role-based access control via the Authority contract.


Permission Owner functions Criticality Risk
general owner: Authority → Timelock (0x70a6…cE3d) setAuthority, setRoleCapability, setPublicCapability, setUserRole, transferOwnership CRITICAL :green_circle:
OWNER_ROLE: Timelock (0x70a6…cE3d) setBeforeTransferHook, setAuthority, transferOwnership CRITICAL :green_circle:
MANAGER_ROLE: (Manager Contract) manage CRITICAL :green_circle:
MINTER_ROLE: Teller contract enter HIGH :green_circle:
BURNER_ROLE: Teller contract exit HIGH :green_circle:
  • Mint and Burn
    • minting eBTC happens via the enter(ERC20 token, amount, shareAmount) function which is only called by the Teller contract (MINTER_ROLE). This function transfers the token amount from the user and mints the shareAmount to the user.
    • The Teller contract (BURNER_ROLE) is the one that can burn eBTC via the exit(ERC20 token, amount, shareAmount) function. Internally, this function burns the shareAmount and transfers the amount of the token to the user.
  • Access Control
    • The OWNER_ROLE can set a before transfer hook contract via the setBeforeTransferHook(address) function. Currently, the hook is the Teller contract.
    • The MANAGER_ROLE (Manager Contract)) can rebalance the vault by making arbitrary calls via the eBTC contract by calling the manage(target, data, value) function. The manager contract whitelists the target data and value via a Merkle proofs system (detailed in the Manager section).
  • Tranfers (Before transfer hook)
    • eBTC has a share lock period implemented in the Teller contract that turns off temporary transfers if the currentShareLockPeriod is a value greater than zero. However, it is not currently set.
    • It also presents fromDenyList toDenyList operatorDenyList mappings that blocks transfers if the from, to or operator are on the deny list.

Teller (LayerZeroTellerWithRateLimiting)

The Teller contract is the main entrance for users to mint eBTC directly from the BoringVault. Withdrawals are processed in the Teller contract but managed via two helper contracts (Queue and Solver). The Teller contract uses the Accountant to calculate the exchange rate of the supported assets (currently LBTC, wBTC, and cbBTC). It has integrated with LayerZero to bridge eBTC through supported chains. It’s a non-upgradable contract with role-based access control via the Authority contract.

Permission Owner functions Criticality Risk
general owner: Authority → Timelock (0x70a6…cE3d) setAuthority, setRoleCapability, setPublicCapability, setUserRole, transferOwnership CRITICAL :green_circle:
OWNER_ROLE: Timelock (0x70a6…cE3d) setShareLockPeriod, updateAssetData HIGH :green_circle:
OWNER_ROLE (bridge functions) Timelock (0x70a6…cE3d) addChain, allowMessagesFromChain, allowMessagesToChain, setChainGasLimit HIGH :green_circle:
STRATEGIST_MULTISIG_ROLE: Safe 2-of-3 (0x41DF…a6ae) and Safe 2-of-3 (0x71E2…Bcd6) updateAssetData, refundDeposit HIGH :yellow_circle:
MULTISIG_ROLE: Safe 4-of-6, Timelock (0x70a6…cE3d) pause, unpause, removeChain, stopMessagesFromChain, stopMessagesToChain, setOutboundRateLimits, setInboundRateLimits, HIGH :green_circle:
SOLVER_ROLE: AtomicSolverV3, LBTCv, BoringSolver, BoringSolver(2), Liquid Bera BTC, LiquidBTC bulkDeposit, bulkWithdraw HIGH :green_circle:
pauser: pauser contract, Safe 4-of-6 pause, unpause HIGH :green_circle:
DENIER_ROLE (not assigned) denyAll, allowAll, denyFrom, allowFrom, denyTo, allowTo, denyOperator, allowOperator MEDIUM :green_circle:
  • Mint and Burn
    • Users can mint eBTC by calling the deposit(asset, amount) function. Internally, the function calculates the number of shares based on the amount of the asset deposited using the Accountant contract by calling the getRateInQuoteSafe(asset) function. The deposit reverts if the accountant does not support the asset. Finally, the Teller calls the enter(asset, amount) function in the Boring Vault, and the new eBTC shares are sent to the user.
    • Users can redeem eBTC in a 7-day window by first giving allowance to a helper AtomicQueue contract and calling the updateAtomicRequest(ERC20 in, ERC20 out, request) function where the users specify the token in (eBTC) and the token out (wBTC, cbBTC or LBTC) and a request struct containing the deadline for the withdrawal to be completed, a discount value, and the number of shares they want to redeem. After the period has passed, the redemption initiates in one transaction via the redeemSolve() function and is detailed in the steps below:
      1. A redeemSolve(ERC20 in, ERC20 out, address[] users) function is called in the helper AtomicSolver contract, batching users’ requests that have chosen the same token out.
      2. Internally, the AtomicSolver calls AtomicQueue.solve(ERC20 in, ERC20 out, address[] users), which transfers the token in from the users to the AtomicSolver and calls the finishSolve(ERC20 in, ERC20 out, totalAmount) fallback function.
      3. The finishSolve() fallback function then calls the Teller to redeem the shareAmount of eBTC via the bulkWithdraw(ERC20 out, uint256 shareAmount, address to) function.
      4. The amount of tokens out in terms of shares is calculated via the Accountant contract. Then the BoringVault.exit(ERC20 out, amount, shareAmount) is called which burns the shareAmount of eBTC and sends the amount to the AtomicQueue.
      5. The atomicQueue then finishes by sending the requested token amount to each user.
  • Exchange Rate
    • The exchange rate is calculated through the Accountant contract and will be detailed in the Accountant section.
  • Bridge
    • Users can natively bridge eBTC using the LayerZero bridge(shares, to, bridgeWildCard) function. The function first verifies whether the shares can be transferred and then calls the BoringVault.exit() function to burn the shares to the zero address. Then, the message data is built with the amount, the to address, and the bridgeWildCard, which contains the destination chain information. Users can back and forth their eBTC through Arbitrum, Base, Corn, and mainnet.
  • Access Control
    • The Teller has a role-based access control via the Authority contract, with the main roles being OWNER_ROLE, MULTISIG_ROLE, DENIER_ROLE, STRATEGIST_MULTISIG_ROLE, and SOLVER_ROLE.
    • The OWNER_ROLE can configure new chains in the bridge system by adding via the addChain() function, allowing sending and receiving messages from and to the chain via the allowMessagesFromChain() allowMessagesToChain() functions and set the gas limit for the respectively chain by calling setChainGasLimit().
    • The OWNER_ROLE and the STRATEGIST_MULTISIG_ROLE can add or remove assets via the updateAssetData(address, bool deposit, bool withdraw) function. It introduces some flexibility in the system, for example, allowing certain assets to be only deposited or withdrawn.
    • The OWNER_ROLE can set the lock period of eBTC via the setShareLockPeriod(period) function.
    • The OWNER_ROLE, and the DENIER_ROLE can add or remove users and operators in the blacklist of sending or receiving eBTC via the allowAll(), denyAll(), allowFrom(), denyFrom(), allowTo(), denyTo(), denyOperator(), allowOperator() functions.
    • The MULTISIG_ROLE can configure in and outbound rate limits for bridging via the setInboundRateLimits(config) and setOutboundRateLimits(config) functions.
    • The MULTISIG_ROLE can stop messages and remove chains via the stopMessagesFromChain(chainId), stopMessagesToChain(chainId), removeChain(chainId) functions.
    • The MULTISIG_ROLE can pause and unpause the Teller contract via the pause() and unpause() functions.
    • The SOLVER_ROLE (the helper contract) can redeem eBTC via the bulkWithdraw() function. It also can deposit assets and mint eBTC via the bulkDeposit() function, which works in a similar way of the normal deposit() function.

Accountant (AccountantWithRateProviders)

The Accountant contract provides the eBTC exchange rate to the Teller contract and quotes for the different assets that can be deposited. The exchange rate is updated with off-chain data, and the Accountant limits the range it can change. It’s a non-upgradable contract with role-based access control via the Authority contract.

Permission Owner functions Criticality Risk
general owner: Authority → Timelock (0x70a6…cE3d) setAuthority, setRoleCapability, setPublicCapability, setUserRole, transferOwnership CRITICAL :green_circle:
UPDATE_EXCHANGE_RATE_ROLE: (not assigned) updateExchangeRate CRITICAL :green_circle:
OWNER_ROLE: Timelock (0x70a6…cE3d) updateDelay, updateUpper, updateLower, updateManagementFee, updatePerformanceFee, updatePayoutAddress, setRateProviderData, resetHighwaterMark, HIGH :green_circle:
MULTISIG_ROLE: Safe 4-of-6 (0xCEA8…ec96) pause, unpause, HIGH :green_circle:
pauser: pauser contract pause, unpause, HIGH :green_circle:
  • Exchange Rate
    • The UPDATE_EXCHANGE_RATE_ROLE set the new exchange rate via the updateExchangeRate(newRate) function.
    • The exchange rate is calculated using off-chain data and includes safeguards that set minimum and maximum acceptable rates (currently a range of 10bps) and minimum update period (currently 6 hours). If the new rate falls outside the defined bounds, the Accountant contract will be paused instead of reverting the update transaction. This also halts new deposits and withdrawals because the Teller needs to call the getRateInQuoteSafe() function to calculate the shares being minted/burned, which will revert when the Accountant is paused.
    • When the exchange rate is updated with an acceptable value, a managementFee and performanceFee are calculated and accrued to the contract. Currently, the Accountant has zero fees for management and performance. The management fee is calculated based on the time elapsed since the last update using the minimum value of shares, while the performance fee is calculated if the new rate is greater than the previous high watermark (the last exchange rate). The boring vault can claim the fees via the claimFees() function.
  • Access Control
    • The OWNER_ROLE can set the rate provider data address of the assets being deposited and withdrawn from the eBTC system and if they should be pegged to the base exchange rate via the setRateProviderData(ERC20 asset, bool isPeggedToBase ,address rateProvider) function.
    • The OWNER_ROLE can configure the upper and lower bound of the acceptable exchange rate in bps via the updateUpper(value) and updateLower(value) functions.
    • The OWNER_ROLE can set the minimum time delay between the rate updates via the updateDelay(value) function.
    • The OWNER_ROLE can set the management and performance fees and the address to send them via the updateManagementFee(value), updatePerformanceFee(value) and updatePayoutAddress(address) functions.
    • The OWNER_ROLE can set the high watermark to the current exchange rate via the resetHighwaterMark() function.
    • The MULTISIG_ROLE can pause and unpause via the pause() and unpause() functions.

Manager (ManagerWithMerkleVerification)

The Manager contract is responsible for rebalancing the Boring vault via the manage() function, which allows the manager to send arbitrary calls. The contract has a role-based access control where the owner must first whitelist the call content of the strategist role (responsible for rebalancing). Then, when a rebalance is initiated, the content is verified via Merkle proofs. The Manager is a non-upgradable contract.

Permission Owner functions Criticality Risk
general owner: Authority → Timelock (0x70a6…cE3d) setAuthority, setRoleCapability, setPublicCapability, setUserRole, transferOwnership CRITICAL :green_circle:
OWNER_ROLE: Timelock (0x70a6…cE3d) setManageRoot CRITICAL :green_circle:
STRATEGIST_ROLE (not assigned) manageVaultWithMerkleVerification HIGH :green_circle:
MANAGER_INTERNAL_ROLE: Manager Contract manageVaultWithMerkleVerification HIGH :green_circle:
MICRO_MANAGER_ROLE: SymbioticUManager,Safe 2-of-3 (0x41DF…a6ae), Safe 2-of-3 (0x71E2…Bcd6) manageVaultWithMerkleVerification HIGH :yellow_circle:
MULTISIG_ROLE: Safe 4-of-6 (0xCEA8…ec96) pause, unpause HIGH :green_circle:
pauser: pauser contract pause, unpause, HIGH :green_circle:
  • Rebalance
    • Rebalances are shared between the MANAGER_INTERNAL_ROLE, STRATEGIST_ROLE and MICRO_MANAGER_ROLE via the manageVaultWithMerkleVerification(proofs[], sanitizers[], targets[], calldata[], values[]) function.
    • When the strategist initiates a rebalancing, first the Manager verifies if the calldata passed is allowed via the _verifyCallData(manageRoot, manageProof, sanitizer, target, value, targetData) function, where the manageRoot contains all the authorized operations the strategist (msg.sender) can do in the BoringVault and the sanitizer is the address used to obtain the arguments in the targetData (packedArgumentAddresses). With that in hands, the _verifyManageProof(manageRoot, manageProof, target, sanitizer, value, selector, packedArgumentAddresses) function is called to calculate the leaf of the current operation by hashing the parameters via keccak256 and verifying via the MerkleProofLib.verify(proof, root, leaf). If the proof is valid, the rebalancing can proceed.
    • The Manager contract integrates with Balancer flashLoan and must be initiated via the BoringVault to be valid (the strategist calls the manageVaultWithMerkleVerification(), and the BoringVault calls the Manager.flashLoan() function). The receiveFlashLoan() callback function is in the Manager contract to complete the operation. The Manager contract enforces that the totalSupply of eBTC cannot change after a rebalance completes.
  • Access control
    • The OWNER_ROLE can set the rebalancing data of each strategist via the setManageRoot(address, bytes manageRoot). The manageRoot (the root of the Merkle tree) is encoded data containing a address decodersAndSanitizer to call and extract packed address arguments from the calldata; a address target, bool valueIsNonZero indicating whether or not the value is non-zero, bytes 4 selector the function selector, and the argumentAddress is each allowed address argument in that call.
    • The MULTISIG_ROLE can pause and unpause via the pause() and unpause() functions.


Miscellaneous

  • The system has 3 security review by 0xMacro and Cantina, and can be found here. We still recommend adding some extra.
  • The staking/restaking rewards (Babylon, EigenLayer, and others) are still to be announced, which leaves the eBTC with an exchange rate of 1:1 for all BTC tokens deposited into the eBTC BoringVault.
  • Even if the exchange rate relies on off-chain data, internal security mechanisms such as pausing deposits and withdrawals can protect users’ funds during updates when values fall outside the defined range.
  • For precaution, we don’t think the asset should be enabled for borrowing, as both pricing and the threat model become relatively complex if so.


Asset Pricing

For LRTs, we have always recommended using a CAPO LRT, combining the exchange rate of the asset (eBTC in this case) to its underlying (BTC), and a Chainlink feed or underlying/USD (BTC/USD) in this case. eBTC is a bit more special than previous cases:

  • The eBTC Accountant contract technically considers the WBTC as “base” token
  • The majority of the eBTC underlying is staked, finally in the shape of BTC, for example via LBTC. That means that the “real” underlying of eBTC is BTC.
  • Currently, it is important to highlight that the rate of eBTC <> WBTC is 1:1 and lacks rewards because both staking and restaking rewards are not live yet. As soon the rewards start accruing, we’ll re-evaluate if the rate providers of the underlying assets are aligned with how they are priced on Aave (in this case, cbBTC and LBTC, which are priced to BTC on Aave).

Considering the previous, one option of pricing is to go the CAPO route, consuming the exchange rate from the Accountant contract plus a Chainlink BTC/USD feed. This way, if rewards are enabled in the future (no plans yet), eBTC on Aave will immediately be aware of them.
On the other hand, it is very consistent with the internal composition of eBTC to simply use BTC/USD, the same as LBTC on Aave. This way, potentially if rewards are enabled Aave would not be aware of them, but with the asset listed as collateral only, that is not a big problem.

In practise, both approaches are pretty much acceptable, but we will sync with both @ChaosLabs and @LlamaRisk to agree on one for the AIP stage.



Conclusion

We think eBTC doesn’t have any problem in terms of integration with Aave, and aside from the necessary proposal payload creation, there is no major technical blocker for listing.

2 Likes

After additional discussion with BGD and a review of Aave’s LBTC onboarding in January, we are amending a couple of factors in the eBTC onboarding—namely, the Borrow Cap and the Price Oracle.

Oracle Configuration/Pricing

Given that the eBTC Accountant’s internal rate is currently set at 1 in the absence of yield, two pricing strategies present themselves:

  1. Using Chainlink’s BTC/USD price feed (similarly to LBTC)
  2. Using a CAPO adapter that multiplies Chainlink’s BTC/USD feed with eBTC’s internal exchange rate, with maxYearlyRatioGrowthPercent set to 0%

Although precedent has been set with LBTC to price solely using the BTC/USD price feed, we believe that the CAPO solution should be privileged for handling assets in this category (early-stage LST/LRT that have not yet begun earning yield).

This solution makes it easier to adjust the cap via Stewards once yield is activated. For all collateral types handled in this way—including LBTC and eBTC—it is imperative for service providers to monitor developments in the LST/LRT protocols and be prepared to implement CAPO once their internal RateProvider becomes active (i.e., when the protocol begins earning and distributing yield).

Borrow Cap

Failure to implement/parametetize CAPO in a timely manner may result in Aave underpricing eBTC. This is more a concern when the asset is borrowable. Given that eBTC is expected to be used primarily as collateral in looping strategies anyways, in this early stage it is more reasonable to make eBTC unborrowable. This is also a precedent set by LBTC, which was initially onboarded with an 80 LBTC borrow cap and subsequently reduced to 1 LBTC.

Hello, this proposal is now ready to move forward to AIP stage.

@ChaosLabs @LlamaRisk requesting an update to risk parameters suggestions as asset is more mature, current parameters are not suitable and it will reach cap in a minute hurting potential growth.

2 Likes

Update (March 26th, 2025): We’re endorsing parameters set forward by @ChaosLabs (750 supply cap, eBTC non-borrowable, and eMode params)

LlamaRisk recommends changing eBTC’s initial supply cap from 80 to 300 (and borrow cap to 30 from 12), given significant improvements in market liquidity. While good inroads have already been made, deeper liquidity and greater LP venue diversity and fragmentation enable us to recommend a higher supply / borrow cap.

eBTC market update

Source: eBTC/WBTC trade at ±10% price impact, Paraswap, March 25th 2025

The market capitalization of eBTC is significantly greater than at past review, with some 3,310 wrapped or staked BTC currently held in the vault. Liquidity for this asset is substantially improved, with a $14.5M trade resulting in ±10% price impact, the recommended liquidation bonus for this asset.
This liquidity is largely held in 4 liquidity pools:

In short, all DEX liquidity is protocol-supplied and is controlled by a few entities. This increases the likelihood that DEX liquidity could dry up rapidly. Greater diversity in LP holders for this pool and a greater number of liquidity venues would drastically reduce this risk. It is important to note that all eBTC positions are paired with eBTC collateral, so should one of these assets suffer an incident, it may result in difficulty in liquidating distressed positions profitably.

Aave V3 Specific Parameters

Endorsing parameters set forward by @ChaosLabs

2 Likes

Given the significantly increased paired on-chain liquidity across various venues relative to the available on-chain supply—since the initial recommendation, as illustrated below—we recommend raising both supply and borrow caps to align with the improved liquidity conditions.

From a growth standpoint, there is substantial external demand for leveraging eBTC. Therefore, rather than immediately relying on the risk steward for incremental increases stemming from correlated debt positions, we propose an initial supply cap of 750 eBTC. This approach accounts for expected demand while maintaining directional conservatism appropriate for an asset of this nature.

Conversely, as outlined in this LRT cap reduction proposal, we recommend launching eBTC as a non-borrowable asset, similar to the approach taken with LBTC. This is based on the limited expected borrow demand and the advantages of maintaining simplicity from both a risk and technical security perspective.

Updated Specification

Parameter Value
Network Ethereum
Isolation Mode No
Borrowable No
Collateral Enabled Yes
Supply Cap 750
Borrow Cap -
Debt Ceiling -
LTV 67%
LT 72%
Liquidation Bonus 10%
Liquidation Protocol Fee 10%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -

E-mode

Parameter Value Value
Asset eBTC WBTC
Collateral Yes No
Borrowable No Yes
Max LTV 83% -
Liquidation Threshold 85% -
Liquidation Bonus 3.0% -

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

Copyright

Copyright and related rights waived via CC0

1 Like