[INFORMAL POLL] Would the Maker Community want to onboard a new collateral (e.g., WBTC-B), backed by B.Protocol that has lower CR with the same SF?


The purpose of this Informal Poll is to get a clearer picture of the MakerDAO community sentiment towards onboarding a new collateral type (e.g., WBTC-B Vault) backed by B.Protocol, which will offer a lower collateral ratio (CR) while keeping the same stability fee (SF) as the existing one (e.g., WBTC-A).

This vault type will be accessible via Maker standard interfaces, and any platform (e.g., Oasis, Instadapp, and other integrations) could offer it to its users. The only proposed change is in the liquidation mechanism.

Further to the discussion we started a week ago, and after presenting the topic in a MakerDAO Collateral Onboarding call, and the discussion that followed it, we are looking for feedback from the governance on whether it sees this proposal as something that would help Maker, before we continue with the technical implementation efforts.

B.Protocol is offering to add a new collateral type, for example, WBTC-B, which will have the same stability fees as WBTC-A, with a lower collateral ratio. B.Protocol liquidators would be forced to hold a WBTC-B Vault with a net positive position of $0.5M. Upon liquidation of a user, the liquidators are forced to take the user position (debt + proportional part of the collateral). In the event that a liquidator Vault becomes undercollateralized, it will get liquidated by the usual Maker liquidation process, i.e., in an open English or Dutch auction.

We illustrated the proposal with more details in the discussion post, however at this point we ask for feedback on the concept, rather than on the concrete parameters.

If we get a positive response to this informal poll, we will pursue the idea further and do the following:

  1. Ask for additional feedback on the concrete parameters (both from the community as well as from the SC and Risk teams which we are already in touch with), and submit a Declaration of Intent proposal, via MIP13, to get the community consensus about these parameters.

  2. Implement the needed smart contract changes - we plan to implement all the needed changes, both on B.Protocol and Maker side.

  3. On-board committed liquidators, likely from our genesis backstop.

I will summarize the pros and cons of the proposal below.

Enable a Collateral with B.Protocol as a Backstop

B.Protocol is a decentralized backstop protocol. We are live for one month, backstopping around $11m of ETH-A collateral and $4.5m debt. A first successful demonstration of the protocol capabilities was done during the sharp market crash on Thursday 26/11. B.Protocol introduces the concept of relying on committed liquidators, who get priority in the liquidation process, in return for their commitment.


  1. Maker gets to offer a lower collateral ratio, which means that users could obtain higher leverage by using Maker, and/or have more relaxed collateral requirements if they are not interested in leverage. In the long run, this will increase the DAI circulation, and therefore the stability fees for the MKR holders.

  2. It is our perspective that it will be done not only without compromising the stability of Maker, but it will even contribute to its stability, as it adds another layer of committed liquidators, while still leaving Maker as the ultimate backstop (like in the present state). Note: While this approach is quite a standard in the TradFi world, it should still be considered subjective, and this signal request aims to get the Maker community’s opinion on that.

  3. B.Protocol team will do all the development work needed for the collateral on-boarding.


  1. Due to the low CR proposed, MakerDAO will have to give up at least some (if not all) of the liquidation penalty proceeds, in order to allow sufficient incentives for the liquidators, without imposing the user with a higher liquidation penalty (which will make the collateral type less attractive than WBTC-A).

  2. The proposed backstop liquidation mechanism does not give mathematical guarantees or insurance like was offered by Nexus Mutual. The community should understand that we simply commit into building a protocol with incentives for big traders/liquidators to on-board and to bootstrap it with initial liquidators. Neither we nor the liquidators commit to the success of liquidations. However, the liquidators have a clear stake to lose if they fail.

  3. While we plan to do the development work for both sides, this proposal will probably add some workload to the domain teams, who will likely be requested by the community to express their opinion before going live with it.

This proposal, and the pros and cons listed above, are relevant for both Liquidation 1.2 as well as for Liquidation 2.0 once it will be deployed.


We ask the community feedback on the next 5 questions. It should be noted that questions 1-4 are tightly coupled, and negative responses to questions 2-4 might make the proposed design infeasible.

Are you comfortable with Maker offering a Vault type backed by B.Protocol’s liquidators (according to the scheme described above)?
  • Yes

  • No

  • Abstain

0 voters

Given a Vault type is backed by B.Protocol’s liquidators. Would you vote for a stability fee that compared to the current vault (for the sake of example, WBTC-A vs WBTC-B) type is:
  • Lower (e.g., lower than WBTC-A fee)

  • The same

  • Higher

0 voters

Given a Vault type is backed by B.Protocol liquidators. Would you vote for a lower collateral ratio?
  • Yes

  • No

  • Abstain

