eBTC Launch Planning, Peg Management, and Monetary Policy

Summary

This post lays out plans for initial eBTC launch, as well as proposed peg management and monetary policy strategies. Public launch preparations and predictable, rules-based frameworks for peg management enhance the effectiveness of monetary policy levers by improving confidence among market participants.

Authors: @BA_Labs, @Steakhouse, and Badger contributors

Contents

  • Capitalization of eBTC Surplus
  • eBTC Protocol Launch
    • Initial Parameters
    • Protocol Owned Liquidity
  • Monetary Policy Framework
    • eBTC Bitcoin Asset Liability Management Council (BALCO)
    • Protocol Yield Share (PYS) Adjustment
    • Trading and Market Operations
    • Incentives
    • Redemption Parameters
    • Post-launch Stabilization
  • Incident Response
    • Technical Faults
    • Oracle Faults
    • Failed Liquidations
  • Conclusion
  • License and Disclaimer

Capitalization of eBTC Surplus

TL;DR: Request the Treasury council allocate capital from the BadgerDAO treasury to the eBTC protocol surplus (contingent on Treasury Council approval)

The BadgerDAO treasury currently holds over $20 million in assets, including both BADGER tokens as well as a variety of hard assets such as rETH, WBTC, and stablecoins. We will be proposing to the BadgerDAO treasury council to allocate capital to the protocol surplus prior to mainnet launch. This will include treasury council controlled positions for providing liquidity, stabilizing the peg through arbitrage trading, and providing a risk backstop against potential losses. BTC denominated assets can be used directly, while ETH denominated assets can be used to create a protocol owned CDP and mint eBTC for approved uses.

eBTC Protocol Launch

TL;DR: Launch eBTC protocol with redemptions turned off, 50% protocol yield share, and protocol owned liquidity split across narrow and broad price ranges on the Uniswap v3 eBTC/WBTC pool

Initial Parameters

Many parameters for the eBTC CDP protocol are immutable, but there are several parameters that can be changed under the protocol’s limited governance mechanisms as described in the eBTC Purple Paper. Governable parameters include the protocol yield share (PYS), redemption activation and fee floor, alpha, and decay, flash loan activation and fees, and choice of primary and secondary oracles.

We propose the following initial state for governable parameters:

  • Protocol yield share: 50%
  • Redemptions: not active
  • Flash loans: active
    • Flash loan fee: 0.1%
  • Primary oracle: Chainlink (composite of ETH/BTC and stETH/ETH)
  • Secondary oracle: None (will be added after launch)

Protocol yield share is proposed to be set to 50% at launch, which is symmetrically positioned between the upper (100%) and lower (0%) bounds for this parameter. This will allow the protocol to quickly dial in on an appropriate PYS level that supports a stable market equilibrium. While a lower or even 0% PYS was considered to help drive initial growth, starting with a non-zero PYS is preferred as this will help gauge organic PMF and demand to use the protocol without excessively subsidizing minting with 0% fees.

Launching without redemptions active helps derisk participation for early eBTC minters, who otherwise might see their positions immediately redeemed due to market volatility. The ability to turn on redemptions if necessary should help build confidence among eBTC holders that any downside price deviations of eBTC vs BTC will be limited over the medium term.

Flash loans help improve efficiency for liquidators so it makes sense to have them active upon launch. A low 0.1% fee can drive incremental revenue without impacting utility for liquidations.

As the most broadly used oracle system, Chainlink is a natural fit for use as the primary oracle at launch. Secondary oracles will not be used immediately at launch, but there is active work being done to identify the best options to use for secondary oracles such as Pyth, Chronicle, Redstone, or on-chain TWAPs.

Protocol Owned Liquidity

We propose using Uniswap v3 as eBTC’s primary liquidity venue, due to the efficiency and flexibility offered by concentrated liquidity, as well as Uniswap’s status as the most broadly used DEX protocol. As the market cap of eBTC increases the goal will be to scale protocol owned liquidity while prioritizing the use of surplus capital on the balance sheet to backstop the peg at certain levels as described in the Figure 2 table below.

Use of the 0.05% fee tier strikes the ideal balance between ensuring adequate fee revenue for liquidity providers, minimizing trading costs for eBTC users, and avoiding the excess gas costs associated with 0.01% fee tier pools (where swaps could cross up to 10 times as many individual ticks for a given trade size).

