Our new initiative is to keep the community up to date with monthly build-in-public updates around what service providers to the Badger association have been working on.
With launching the eBTC protocol being the most important milestone of the Association’s Q1 goals, this update is focused on the technical progression of core protocol development.
In the next builder update we will dive deeper into governance, web2 and product.
January was focused on continued mitigations from the C4 contest, revisiting the price feeds in light of some new insights, and polishing of our testing suites.
For mitigations, the bigger threads focused on obscure economic or mathematical edge cases and locking them down with new mechanics.
Some of this work was in December, but as this is the first update it makes sense to include more context.
A CDP system is only as good as its oracle(s). It’s one dependency you can’t get away from yet.
We made the call to enable governance over the primary oracle for security and future-proofing reasons.
This led to revisiting some design considerations, as the original PriceFeed contract has a number of complex “paranoid” features that make more sense when trying to plan for all contingencies in an immutable setup.
The ability to swap the primary oracle reduces the need of all these additional complexities and allows for a more efficient pricing mechanism that still meets the highest security practices. For this reason, we created a simplified priceFeed; the EbtcFeed.
However, we have a deeply audited PriceFeed that, despite its complexity, has been thoroughly tested.
We decided to keep this code, and introduce that feed as the primary oracle within the new EbtcFeed design. So we ended up with a hybrid solution that uses the existing PriceFeed mechanics (which combines dual Chainlink feeds with a validity state machine + potential backup oracle) as the primary oracle while still keeping options open in the future.
The EbtcFeed decision tree at the highest level:
To price stETH/BTC, the original design involved combining the Chainlink ETH/BTC and stETH/ETH market rate feeds.
However, there have ended up being very few users of the ETH/BTC feed and as Chainlink monetizes their services it would become notably expensive to run for the few users of it.
This is one example of why locking in an oracle forever is a difficult thing to plan for.
Working with the Chainlink team, the better solution was to move to combining other feeds:
- We get ETH/BTC by combining ETH/USD and BTC/USD
- Then merge this with stETH/ETH to get stETH/BTC
However, now you need to combine three feeds rather than two! When combining feeds, your maximum price deviation from market rate becomes more “loose” as you combine the deviation threshold of the feeds involved.
- 0.5% + 0.5% = 1% max theoretical deviation from market rate
- 0.5% + 0.5% + 0.5% = 1.5% max theoretical deviation from market rate
The primary implication of this is that the base fee for redemptions is determined by the maximum deviation threshold of the Oracle. If this threshold is reached without an update and the redemption fee is lower than this threshold, an unfair arbitrage opportunity would be created. Consequently, the maximum deviation threshold defines the maximum hard peg at the floor that can be enforced through redemptions.
We also revisited the topic of pricing stETH in terms of ETH. Should we continue to use the market rate oracle, or assume a 1:1 fixed price between the assets?
Ultimately, we decided that the risks of a real depeg in a post-merge world are lower than the risks of an oracle malfunction. However, both can lead to negative consequences and we want to be able to respond to a true depeg.
For this reason, and to maintain a maximum deviation threshold as low as possible, it was decided to implement the primary oracle by aggregating only the ETH/USD (0.5%) and BTC/USD (0.5%) feeds, and assume a fixed 1:1 stETH/ETH ratio. We call this the “optimistic stETH” oracle.
However, close monitoring will be in place for potentially harmful de-peg situations. We can seamlessly switch to the market rate oracle as an emergency measure.
The rounding issue prompted deep research re-evaluating all the accounting to ensure the problem was small and precision-related.
- The issue was found to be a very small, bounded issue related to solidity fixed point precision.
- Practically, when you avoid allowing extremely low values it helps mitigate this. We introduced a minimum 1000 wei unit debt for a CDP. For context this value represents 0.0000000000001% of a full Bitcoin (notably less than 1 sat).
- Additionally, there is 1000 wei units minimum change of debt and a 1000 wei minimum change to collateral on user operations.
When calculating redemption fees, the fee scales based on what percentage of the system is being redeemed. The more that is redeemed in a given timespan relative to the total system debt, the higher the fee. This is designed to let redemptions “cool off” and for the asset to regain market confidence without the need for more redemptions.
We had a finding around a scenario where a user could use flash loans to artificially inflate the total debt for a block, reducing the fee paid for redemption. This could lead to more being redeemed than should be profitable in (admittedly quite extreme) eBTC depeg scenarios.
There is now a TWAP mechanic on the system debt to prevent spot manipulation of the system debt via flashloan.
This uses the smaller of the TWAP value and spot value as the total debt with which to calculate the fee, to ensure it is always in the protocol’s favor.
A hallmark of eBTC late last year is the work we put in with Antonio Viggiano to leverage front of market property testing methodologies and fuzzing tools.
See more in Antonio publishied an article ‘learnings-from-6-weeks-of-fuzzing-badger-daos-ebtc-protocol’ and check out the Spearbit presentation on youtube. (the forum places limits to including links in this post, thanks for searching)
In Dec/Jan we added a couple new test suites in addition to some coverage expansion opportunities:
- Doomsday Tester
- PriceFeed Tester
DeFi users are used to zaps to make their actions as seamless as possible.
Although eBTC is single collateral (stETH), we want users to be able to enter from other assets.
For the first round of zaps we added the ability to enter positions with native ETH, WETH, and wstETH. These assets were scoped first because they don’t require any swapping. Introducing swaps into the zap leads more to security considerations, handling of slippage, etc.
We used the Position Managers feature of eBTC to build this in a way which is peripheral to the core protocol.
These Eth-variant Zaps are feature complete and already integrated into the app. They allow users to:
- Enter or increase collateral to positions in native ETH, WETH, stETH, and wstETH
- Exit or decrease collateral to positions to stETH or wstETH
We have a continuous cadence of security review at a PR and release level during development. This has been a big focus in January working with a variety of private security partners.
See more around our security process in the interview series on twitter.
The last stage before the eBTC protocol is available for anyone to try on ebtc.finance is our Immunefi bug bounty.
We are tackling this bug bounty in two stages, pre launch and post launch.
Our pre launch bug bounty is an incentivized contest run against the final eBTC code which will be deployed on mainnet but not officially live.
This also acts as the last audit of the codebase, aiming to be completed in late February.
Assuming there aren’t any vulnerabilities discovered, the final step is connecting it to the dapp and going live publicly!
It’s been a long road but we are nearly at the finish line and excited for everyone to try the best bitcoin borrowing protocol in the world.