0 voters

Given a vault type is backed by B.Protocol liquidators. Would you agree to vote that when the liquidation is done by B.Protocol, the Maker DAO will not get the Liquidation Penalty?
  • Yes

  • No

  • Abstain

0 voters

Which assets would you like to see used for Vaults of this nature?
  • ETH

  • WBTC

  • Other

  • Any

0 voters

This informal poll will run for 2 weeks (Dec 28th) and can be extended if there is not enough activity or consensus.


I am not even going to vote Abstain in the above polls as I think B Protocol is moving much too quickly on this. First I want to see Maker implementing Liquidations 2.0 and we see how that works. And then there is the fundamental issue if the community wants to see core functions outsourced. Minor liquidations are already handled without much issue using the present system, and I am quite sure no one has done any real analysis of a black swan event using B protocol. After all - in crypto a committed liquidator is only one transaction away from being non-committed.

I would be much more comfortable if B Protocol worked with the existing liquidation system instead of wanting their own Vault type.


Thanks for the feedback, below are replies with our point of view:

I don’t think liquidations 2.0 was designed to enable better collateral ratio. And in any case, in the proposed design it will be used in the case B.Protocol fails to liquidate.

the proposed solution suggests that liquidators will commit by locking funds, and if they fail to liquidate they will lose it. So they will have a lot to lose if they fail/stop being committed.

the proposal is to have gradual controlled experiment., so we believe it is better to start a small experiment quickly, and gradually increase it, than waiting a long time before begins.


The more capital is committed to liquidations the more skin in the game to mitigate a Black Thursday type of event. Seeing how it works with a million dollar debt ceiling we can start to extrapolate how high the debt ceiling should be. Also, Liquidations 2.0 are a nice safety net in case all else fails. If this works, MakerDAO would be more capital efficient and less exposed to the downside risk in a flash crash.


There are additional cons:

  • dependence on external protocol
  • extra complexity for the maker protocol
  • less transparent protocol (we don’t have any monitoring, graphs, data exporting etc… tooling)

I would put complexity and dependency under same category, as the proposed solution will have an immutable smart contract code, so it is not like you will depend on its operators or community.

Regarding transparency, our point of view is that the current liquidation process lacks a lot of transparency. The governance has no clue on which systems are currently use for liquidations, and have no commitment from the liquidators. So it is my view that we bring more transparency to the process, and would be happy to provide analysis tools for it once it is up.

1 Like

Thanks for the poll @yaronvel! I think most people that came to the Collateral Call feel pretty comfortable with moving forward with this at an experimental level. For those who did not attend the call I highly suggest watching the video here. Yaron answers many of the questions and concerns that are being brought up on this poll and as someone who initially thought this move would be too risky, I was motivated to support the proposal based on Yaron’s presentation. The only part I didn’t agree with in the poll above was giving B.Protocol the entirety of the liquidation fee. I believe B.Protocol should be entitled to the vast majority of the fee, but that Maker should get a small percentage from that interaction if implemented as proposed, given that we are sending over some users (and potential liquidations) to this backstop via the Oasis platform.


Hi @yaronvel thanks for the post. Something that I think could use clarification:

Does B.Protocol offer protection from OSM delay attacks? I.e. if there is a special vault within B.Protocol with a very low CR, does something prevent the Vault owner from drawing Dai up to the debt ceiling should the Vault go below a 100% CR during the period of the OSM delay?

Technically the liquidators have their deposited funds as protection, that will incentives them to liquidate even at a losing price.
But it is not intended for that. The funds are locked to incentives liquidators to liquidate, not to cover for potential glitches outside B.Protocol.

In the long term if Maker would want to offer competitive CR, this is something that will have to be addressed anyway.
For the new collateral, as several proposed, we can start with 120-130% CR, which could mitigate a delay of couple of hours, and already seem to work with ETH-B.

1 Like

Agreeing with the view of @Planet_X - maybe it is my fault that I haven’t followed the proposal in the last weeks (?), I don’t get why or how the B.Protocol keeper mechanism is superior to the keeper system which is currently already protecting the ecosystem and how this justifies to cut the liquidation penalty.

Voted no therefore

1 Like

In the proposed B.Protocol keeper mechanism liquidators lock funds, e.g., $0.5M in return for a commitment for liquidations, and will lose them if they fail to liquidate.
Our view that this is an improvement to the current situation where in extreme market conditions, e.g., balck thursday, liquidators didn’t act (and more over it gives them a clear incentive to build a robust liquidation system).
In addition if they fail, the liquidation falls back to MakerDAO keepers (and then also the liquidation penalty goes to Maker), so the protection is better.