Liquidity will be deployed across four price ranges to create a symmetrical, concentrated liquidity pool that supports both low slippage for active trading and backstop liquidity in stressed conditions or during depegs. Proposed initial liquidity ranges are as follows:

  • 0.925-0.99 eBTC/WBTC: 10% of funds allocated to liquidity provision
  • 0.99-1 eBTC/WBTC: 40% of funds allocated to liquidity provision
  • 1-1.01 eBTC/WBTC: 40% of funds allocated to liquidity provision
  • 1.01-1.08 eBTC/WBTC: 10% of funds allocated to liquidity provision

Protocool owned liquidity can be further adjusted as needed based on observed market conditions. As the protocol matures, the total liquidity requirements are expected to scale up and either additional POL or incentives may be used to achieve sufficient liquidity depth. Adjustment to ranges will also be considered based on realized peg volatility.

Monetary Policy Framework

TL;DR: eBTC will implement a predictable rules-based monetary policy framework overseen by the Bitcoin Asset Liability Management Council (BALCO), using available levers including parameter adjustment, market operations, and incentives to maintain healthy liquidity and a stable peg

eBTC Bitcoin Asset Liability Management Council (BALCO)

The eBTC asset liability management council (BALCO) will be led by contributors from @BA_Labs and @Steakhouse. BALCO will hold regular meetings to assess protocol and market conditions and recommend monetary policy changes publically via the Badger forum. The BALCO as a council will decide on protocol parameter changes but doesn’t execute these changes via a multisig. Instead the eBTC technical operations arm will be taking these recommendations and executing them with a multisig that’s further secured by a timelock. The BALCO will also be making recommendations to the BadgerDAO treasury council on adjustments to treasury controlled positions to help with protocol stability that they can execute through the existing treasury council multisig framework.

The long-term aim of BALCO is to eventually encode or automate these ALM rules over time. Using a rules based process for monetary policy will encourage market participants to take proactive steps (buying, selling, minting, or repaying eBTC) to return eBTC to peg based on credible expectations of future BALCO parameter changes.

Protocol Yield Share (PYS) Adjustment

In addition to driving revenue, the protocol yield share (PYS) is a key monetary policy lever for managing supply of eBTC. Lowering the PYS encourages increased minting through CDPs to increase supply, while raising PYS does the opposite, discouraging new minting and driving repayment of existing CDPs. PYS will be adjusted dynamically through the periodic BALCO review and proposal process to help keep supply of eBTC in line with market demand, thereby stabilizing the peg.

BALCO will adopt a rules based process for PYS adjustment that looks at prior period peg stability and price behavior, and then adjusts PYS up or down based on eBTC’s average realized distance from peg. Greater price divergence will result in a higher rate of change to PYS, which should help speed up the process of balancing supply and demand. While the specific parameter adjustment framework is expected to evolve after launch based on observed market dynamics, over time we’ll seek to dial in on a robust and stable policy which can be fully automated.

Trading and Market Operations

In addition to the protocol owned liquidity, which is expected to be managed in passive ranges with only occasional adjustments, through BadgerDAO treasury owned positions the protocol will also have additional surplus capital on hand which can be used to support the peg if supply and demand are imbalanced. If the price of eBTC is persistently above peg, inventory of eBTC held by the protocol can be sold at a premium and stETH reserves can be used to collateralize the protocols CDP to facilitate the minting and sale of additional eBTC. If eBTC price falls below peg, WBTC held by the protocol can be used to purchase eBTC at a discounted price.

In either case, these arbitrage activities will not only help stabilize the peg and improve market confidence, but may also result in realizing profit for the protocol through opportunistically buying eBTC low and selling high. The thresholds and pace of market operations in the immediate post launch period are described in Figure 2 below.

Incentives

BadgerDAO has allocated a portion of tokens to be used for bootstrapping eBTC liquidity, and other partners may also provide additional funds to be used for incentives. While the Badger allocated funds will only be used if necessary, any funds provided by partners will form an integral part of the launch bootstrapping process.

Incentives will primarily be used to encourage users minting eBTC through CDPs, as they directly drive protocol revenue through the PYS. Depending on the state of the eBTC peg (whether over or under peg), minting incentives can also be augmented with additional strategies to achieve desired behavior.

When under peg, incentives for LPing within a tight range on the Uniswap v3 eBTC/WBTC pool can be used to drive additional demand. If eBTC is over peg, minting incentives can be adjusted to favor users who both mint eBTC and provide liquidity to the Uniswap v3 pool, which effectively incentivizes CDP users to sell some of their minted eBTC rather than holding it in their wallet.

Redemptions Parameters

