The Keeper’s dilemma: Game theoretic analysis of liquidation incentives, with preliminary empirical results

tldr; When the incentives are not clear, the liquidators’ expected behavior is also not clear.

Two weeks after going live, while testing B.Protocol liquidators, we observed that MakerDAO keepers do not liquidate Vaults with $120 debt. In this write-up we (i) demonstrate with an experiment how this could potentially be a threat to the MakerDAO system, as it is relatively cheap to split a Vault into small pieces (ii) performing a theoretical analysis that suggests the same behavior might repeat also for bigger Vaults; and (iii) present experimental results on how B.Protocol mitigates this issue by providing clear and quantifiable incentives to the liquidators.

The experiment was done over MakerDAO as currently B.Protocol is live with MakerDAO integration, and the Compound and Aave integrations are expected to go live towards the end of the year. The exact experiment is not applicable to other liquidation systems, and moreover it demonstrates only a single shot game, where a liquidator/keeper needs to take a single decision on whether he should liquidate or not. However, it is our belief that when modeling as a repeated game, and taking into consideration the costs of building a non-trivial liquidation system, all current DeFi platforms are lacking the proper incentives to ensure their stability.

In the next section we describe how we encountered this issue on the mainnet, and the experiment to measure the costs of splitting a Vault into small pieces. Then we present a theoretical analysis of the current incentives, and argue that it is not certain that the incentives for bigger Vaults are higher. Finally we show how a Vault of the same size was properly liquidated by B.Protocol backstop, thanks to a more quantifiable incentive system.

Preface

On the date of November 8th, we opened two MakerDAO Vaults, one via B.Protocol interface and one directly via MakerDAO vat contract, in order to demonstrate the two different liquidation processes. Due to budget constraints, each Vault consisted of only 120 dai (normalized) debt, which is roughly 20% over the minimum supported debt (aka dust). 40 minutes after opening them, they both became unsafe. However only the B.Protocol Vault was liquidated (by B.Protocol dedicated backstop). MakerDAO keepers did not liquidate it for a few hours, until we finally decided to repay the Vault debt and shut it down.

In order to investigate if this could potentially pose an potential threat on the MakerDAO stability, we decided to make an experiment on how expensive it would be to split a big Vault into many small pieces. We simulated splitting a $1M debt Vault into 7,800 Vaults of $128 each, by splitting a Vault of $514 debt into 4 Vaults, each of $128 debt (the exact number was chosen in order to make sure it becomes unsafe in the next price update).

On the evening of November 8th (we chose to do it on a Sunday, as usually the gas prices are lower on that day), we used this contract to open the big Vault, and this function call to split it into 4 Vaults. The cost of the split was 349k in gas, which amounted to $3.12, and it should be noted that on local simulations we did, the marginal amount for an additional Vault split is in the order of only 50k gas. We let these 4 Vaults to remain unsafe for over an hour and a half (and an on-chain recording of it was maintained in this contract). After that period we repaid the Vault debts and closed them.

Extrapolating these results to a Vault of $1M suggests that it will cost around $5k in gas to split it into 7,800 Vaults. Or in other words, one could protect his Vault from future liquidations by sacrificing only 0.5% of his Vault size.

We shared the results of this experiment with the Maker Foundation Smart Contracts team on the same day.

Analysis of the Current Incentives

The core reason for the fact that small Vaults were not liquidated is likely because the liquidators did not find it profitable to initiate the liquidation process.

In order to reason about the minimal threshold where liquidators will be willing to initiate such a process, we first bring some background on the current MakerDAO liquidation process, and then we analyze the minimal threshold. For the readers who wish to avoid the technical details, we can summarize our conclusion by saying that it is not clear such a threshold exists.

MakerDAO liquidation process

MakerDAO Vault management system (aka vat) has a price feed that updates hourly. When a Vault becomes unsafe w.r.t the price feed, the following sequence of operations take place:

1. A call to cat.bite() initiates a 6 hours auction process. Where each bid must present at least 3% increase over the previous bid.
2. A call to flipper.tend() is used to place bids, until the bid price is roughly 13% below market price.
3. A call to flipper.dent() is used to place higher bids.
4. After the 6 hour period ends, a call to flipper.deal() hands over the Vault collateral to the winner of the auction.