Regarding potential loss of revenues due to a cut in liquidation penalty, the question is if the increase in stability fee will not compensate for it.
If you look at TradFi platforms like bitmex, who make billions in revenues, while taking 0% of the liquidation penalty to itself. This allows it to construct a big backstop of liquidations and offer better leverage for its users.

1 Like

A general technical perspective: one concern with both liquidations 1.2 and 2.0 is that auction participation is zero-sum and subject to value extraction by miners, which makes developing a robust ecosystem of committed Keepers challenging. B.Protocol quite literally changes the game theory around liquidations to favor cooperative strategies that evenly share liquidation proceeds among capital contributors. I believe this mechanism, or one like it, could be the optimal path forward for reliable and safe liquidations (with an auction mechanism always available as a fallback).

One thing I think people commenting on the liquidation penalty should keep in mind is that it primarily exists to prevent auction grinding; generating additional protocol income is a side effect. IIUC, there is no “liquidation grinding” attack possible with B.Protocol because liquidators are bound by the smart contracts to repay debt fully or not at all (@yaronvel please correct me if I’m mistaken). If integrating B.Protocol incentivizes higher Vault usage (because liquidations are less risky and parameters are more favorable), this could very well compensate for the loss of penalty fees in the long run. That said, it might also be reasonable for some portion to still go to MakerDAO and I leave that for the community and B.Protocol to negotiate :).

IMO it’s best to experiment early and often; so long as downside risk from the integration is managed via appropriate sizing of max debt ceiling of the new collateral type, I don’t see why the DAO should need to wait for, say, Liquidations 2.0 before trialing B.Protocol. Auction parameters for the new ilk will have to be considered carefully, however–there is additional tail risk because while B.Protocol will make typical liquidation events more predictable in outcome, a very large event that liquidates the backstop Vault itself will result in an immediate and huge auction event (mitigated somewhat by parameters like box in 1.2, but that just reinforces the need to choose parameters carefully).


Capital efficiency will be more demanded as the bull run accelerates therefore I believe we should start to explore this possibility with a tight debt ceiling and adjust it as we move along, having said that I’m more in line with an increase in the rates and a split in the liquidation fee.

Correct, a liquidator that will liquidate himself (under different identity) will not profit, and if he himself get liquidated, it will go through Maker standard liquidation process (1.2 or 2.0), which does have a full liquidation penalty, so nothing to gain there.

The proposal could work even if liquidation penalty is not fully 0, so there is a room for discussion there. it should be noted though that every $1 that goes to penalty is either on the expense of the user, or on the expense of the backstop, which will eventually lead to a weaker backstop.
Also as a side note, a lending platform that takes liquidation penalty to itself, or in general profit from its user losses (while controlling the price feed, and other parameters) , is somewhat of a conflict of interest.

this is a good point.
For the short term, in a small experiment the risk is mitigated by the small size.
But moving forward this could be mitigated by forcing requirements on the number of liquidators before increasing the ceiling.
In this case every liquidator insolvency will only trigger a medium size liquidation.
It is true that there is likely a correlation between liquidator insolvency (i.e., it is not an independent random variable), but this is also the case now where there is a correlation between CDPs insolvency (though likely at current state the variance is lower).
In the long run it gives a unique opportunity for the Maker DAO to require (and enforce) advance risk management criteria over the liquidators, and liquidate them if they do not adhere.

But this should evolve over time, and could be best decide after extensive experiments.


I agree with the points made by @Kurt: both about the liquidation penalty and that B.Protocol has the potential to create a more reliable equilibrium for MakerDAO liquidations. I think an experiment using B.Protocol with a low LR collateral type with appropriately sized debt ceiling to mitigate risk should go ahead, since it might teach us a lot about how to improve reliability of liquidations.

I voted for higher SF for the B.Protocol collateral type not because I think that all else equal, B.Protocol-liquidated collateral types should have a higher rate, but because of the assumption that a B.Protocol-liquidated collateral type will have lower LR and therefore should have higher SF for both risk and business reasons.


Really interesting proposition.

As detailed by Kurt_Barry, B.Protocol provides an innovative design to liquidation process.
I am in favor of an experiment.


Let me first say, I think we need to do more experiments like this with low debt ceilings and see how they prove themselves. I think we need to think hard about the following though:

  • the debt ceiling
  • the LIQ-1.2 or LIQ-2.0 parameters, as these are the backstop
  • sharing the liquidation penalty (more on this later)
  • collateralization ratio

