[Informal Poll] Creating a Bite-Rebate Contract for Keepers Acting on Small Vaults

Before we get into politics:

  • What happens to those vaults if no one is biting them?
  • What is the cost of that bad debt?

Is that cost higher than the subsidy + the implementation costs + potential new risks?

I want put emphasis on the implementation costs. It’s not like we have extra resources lying around.

Going back to the politics (not really, but my 2 cents):

  • I don’t think anyone believes that MakerDAO is raising the dust to “outprice” smaller investors. (DeFi has become less inclusive in general because of the current limitations of Ethereum. #ETH2 #EIP1559 #POS #L2 #soon
  • Usually subsidies are a bad idea. We could speak next about the real cost of food, or the type of energy we use. We can also start thinking about what else we could subsidize. #WenAirdrop

I can think of a couple ways that we would implement this without adding work to the developers. For example, MIP14 (not sure if there’s something simpler) + donations into a wallet, someone monitoring the bites, and manually sending rebates. I’m sure there are better ways of doing it. :man_shrugging:t2:


In liquidation 2.0 this subsidy is built in.
So the suggestion here is to just take the subsidy part from liquidation 2.0 and implement it externally to the protocol.

That said, now it seems that the subsidy in liquidation 2.0 might also not be able to handle small vaults. So this undermines my original thought of having a temporary patch until liquidation 2.0 is live.

1 Like

This poll is set to close soon, with pretty low voter turn out. One last plea for people to share their opinion on the matter! It seems like there is some support for sure, but some noted push-back on the idea of using subsidies to stabilize the system.

@cmooney shared some interesting points on yesterday’s Governance and Risk call, surrounding Liquidations 2.0 already having a similar subsidy structure. I don’t know if you have a moment to share some thoughts on this post Chris, but if you do it would be greatly appreciated!

I voted no on this just because I would prefer to go with a more general solution. Biting vaults is an issue which will be resolved by LIQ-2.0, but there are many other functions which require altruistic actors to maintain such as spot.poke(), jug.drip(), dcIAM.exec(ilk), and the new PsmFlipper.

I’ve created dss-cron to do exactly that. I considered doing a fixed rebate calculation, but that could potentially open up an attack vector which allows anyone to drain funds from the DAO at the highest possible speed. Instead I opted to go with a steady increase of the bounty to enable competition to bid on the lowest price.

That being said, I think EIP1559 will be exposing the new base fee which will be very helpful to determine is someone is placing a competitive bid or they are just wasting money. Once that comes out we should be able to do the fixed refund + tiny profit method.


There has already been spam attacks done against the protocol in the past. Wouldn’t this kind of uneconomical subsidy just further incentivize spam attacks? I think this effort and resources should go towards building a real layer 2 solution that actually deals with the real problem instead of getting stuck putting on band aids.

Unfortunately liquidation 2.0 will not be able to incentives biting small vaults (as otherwise the tip will be bigger than the penalty). At least unless the devs will agree to add the tip to the tab.

Given LIQ-2.0 would not solve it, it also does not make much sense to implement this temporary patch.

1 Like

spammer will lose more than the rebate. And more generally the DAO will profit more than the rebate loss.
That said, as I said in previous replies, since liq 2.0 wouldn’t solve it, I no longer see a need in a temporary patch.

If you can get layer 2 solution for $10k, and 0 dev work (as I suggested to do the implementation myself), then go ahead…
That said, given liquidation 2.0 would not solve this issue as well, I agree that this concrete patch is not needed.

1 Like

I changed my vote to NO, after realizing that LIQ 2.0 will also require high dust level, and hence there is no point in spending effort towards a temporary patch.

I would recommend the community to try and make LIQ 2.0 to support low dust levels, as IMO it requires a very minor change in the code.


Given the recent contributions and voting shift in the poll, I am deciding to close this poll a few hours early. Thank you everyone for the thoughtful comments and debate.

It seems that this solution is not right for the time being, however I still believe we can come up with one that is worthy of our time and resources. To help find out what that idea might be, I started a new Brainstorm Thread in hopes that we can aggregate thoughts there and pursue a new path forward. Wanted to offer a special thanks to @yaronvel for his work on the code and for all the time he spent answering questions about this idea.

I’ll be tagging everyone else who participated on this discussion here to say thank you, as well as to encourage your participation on the Brainstorm. But even if you don’t have the time to keep discussing this topic, I want you to know how deeply I appreciate you engaging on this policy that means so much to me. @ElProgreso @mario @Joshua_Pritikin @bit @g_dip @smaugho @ultraschuppi @juanjuan @hexonaut @Replenish2030