Redemption will be disabled at launch to help de-risk participation for CDP users during the initial phases which may see heightened eBTC price volatility. It is our goal to leave redemptions off indefinitely and use other protocol mechanisms to balance supply and demand, as redemptions can significantly impact user experience (as witnessed recently with Liquity, where troves are being redeemed as high as 400% collateral ratio). Instead, situations where eBTC is trading below peg due to excessive supply vs demand will be addressed primarily with increases in the PYS (disincentivizing minting).

Redemptions will primarily be used as a credible threat to avoid severe depegs to the downside; if eBTC trades significantly below peg, then redemptions can be turned on with conservative parameters (high fee floor, high fee alpha, and slow decay) to put a hard floor under the eBTC price and encourage minters to voluntarily buy back eBTC to close their position.

Post-launch Stabilization

It is expected that the immediate post-launch period could see heightened volatility and rapid changes in market conditions. To adequately address this and ensure the prompt stabilization of the protocol, the eBTC BALCO will meet at least weekly during the first month of protocol operations, and will recommend accelerated parameter changes to achieve equilibrium as quickly as possible.

Figure 1: Launch Timeline (not to scale)

Figure 2: Dynamic Peg Stability Strategy

The above table in Figure 2 shows expected parameter changes in response to various peg conditions. This framework uses the range of tools available to BALCO and eBTC governance including PYS adjustment, incentives, use of protocol owned surplus capital, and activation of various features such as redemptions. The above actions are subject to revision based on market conditions, but we expect this plan of action should provide sufficient support to maintain a stable eBTC peg at launch. After the first month, assuming the peg has achieved consistent stability, we will move towards a more measured and gradual approach to parameter adjustment recommendations.

Incident Response

TL;DR: eBTC faces several risks as a new protocol, and BadgerDAO contributors and community should be prepared with incident response plans in case an adverse event occurs after launch

Technical Faults

While significant efforts have been made to ensure the eBTC protocol is robust and free from technical faults, the possibility of undiscovered bugs cannot be ruled out definitively. Smart contract systems achieve lindyness through time in production with funds secured.

In the event that eBTC faces a technical fault in production, Badger technical contributors will form a war room for incident response, looping in any necessary contributors from the BALCO as well as outside security professionals where appropriate. Information will be shared with users and the broader community when feasible.

If conditions causing the fault can be addressed (for example turning off flash loans), these actions will be taken as soon as possible. However, many parts of the protocol are immutable so it may not be possible to actively address certain possible faults. Certain other actions such as disabling front end UIs will be considered if this could help prevent losses.

Oracle Faults

At launch, eBTC will use Chainlink feeds to create an aggregated stETH/BTC price feed. A secondary oracle protocol will be added after launch, which will become active if the primary oracle becomes unresponsive or falls outside of certain validity thresholds.

Badger contributors will continuously monitor the primary and backup oracles and propose adjustments as needed to ensure that the chosen providers meet the necessary standards for reliability, accuracy, and resistance to manipulation. For example, if an on-chain DEX TWAP oracle is used as a backup, liquidity levels will be monitored to ensure the oracle remains sufficiently resilient given the value at risk within eBTC.

In addition to liveness failures, oracles may also provide incorrect prices, potentially resulting in erroneous liquidations (if price is too low) or undercollateralized eBTC (if price is too high). Each of these situations may lead to liquidations settling for under 100% of owed eBTC and bad debt redistribution to other CDPs. BadgerDAO’s protocol owned CDP will absorb a share of any bad debt redistribution, reducing impact on other users. Additional remedial measures can be considered on a case by case basis.

Failed Liquidations

Severe market volatility or stressed eBTC liquidity conditions may result in liquidations returning less than 100% of CDP’s outstanding debt. This will then result in bad debt being redistributed to other CDP users. Badger DAO’s protocol owned CDP will absorb a share of any bad debt redistribution, reducing impact on other users.

In particular, cases where the price of eBTC is trading above 1:1 to BTC reduce the profitability of liquidating positions, and may make the incidence of unsuccessful liquidations and bad debt redistribution more likely. Specifically, if the ICR of a CDP is lower than the eBTC/BTC price ratio, then liquidator profit will be negative, indicating that liquidations could be delayed until eBTC price normalizes at which point the CDP’s ICR may have deteriorated further. BALCO’s monetary policy and peg management strategies described above will be employed to address any over-peg price deviations and mitigate this risk.

Conclusion

