MIP13c3-SP11: Onboarding a new collateral type backed by B.Protocol v2 (Declaration of Intent)


MIP13c3-SP#: 11
Author(s): Yaron Velner (@yaronvel)
Contributors: n/a
Status: Request for Comment (RFC)
Date Proposed: 2021-6-16
Date Ratified: <yyyy-mm-dd>
Declaration Statement: Onboarding a new collateral type backed by B.Protocol v2.
Declaration to Replace: n/a


Context and Motivation

  • Maker, and the DeFi ecosystem in general, has conservative collateral ratios (CR), in order to mitigate potential failures in the liquidation process. High CRs narrows the potential user base, and the potential profit from stability fees (SF), and reduces capital efficiency in the market.
  • B.Protocol introduces the concept of a backstop made of committed liquidators, who get priority in the liquidation process, in return for their commitment to execute liquidations.
  • B.Protocol has been live since October 2020, and few successful liquidations were already done .
  • B.Protocol’s V1 was designed as an opt-in system, where users can decide to manage their Vault with, and give priority to the backstop liquidators. B.Protocol liquidators in return share some of their proceeds with the users. In particular, it requires MakerDAO users to interact with a new set of smart contracts.
  • The V2 of B.Protocol is based on the B.AMM. A user based liquidation system, with a novel rebalance algorithm that combines Curve Finance’s stable swap invariant with a price oracle.
  • An experiment is proposed for a native integration between B.Protocol v2and the MakerDAO system, by on-boarding a new collateral type, namely WBTC-B or ETH-D, with lower CR than WBTC-A or ETH-B (respectively), which will be natively backed by at least 1M Dai deposits in the B.AMM.
  • This proposal replaces proposal MIP13c3-SP9, with the more robust design of the backstop.

Committed backstop design using B.Protocol V2

The B.AMM will pool DAI deposits from users and will deposit it to the Maker’s DSR system where it will get some yield when the DAI is idle, and not used for liquidations.

Upon liquidation, the flip contract will transfer the WBTC-B collateral to the B.AMM, who will give DAI in return, with a 5% discount over market price. The DAI will be used immediately to repay the undercollateralized vault debt in return for the discounted collateral.

The B.AMM will offer the WBTC-B for sale according to a special formula that is described in the whitepaper.

Once the WBTC-B is converted to DAI, it will be deposited back into the DSR.

It is a trivial observation that 1M Dai deposits can trivially handle 1M Dai liquidations. And the experimental results in the whitepaper show that X deposits can cover up to 10X of monthly liquidations.

Declaration Detail

Maker Governance declares its intention to experiment a native integration with B.Protocol’s V2. Namely, to on-board a new collateral that gives a priority(*) in liquidations to B.Protocol, in return to an on-chain commitment of 1M Dai locked funds for the duration of the experiment, towards successful liquidations.

(*) If B.Protocol fails to liquidate a Vault, then the Vault will be liquidated by the standard Maker keepers, like today.

Further, it is the governance intent that:

  1. The development work will be done by the B.Protocol team, to the satisfaction of the protocol engineering core unit.
  2. The collateral price oracle will be recommended by the oracle core unit.
  3. The risk parameters, namely, the CR, debt ceiling, and auction parameters (if still applicable) will be recommended by the risk core unit.
  4. Stability fee and liquidation penalty will be discussed again with the community, in the form of signal requests.



Pleasantly surprised to see this proposal and look forward to seeing the B.AMM in action. Good luck @yaronvel.


Hey @yaronvel, could you please propose a PR here for the new proposal? Thanks!

This section is very clear, succinct and comprehensive. Well done!

I’m excited to see the outcome of this declaration. I’ll ping @Risk-Core-Unit @Oracles-Core-Unit and @Protocol-Engineering here to ensure they are aware of the contents that involve their units.


It will also be great to present it in one of the governance calls.


@yaronvel I had the time to add it Github, so don’t worry about this anymore :slight_smile:

Reference: mips/MIP13c3-SP11.md at master · makerdao/mips · GitHub


Thanks for the interesting proposal!

Some initial thoughts:

  1. The B.AMM design relies up-to-date oracle prices, whereas the Maker system currently uses only delayed prices. This is to allow time for reaction against oracle manipulation. Thus the new mechanism increases the impact an oracle manipulation attack could have (as collateral could potentially be sold at a very low price even if the delayed price is reasonable). The Risk+PE+Oracle teams should discuss this thoughtfully and consider whether the potential benefits outweigh the additional risks.

  2. Who will have control of the StableSwap A parameter used by the B.AMM–Maker governance or B.Protocol governance?

  3. How will the fallback to the Maker liquidation system work? How does the system know if a Vault has been “missed” by B.Protocol? This mechanism may be non-trivial. One concern: in the case that fallback to the Maker system is necessary, it seems there would be much greater risk of auctions underperforming since the collateralization ratio will presumably be set lower for the new ilk (otherwise there is not much point to integrating B.Protocol, since the main benefit of this should be lower collateral requirements resulting in a more attractive self-borrowing offering).

