Summary
An analysis of the eBTC redemption mechanism and parameter recommendations for activation.
Abstract
The eBTC redemptions mechanism provides a backstop of liquidity and price support for the eBTC token in cases where it is trading significantly below target price, by allowing eBTC holders to exchange their tokens for collateral from the lowest collateralized CDPs subject to a protocol fee. Badger launched eBTC with redemptions turned off, in order to de-risk using CDPs during the potentially volatile launch period. However, we have seen a healthy baseline of CDP usage and DEX liquidity develop for the eBTC token, which reduces the risk of price volatility causing unnecessary redemptions.
Enabling eBTC redemptions can provide a few key benefits for the protocol and token usability. Providing an additional source of below-peg liquidity will allow the Badger treasury to tighten the range of WBTC liquidity provided on Uniswap, improving capital efficiency and market depth. Additionally, by creating strong buy side support for eBTC, it may be possible to integrate eBTC as a collateral asset in 3rd party lending protocols while using a standard BTC price feed, instead of a specialized eBTC feed. This will reduce the cost and complexity for integrations while mitigating potential oracle and market manipulation risks.
Below we analyze the redemptions mechanism, including risk and UX considerations, and recommend parameters for activation.
Redemption Mechanism Overview
The eBTC protocol redemption mechanism works similarly to LUSD redemptions. Users can permissionlessly exchange their tokens for collateral from the least collateralized CDP, less a redemption fee that is charged by the protocol. This redemption process will only be profitable in cases where the token is trading far enough below peg where the price divergence is greater than the redemption fee.
The redemption fee is made up of a fixed component (called the FeeFloor) and variable component (called the BaseRate). The FeeFloor is set by default to 1%, and is adjustable via the limited governance mechanism. The BaseRate is set via a formula where the fee increases with recent redemptions volume, and decays over time since the last redemption. The parameters for the BaseRate formula determining volume sensitivity and decay factor are also configurable via limited governance. Relevant formulas are shown below.
RedemptionFee = BaseRate + FeeFloor
The base rate’s increase due to recent redemption volume is shown here, with α denoting the rate of fee increase, while n / m refers to the share of eBTC redeemed as a share of total eBTC supply.
b(t) = b(t−1) + α × (n / m)
Base rate decline is calculated using a decay factor δ and the time since last redemptions, essentially creating a half life for the BaseRate to approach zero over time.
b(t) = b(t−1) × δ ^ (Δt)
Generally, the FeeFloor parameter will determine the beginning of price support from redemptions, while the BaseRate parameters will determine how much the price will be able to fall below this level and the speed of redemption activity. CDP users will tend to prefer less aggressive redemptions mechanisms (higher FeeFloor, higher α, and slower decay), while eBTC holders and collateral integrations will prefer a stronger redemption feature to limit downside price volatility.
Risk and UX Considerations
Redemption parameters should be set carefully to avoid any negative impacts on risk or UX for the core eBTC protocol, as well as potential third party integrations.
Primary considerations for setting redemption parameters include:
- Protecting CDPs from adverse redemptions due to standard oracle latency and deviations
- Ensuring safety of third party collateral integrations for eBTC
- Avoiding griefing attacks against CDP users via the redemption mechanism
- Ensure that all of the above conditions hold even in case of stETH depegs
Oracle Latency
eBTC currently uses a composite of the Chainlink ETHUSD and BTCUSD price feeds as the primary oracle. Each feed features a 0.5% deviation threshold, so updates will be triggered whenever the price moves up to 1% from the last reported price. Additionally, there is the option of adding a stETHETH price feed to the composition in the event stETH begins to trade off peg, with an additional 0.5% deviation threshold (for a total of 1.5% maximum deviation if this is added). To prevent CDPs from being redeemed against at an unfavorable price that causes losses to CDP users, the redemption fee floor should be at least as large as the oracle deviation threshold, and preferably a bit larger to account for the possibility of laggy oracle updates.
While eBTC currently does not have a secondary oracle set up, adding one would provide a useful layer of redundancy for any possible Chainlink issues. It is expected that the deviation threshold for the secondary oracle will be set higher to minimize operating costs, most likely to 2%. So ideally the fee floor should be set to at least 2.5% to prevent CDP collateral from being redeemed below fair value.
Collateral Integrations
Allowing eBTC to be used as collateral on lending markets will provide a valuable demand driver and help boost protocol growth. However, this would typically require a bespoke eBTC price feed, which involves considerable operating costs and may also be vulnerable to price manipulation attacks due to eBTC’s relatively small size and limited number of exchange integrations. However, if we can use redemptions to ensure that the price of eBTC never falls too far below BTC, then it is possible to pursue lending integrations using a standard BTC price feed instead.
In general, as long as a lending pool’s liquidation incentive is greater than the maximum expected eBTC discount vs BTC, liquidations will still be profitable even when eBTC trades at a discount and the pool can safely use a BTC price feed. We consider Morpho’s liquidation engine for the rest of this section, as it is the most likely target for initial lending integrations.
Morpho Blue pools can be set up with one of eight DAO approved liquidation loan to value ratios (LLTV); 38.5%, 62.5%, 77%, 86%, 91.5%, 94.5%, 96.5%, and 98%. The liquidation incentive factor (LIF) is automatically set to be proportional to the LLTV via the following formula:
LIF = min(M, 1 / (β ∗ LLTV + (1 − β) ) )
Where β = 0.3 and M = 1.15
This yields the following LIF values per LLTV.
Taking the inverse of these values, we can calculate the maximum price discount for collateral value vs oracle price where liquidations will still be profitable (and by extension, where the market remains safe from bad debt).
From the above data, we can see that the maximum acceptable discount for eBTC/BTC price ratio is highly dependent on the LLTV used. For even low leverage use cases with LLTVs of 38.5% or 62.5%, the eBTC price must not be allowed to fall below 0.9 to ensure adequate liquidation safety. The 77% LLTV pool, which may be useful for borrowing uncorrelated assets including stablecoins and other crypto, requires a eBTC price floor above ~0.94 to operate safely, while the 86% LLTV pool which could be used for looping against other BTC tokens, requires a price floor of roughly ~0.965. LLTVs of 91.5% or above may not be achievable at present due to the minimum redemption fee floor required to address oracle deviation thresholds and latency.
Given the recommended fee floor of 2.5% to address oracle deviations, we want to ensure that any necessary redemptions to support collateral liquidations can take place with not more than an additional 1% base fee for correlated assets, or 3.5% base fee for uncorrelated assets. If we conservatively assume that as much as 20% of the eBTC supply could be redeemed in a mass liquidation event, the redemption fee alpha parameter should be set at 0.05 or lower to meet the 1% base fee boundary condition. Note that this allows for significant additional buffers for the 3.5% base fee threshold, where as much as 70% of eBTC could be redeemed at once without threatening liquidation safety. Setting a redemption fee decay factor of 0.5 will ensure that the base fee component of redemptions fees would decline at a rate of 75% per day (~5.6% per hour), which should allow for a very high throughput of redemptions activity when price falls below the fee floor.
We must also consider the impact that potential price discounts have on effective LLTVs (calculating the ratio of debt to fair market value of eBTC collateral, rather than BTC oracle priced value of collateral). Assuming we want to allow for pool LLTVs up to 86%, this means that eBTC may trade as low as 0.965 or 0.94 without violating our boundary conditions. So, we’d divide the pool LLTV by these price values to calculate the pessimistic LLTV based on the worst case fair market value of collateral. We see that the 77% LLTV pool remains firmly within the normal range of defi collateral ratios, while the 86% LLTV pool may approach higher thresholds that are typically reserved only for correlated assets. As such, we would recommend to launch uncorrelated pairs (eg borrowing stablecoins or other cryptos against eBTC) at a 77% LLTV, and use the 86% LLTV pool for correlated pairs where eBTC is used to borrow other BTC tokens.
Griefing Attacks
One possible risk of redemptions is the risk of a griefing attack targeting CDP users. In this hypothetical attack, a user would acquire a significant quantity of eBTC either from minting or purchasing on the secondary market, and then redeem it with the intent of forcefully closing CDP users’ positions. Given a minimum necessary redemption fee floor of ~2.5% based on the oracle deviation considerations discussed above, this attack would be fairly expensive to execute. And because eBTC does not charge CDP users a minting fee (a key difference from similar models like LUSD), there is no direct cost to end users if they are forced to manually reopen their CDP after redemption. Impact to CDP users would be limited to UX friction, gas costs, and possibility of adverse price movements between redemption and when they reopen their positions. Based on the high cost of attack and limited potential impact to end users, we believe this risk is sufficiently mitigated by the redemption fee floor parameter.
stETH Price Divergence
The eBTC protocol currently uses a ETHBTC price feed for managing redemptions and CDP liquidations. While stETH price has been extremely stable since ETH unstaking became available, it is possible that a market crash could cause a significant backlog in the unstaking queue and result in stETH trading at a discount. If this happens, the effective price guaranteed by redemptions will fall proportionally, as the amount of collateral redeemed will be calculated based on ETHBTC price but users will receive stETH instead of ETH.
There are a few factors that help limit the impact of potential stETH price divergence. First, we expect that incidents of stETH falling below peg will correspond to significant drawdowns in the ETHBTC price ratio (due to general stress and loss of confidence within the Ethereum defi ecosystem). This will tend to create buying pressure for eBTC from liquidations or users manually reducing leverage of their CDPs, so stETH discounts are less likely to occur at the same time as eBTC redemptions activity where the market relies on this form of support for eBTC price. And beyond this, the above redemption parameters already bake in a significant buffer for liquidation safety based on the large spread between the fee floor and maximum safe discount for external lending integrations. Assuming 20% of eBTC is redeemed, stETH could still trade at as much as a 3-3.5% discount before liquidations in the 77% LLTV Morpho Blue pool would be at risk of unprofitability. And lastly, Badger has the capability of adding stETHETH price data to the aggregate feed for CDP redemptions and liquidations with relatively short notice, which would ensure that stETH discounts don’t prevent timely liquidations in the core eBTC CDP protocol or on external collateral integrations.
Parameter Recommendations
Based on the above analysis, we recommend enabling redemptions for the eBTC protocol with the following parameters.
- Redemption Fee Floor: 2.5%
- Redemption Fee Alpha (α): 0.05
- Redemption Fee Decay Factor (δ): 0.5
At present, we recommend to leave the existing below peg protocol owned liquidity unchanged. This will provide an opportunity for users to arbitrage redemptions against liquidity within the DEX LP pool, which will ensure that liquidations can be processed efficiently even if liquidator bot operators have not directly integrated eBTC redemptions as a liquidity source. Over time the below peg ranges may be able to be tightened somewhat based on observed liquidator bot behaviors, integration of redemptions into DEX aggregators, and observed eBTC peg conditions.