The above scenario planning and monetary policy mechanisms should help eBTC have a stable and successful launch. By focusing on maintaining a strong peg with deep liquidity, we’ll build user trust among both CDP users and eBTC token holders, which is a prerequisite for achieving robust growth and financial performance over the medium term. While new project launches inevitably require agility and adaptation on the fly, protocol stakeholders should feel confident in eBTC’s mechanism design and governance.

License and Disclaimer

Copyright and related rights waived via CC0.

This content is provided on an “as is” basis without warranty of any kind, either express or implied, including, but not limited to, implied warranties of merchantability, noninfringement, and fitness for a particular purpose. Authors do not warrant the accuracy of the information in the content. Authors shall not be liable for any claims or damages arising from or related to any party’s use of the content, including any claims for losses or lost profits, or other incidental, special, consequential, or statutory damages in connection with the content. This content is not intended or offered as advice of any kind, including investment, financial, legal, regulatory, or tax advice, and readers should seek their own professional advice where appropriate. This content is not an offer, solicitation, or recommendation to purchase, sell, or engage with any asset or product, and any mention of assets or products is purely for illustrative purposes. Users acknowledge and agree that their use of the content is solely at their own risk.

References

5 Likes

thanks for putting this together and sharing it here! it has been a while since we have seen anything concerning the future plans of ebtc.

some feedback :slight_smile:

capitalisation

badgerdao currently holds not $20m but $30m in assets. when not including non circulating/native $badger it is $15m. where did you source $20m from?

pol

you propose univ3 as the protocol to use for ebtc’s primary liquidity. you also mention the importance of incentivisation of liq. what platform do you see being used for such incentives? univ3 does not have the same native gauge system that for example curve or balancer have. a builtin robust (onchain) gauge system might help users find this yield faster, and aid in some the automation processes you describe.

i assume you decided on univ3 due to its concentrated liq feature. how does the performance of univ3 compare to curve v2 in your opinion? i thought they were pretty similar. what other platforms did you consider and how did you get to uniswap?

the historical peg for lusd has deviated much more than .99-1.01. does putting only 20% of pol outside those ranges provide enough support? personally i would suggest putting 80% of the depth in the .95-1.05 range or something, or at least widening it a bit more than ±1% peg.

balco

can you share what the governance process for balco making these decisions looks like? how does balco differ from the ebtc multisig? and while on the topic, what does that multisig look like and how is the badgerdao and/or how are badger tokens involved there?

how many tokens? where has this been decided?

protocol yield share

maybe a bit of a tangent, but where does this yield share go exactly? the purple paper mentions no parameter that determines the destination of the yield. so it must be hardcoded?

redemptions

i believe redemptions are an important feature of ebtc and of stablecoins in general. it vastly increases the trust one can put in a token. is an indefinite exclusion of the feature really necessary?

i have strong doubts about the adjustment of the pys being the end all solution to solve situations in which ebtc is under peg. is changing pys from 50% to 75% really going to affect the market enough for ebtc price to make the necessary shifts? it might work for a bit, or for a while, but eventually pys will reach a state where it is maxed out imo.

your emergency plan shows turning redemptions on at .9. does it ever get turned off again? at what point?

1 Like

Hi @gosuto, thanks for your comments!

I’ll try to address each item below.

Capitalization

I think the $20M amount was from an earlier draft and I had neglected to update it with current valuations before posting. Number was based on the assets held in the Badger treasury multisig. Thanks for correction!

Protocol Owned Liquidity

Choice of DEX

Uniswap was selected for a few reasons.

Uniswap has the highest adoption of any DEX, if a user goes directly to a DEX (rather than through an aggregator) to trade it is overwhelmingly likely to be on Uniswap. So having liquidity on Uniswap offers a bit better utility for end users versus liquidity on Balancer, Curve, or another alternative.

Uniswap v3’s concentrated liquidity ranges also offer a higher degree of control versus competitors. For example, due to the minimum collateral ratio of eBTC, any liquidity covering price ranges over ~1.1 eBTC/WBTC would remain unused (if price is above this level, there is a risk free arbitrage to mint and sell eBTC from CDPs). Balancer and Curve offer concentrated liquidity/stableswaps, but some amount of liquidity would continue to be provided into this idle range. Uniswap also offers the ability to weight liquidity unevenly above versus below peg, which isn’t being recommended for launch but may become useful depending on how eBTC peg conditions turn out.

Lastly, engagement with bribe/incentive economies of Balancer, Curve, or others introduces some additional complexity for managing bribes and analyzing performance. In many cases it may be possible to achieve higher incentives received to the pool versus bribes paid, but the potential marginal benefit was judged to be insufficient to justify using these platforms over Uniswap.