It’s true that the liquidation penalty is in place to stop auction grinding attacks, but I noticed something interesting on the Thanksgiving pullback. Unlike on Black Thursday, the most recent pullback saw a large spike in surplus (flap) auctions from the liquidation penalty. I believe the protocol received 1.5 to 2 days worth of additional MKR burn from liquidation penalties from fees. We never got to see this healthier operation of liquidations on BT, and what it meant was that while MKR was pulling back, there was aggressive support of the MKR price on exchanges. This is still minor compared to the overall market pullback, but that means that more MKR was purchased off the market at favorable prices and burned. This function ends up being highly desirable if market conditions continue to deteriorate, as we may eventually see prices that are so bad they lead to no collateral left for Vault holders, no liquidation penalty left, and eventually bad debt that could eat the surplus buffer and lead to debt (flop) auctions. In this scenario, the earlier flap auctions built up some capacity in MKR that the protocol now needs, as it will mint() more to recapitalize the system. For this reason, I think the community should heavily consider sharing any liquidation penalty.

So, as much as the liquidation penalty was a way to prevent auction grinding attacks and ward off liquidations by being considerably worse than what a Vault holder could unwind on the market for, it turns out the penalty has some income/safety potential for the Maker Protocol. I think there is a strong chance that LIQ-2.0 would be all the protocol needs, at least for now, to secure liquidations into the future; however, I think the B Protocol experiment can’t hurt to try and helps us hedge against potential LIQ-2.0 shortcomings. For that reason, I am in favor of an experiment with a small debt ceiling to start, but MKR holders need to be prepared for the failure of any such experiment that could wipe out the protocol’s surplus buffer and ruin our capacity to fund teams. We have a growing number of these experiments, and perhaps should plan accordingly for the failure of one or more of them at the same time.

@yaronvel I just wanted to indicate, and risk teams can say more, that LIQ-2.0 with dutch auctions using single-block composability should so greatly improve liquidations that risk premiums and possibly liquidation ratios will likely be adjusted. To that end, it may be worth highlighting the additional benefits of B Protocol’s solution over LIQ-2.0.


I agree LIQ-2.0 is much better than LIQ-1(.2). But the concept remains the same (and similar to all current DeFi platforms) of throwing all the bad positions to arbitrage bots, and it gives very little incentive to construct anything more than a flash loan arbitrage bot.
This is very similar to bitmex throwing bad positions to its orderbook, but this is only a first level of protection in bitmex.
For Maker it would mean that the CR will mostly be bound by uniswap liquidity, which is still order of magnitude(s) lower than CeFi USD/BTC liquidity (it is true that DAI != USD, but a robust hedging system could rely on it being a correlated asset).
This approach is not unique to Maker, and even if the LIQ-2.0 could support CR like in compound, it is still very far from CeFi levels.
And accordingly the ability to collect fees would be lower.

this is a fair point, and it is up to the community to decide. One might argue that high CR are an obstacle towards earning more from stability fees.

another fair point. all I can say is that liquidators will also have a lot on stake to lose, and maybe even more than the Maker DAO (though it depends on the parameters).
Recall that Maker keepers would still be there if B.Protocol fails, so the theoretical max loss is not the entire ceiling, but rather only the delta in CR times ceiling.

We are not selling an insurance. Though if you want to do 2 experiments at once, maybe Maker can combine this experiment with Nexus Mutual insurance :slight_smile:.
My personal view is that the proposed system is strictly safer, but I can see why this could be subjective, and in this case it is a trade-off between a potential of earning more stability fees, and the risk of becoming under-collateralized.


I think this is one of the key reasons why we should be hesitant to give away the liquidation penalty in its entirety to B.Protocol. Clearly, B.Protocol’s liquidators have to be heavily incentivized to be forced to take on liquidations at any time, and even more so considering the capital required up front to participate. However, if the entirety of the liquidation fee is kept out of the Maker system we lose a key chance to pick up MKR at a discounted rate, while also (in theory) losing a good chunk of SFs due to vaults being liquidated. While my initial split suggestion of 10% to B and 3% to Maker didn’t have any math behind it, I do think it’s pretty close to what should be deemed fair. While I do think we would benefit tremendously from B.Protocol testing and implementing obligated liquidators into our process, it is worth noting that we are doing pretty well under the current system and will be doing even better with Liquidations 2.0.

I also wanted to push back on this a little, as while it certainly opens up the avenue for malicious actions on the side of Maker, it’s hard to say charging a fee as a deterrent to users not monitoring their collateral is a conflict of interest. We are providing a service, expressly stated to our users, and if they break the contract in which we lay out what is a safe collateralization then we are not in conflict for taking profits from the operation of incentivizing a return to a stable collateralization ratio for the system. Yes we control the parameters and measuring of what is safe for the vaults, but in an open source fashion that allows anyone engaging with the system to see clearly how it will behave in different market scenarios


ooof maybe this :point_up: is something the folks over at "Balance sheet manipulation" discussion need to here as well…

1 Like