Observing this single transaction who executes stages 1–3 atomically, we estimate that the 4 steps consume at least 500k gas, which amounts to $5 in a day with low gas prices of 20 gwei.

Is there a minimal debt size to guarantee a liquidation?

What is the expected extra profit for an agent that invokes cat.bite()? For small amounts that are easy to hedge (e.g., by selling the entire quantity on uniswap), the best scenario expected outcome of the auction is to end in at most 3% below market price (though in practice some ends at much better outcome, and some ends even above market price). Given an expected $3 profit for a small Vault, it is easy to understand why liquidators will not bother to initiate such a process.

However, in the presence of non-negligible gas costs, is 3% really the expected profit? In such a case a rational agent will not invoke flipper.dent() towards the end of the auction, only if his expected return + gas cost will be below the market price. Since the gas costs are much below $97, the size of the Vault is not necessarily the dominating factor in the decision not to liquidate. We illustrate it with a numerical example. Suppose the market price of 1 ETH is 100 DAI, and suppose the gas costs for the liquidation process are $10, and that a debt of 100 DAI is up for liquidation. We claim that a bid of 0.870001 ETH could win. Indeed, if an opponent agent would offer a bid which is 3% higher, namely, 0.90000001, he will end up with a net loss, due to the gas costs. Even for higher gas costs, an 100 DAI debt Vault offers plenty of room to adjust to the gas costs in the liquidation process.

One could argue that the costs are bigger for the first agent, who also has to invoke cat.bite() and flipper.tend(). And that the potential advantage of bidding first is higher for bigger vaults, however this advantage heavily relies on current market conditions, and expected ETH/USD volatility in the next 6 hours (as it triggers 6 hour auction process). Hence, in many cases it might even be negative, and it is not clear why such a first agent would altruistically trigger the liquidation process even for bigger Vaults.

While the potential for profit is certainly larger for bigger Vaults, it is unclear how to determine the size threshold that guarantees a liquidation, or whether such a minimum size exists — due to a combination of gas, volatility, and competition factors. It could be that under some market conditions, being a Keeper results in a net loss over many game iterations no matter the size of Vaults liquidated.

Empirically however, there is sufficient evidence that in practice normal size Vaults do get liquidated. But it is hard to say if it is because the market can really estimate the expected profitability, or because simply few bots decided on some heuristics for minimum thresholds for liquidations.

When the incentives are not clear, the liquidators’ expected behavior is also not clear.

The upcoming MakerDAO liquidation 2.0 upgrade is expected to make the process much simpler and predictable. However, the incentives will only suffice when you analyze the process as a one shot game, where a keeper simply needs to decide on whether he should liquidate now or not. The reality however is much more complex, and in order to be able to backstop significant quantities in adverse conditions, such as during the Black Thursday, a keeper must prepare, months in advance, a complex trading and hedging system, that will allow him to enter and exit big positions.

To our opinion, the liquidation 2.0 system, as well as all existing DeFi liquidations systems (on Compound, Aave etc) do not provide sufficiently clear incentives for traders to build and operate such systems.

B.Protocol solution

With B.Protocol, a set of liquidators is chosen every epoch, and the genesis backstop is composed of the three biggest DeFi liquidity providers. Once chosen, the protocol eliminates all aspects of competitions among the liquidators, and lets them fairly share all the liquidations. In return to higher certainty, the liquidators are willing to settle for a lower discount and share their proceeds with all the users of the platform.

B.Protocol is currently live on mainnet with a MakerDAO integration. And during the experiment on November 8th we also opened a 120 Dai debt Vault with B.Protocol interface. Since this is a small Vault, it was assigned to a single liquidator, who knew already in the beginning of that hour that if the Vault will not be saved by the user, then he could liquidate it himself. Knowing exactly how much he expected the profit, and knowing the future governance might choose not to extend his liquidation franchise, the only rational outcome for him was to liquidate the Vault, as can be seen in this transaction.

About B.Protocol:

B.Protocol makes lending platforms more secure by incentivizing liquidators (keepers) to commit on liquidation of under collateralized loans and shift the miners extracted profits back to the users of the platform. B.Protocol was founded by Yaron Velner, who was previously Kyber Network’s CTO and a co-designer of the WBTC protocol.

For more, please visit our website, twitter, discord and github.