Range Selection

For range selection, we proposed to put most of the passive protocol owned liquidity into the 0.99-1.01 range to support adequate market depth for day to day use. Widening the primary range would result in relatively more slippage for users opening/closing CDPs which would increase the effective all-in cost of using the protocol. To backstop the peg in the event it trades farther outside of the 0.99-1.01 price range, we proposed an active liquidity strategy where the treasury would buy eBTC below peg or sell above peg, based on certain price thresholds. This can serve as a more capital efficient stabilization mechanism while giving the treasury an opportunity to earn revenue from arbitrage.

The liquidity strategy isn’t static though, and if we notice prices frequently trading out of range then we can recommend the treasury multisig to widen the LP ranges.

BALCO

Governance

BALCO will be a purely advisory body, so won’t be directly executing any parameter or treasury management changes ourselves. Instead, we will review data/market conditions and then make public recommendations to the Treasury Council (for treasury management or POL related changes) or another execution body (for eBTC parameter changes).

We plan to meet on a weekly basis to review collected market data and agree on recommendations via internal consensus, before publishing our findings and recommendations publicly for community review.

Incentives

There was a previous snapshot vote that allocated some tokens towards incentivization (see here). However these will only be recommended to be used for incentives if necessary to meet the protocol’s liquidity needs. Potential for incentives provided by external partners will be more central to the launch planning.

Protocol Yield Share

I’m not sure how the PYS will be handled / where revenue will be held. So details are TBD here for now.

Redemptions

We’ve determined that keeping redemptions off, at least for the immediate post launch period, is in the best interest of users and the protocol. Disabling redemptions will give the first batch of CDP holders greater confidence to mint eBTC and help increase the circulating supply, without fear of being immediately redeemed against. There’s also a potential griefing vector while eBTC supply and liquidity are relatively small immediately after launch, where someone could mint and dump eBTC in order to purposefully trigger redemptions against a CDP with a lower collateral ratio.

We’ve seen at Liquity that redemptions are one of the largest negative factors for CDP user experience, and avoiding this unless/until necessary should help with initial bootstrapping. This in turn will allow for market liquidity to improve, reducing the likelihood and severity of downward eBTC depegs that might require redemptions in the future.

Unlike with upward eBTC depegs, which can potentially interfere with CDP liquidations, there is no direct solvency risk to the protocol from downward depegs. So while downward depegs may cause a temporary negative impact to user experience for eBTC holders, they aren’t a critical threat and can be addressed more gradually over time.

When redemptions are turned on, Badger would retain full flexibility to turn them back off or make them more or less aggressive. For example if we wanted to reduce the frequency/likelihood of redemptions without deactivating them entirely, Badger could increase the redemption fee floor which would mean redemptions would only begin to be triggered at a lower eBTC/BTC price.

Hope this helps, and feel free to share any other questions or comments!

:pen: monetsupply on behalf of BA Labs

1 Like

hi @BA_Labs/monetsupply thanks for your thorough reply :slight_smile:

the ability to ignore parts of the range (eg >1.1) is indeed only offered by uniswap v3, i see its advantage there. however im still not sure on how you are planning on distributing the incentives?

solving peg issues outside of the .99-1.01 range through the treasury buying/selling sounds good in theory, but i wonder how efficiently this can be implemented. can the treasury act in a timely manner and will it always have enough volume at its disposal? i guess time will tell.

2 Likes

Thanks for your strong work. Be cautious of including non circulating/native $badger as assets on our balance sheet. Thats where Organizations get into trouble.

1 Like

Thanks for sharing this eBTC planning, Peg Management and Monetary Policy, about time! :slight_smile:

There’s a few options here. For incentivizing liquidity:

  • Merkl by Angle protocol allows for off-chain calculation of liquidity across relevant metrics ($ value in active tick, depth, other arbitrary measures the protocol wants to target), and then lets users claim incentives periodically via a merkle root claim mechanism.
  • Automated liquidity management products (eg Arrakis, Gamma) create a fungible token to represent Uniswap v3 LPs, these could be incentivized via a regular staking contract. Most likely this would be done with static ranges (eg no active liquidity rebalancing or management).

For incentivizing CDP users who mint eBTC, a periodic merkle root claim or maybe direct distribution could work.

We’ll have to see about performance. But, I think the benefits of greater profitability and capital efficiency of buying/selling vs adding more funds to wide range passive LP outweigh the execution risks. For cases when eBTC trades below peg, we also have the ability to activate redemptions which should give a strong price floor.

1 Like