Of course we do not necessarily need to completely resolve all concerns before trying things with a low debt ceiling, but these areas and potentially others should be discussed in more detail first.


Thanks for the questions. Before replying to each of the questions it is important to observe that some are related to B.AMM user risk, and not to Maker risk, which give rise to the question if Maker should care about B.AMM user risk.
The short answer is that it should care, but there are ways to mitigate it. On the most extreme case, B.AMM users might lose a lot from bad trading, and then fewer funds will be available to backstop the new collateral. However, an important observation is that the B.AMM dai balance can decrease only when liquidation happen. Therefore a mechanism that will peg the ilk max debt (line) to the B.AMM dai balance (possibly with some factor), could mitigate (or even fully mitigate if the factor is 1) B.AMM user risk from affecting the stability of Maker.

Will now reply to each of the questions:

  1. At least initially we can make it a B.AMM user risk. Meaning if the gem does not suffice for 1.05 * debt, then we can set the B.AMM to agree to take all the gem in return to repaying all the debt. Regardless to what the oracle price is. Bad oracle price would damage the rebalance process, but this is again user risk.

  2. The parameter only affects the rebalance process, so it is again user risk, and should be under the control of the users (meaning B.Protocol). We can consider have the Maker governance dictating a range for possible As.

The idea is that when calling bite it will check if the B.AMM can take it. And if not, it will execute the current auction process. Note that since liquidation 2.0, the dss relies on an external user to call bite. So there is no difference in that regard.

This is true. And eventually it is a matter of trust in the system (in the system code, and crypto economic incentives). Initially it will be easy to mitigate by setting the line to values that are not far away from the B.AMM dai inventory. But over time the idea is to have a partial reserve system. Still I would argue that it is safer than the current state. In the present state there is no public knowledge on the amount of liquidity available towards liquidations, which makes it impossible for the DAO to make a fully transparent evaluation.


Hope to see the B. AMM up and running soon to see how it handles a bear/choppy market.


Very promising.
Initiatives like this, which effectively allow lowering the CR and attractive leveraging can potentially grow to great sources for generating DAI.

Some comments on the price oracle initial discussion:

As I understand there are a few price feeds/oracles in the mix:

  1. The price feed for triggering the liquidation (i.e calling bark).
  2. The price feed anchoring the proposed 5% liquidation price discount.
  3. The price feed used for the rebalance process algorithm.

I think that the price feed for triggering the liquidation (1) should remain the OSM delayed price.

This will conform with the current liquidations system which tries to reduce price manipulation risk.

The price feed anchoring the discount (2) should probably be a live feed (not delayed), but should also be trusted by Makerdao. This could possibly be the raw medianaizer, though we need to see if its resolution is fine grained enough.

Regarding the price feed for rebalancing, ideally it would be the same as (2), but this should be further discussed with B.Protocol, as this is more on their side of the system and could be generic for other platforms.

Regarding the mitigation suggested for an oracle manipulation, if I understand what is proposed is that if the price is low enough causing not all debt to be repaid (tab is not reached, leading to potential bad debt) - then all of the debt will be paid in return for all collateral.

I think this is reasonable - it will effectively put a lower bound on the price, which should be deducted from the OSM delayed price. Note that this indeed puts the risk on the B.AMM users (not only in a manipulation but also in a potential “regular” flash crash), and not on the maker system.

Overall this seems to me like a good experiment to cooperate with.


Thanks @yaronvel, I would say overall I agree with your responses–most risks can be primarily B.AMM user risks initially, and establishing a relationship between an ilk's line and the B.AMM liquidity available for it would be a good mitigation. Some custom logic will be needed for the fallback, but I think it can be done without replacing any core contracts (and we might re-factor the liquidation system in the coming months to simplify this sort of integration, although that is not a blocker).

I like @talbaneth’s comments on oracle considerations too–delayed price for liquidation, a Maker-trusted current price for discounting, and a B.AMM-determined price for rebalancing. The key challenge from a risk perspective seems to be making sure the discounting price and rebalancing price are sufficiently close to avoid taking either too much or too little collateral in the majority of cases.


Yes, and we can definitely take the medianizer as one sanity, and even the OSM price as additional sanity. I think eventually the liquidity providers will be Maker enthusiastic, so there is definitely a merit to rely on maker feeds as much as possible. However afaik the medianizer is being updated only after 2% price change, while chainlink, e.g., update every 0.5%.
But yeah, taking a sanity with it and the OSM (say even up to 50% difference from the OSM) might be enough to provide some guarantees even if the medianizer and chainlink feeds are rekt.

The feedback from the smart contract team (@Kurt_Barry and @talbaneth) is great and appreciated, and we will definitely implement it once the deceleration of intent is approved.
For the deceleration itself, currently it is quite generic, and explicitly specified that it will take into account the core unit team member feedback. So there is no need to revise it (if I understand correctly).

1 Like

@charlesstlouis we would like to move forward with the proposal and make it a formal submission towards this August governance cycle.