We are working on B-Protocol, a backstop liquidity protocol, that is built on top of MakerDAO, and offers two advantages:
- It mitigates the gas wars, and shifts the MEV to the users, by doing periodic on-chain MEV auctions via a smart contract.
- It gives rise to more committed liquidators as it gives them more certainty.
Technically details are available here, and the implementation, as an alternative vault management system (aka CDP), is available here.
The new liquidation system is opt-in in the sense that users can choose if they want to connect to it or not, and in any case, the user’s CDP is still subject to liquidations by the original MakerDAO keeper, if the B-Protocol system fails to liquidate it.
Besides more committed liquidators, and higher yield to the users, we believe the MakerDAO system as a whole could benefit by having a “sandbox” to try out new opt-in liquidation systems, who could put to a test different liquidation approaches, without hurting the underlying security of the protocol (as it is only an additional layer).
The reason I am writing this post is to start a discussion on how MakerDAO governance system could support such platforms.
In particular, the B-Protocol vault management system relies on the
cat contracts, where the
cat contract is used to read the liquidation penalty
chop (in order to be able to offer the same conditions to the users).
Relying on the
cat contract is problematic as it is being upgraded over time.
Currently I can think of some ugly workarounds, like assuming that any contract with a
chop() function that returns a non zero value, and that is relied by the
vat contract, is the
But as I believe the system could benefit from more opt-in liquidation systems integrating with it, I think a more systematic solution is in order.
I would be happy to share more thoughts about potential solutions, and also to share more details about B-Protocol, which is expected to go live on October.
P.S: general feedback on B-Protocol is welcomed.