Hi everyone, I’d like to first make an attempt at summarizing a couple of the concerns expressed by others in this thread, including @lay2000lbs @tonyotonio @ekrenzke @franklin-pantera that might have resulted in this proposal not gaining the required support:
- Some of the largest liquidated accounts were using the protocol in a way that is not intended, and displayed behavior not well aligned with the long-term interests of the protocol (aka Recursive farmers, wash lenders)
- COMP is a governance token, any compensation should come from the DAI reserves
With that in mind, I have been working on an idea for which I would like to solicit feedback from the community, on its soundness and on if it’s considered worth pursuing further.
I’ve done some work to discern the accounts that were engaging in farming and to what extent if they were. By using the following formula we can quantify this for any Compound user. Let’s call it recursive factor for lack of a better name
Where:
t = Tokens the user has borrowed or supplied as collateral
CFactor = Collateral factor for the token in question
Supply,Borrow = Self descriptive for the token in question and converted to Dollar value
A couple of examples might help to illustrate how this works out:
- Alice supplies 10M DAI, subsequently borrows 7.5M DAI, then recursively does this again and again, and ends up with a total supply of 40M DAI and total borrows of 30M DAI. The collateral factor for DAI is 0.75, so Alice would have a recursive factor of 1
- Bob deposits ETH for 10M worth of value, borrows 7.5M DAI, exchanges the borrowed DAI for ETH, which he again deposits to the protocol for another DAI loan, and so forth until his account ends up with 40M worth of ETH supplied and 30M worth of DAI borrowed. Bob is leveraged up on a long ETH and short USD position. His recursive factor is 0
What determines the recursive factor is not how leveraged up a position is, but what proportion of their supplies and borrows are in what we could call “wash loans” which serve no seeming purpose other than farming COMP. So for the purposes of this metric, all stable coins in the system are counted as a single asset. Another example might illustrate this point:
- Carol supplies 10M USDC, subsequently borrows 7.5M DAI, exchanges the borrowed DAI for USDC, then recursively does this again and again, and ends up with a total supply of 40M USDC and total borrows of 30M DAI. The collateral factor for both DAI and USDC is 0.75, so Carol would also have a recursive factor of 1
I analyzed all the liquidated accounts using this proposed metric, and have created a spreadsheet with the results. The columns in green are there just to demonstrate the formula described above. All the supplies and borrows are using coingecko USD prices for the day of the liquidation event, except for stable coin prices which I fixed at $1, and all account values are taken from a snapshot at block 11332733 which is 1 block before the first liquidation. I’d of course happy to share the code used so that it can be properly audited by the community.
A summary of the results is that out of 122 distinct liquidated accounts, 87 have recursive factors of basically 0, and only 29 have a recursive factor greater than 0.50.
I also added a column that computes one possible compensation scheme based on this recursive factor that results in a total compensation of 2.22M as opposed to the 6.8M originally proposed. There are other ways to use the recursive factor to compute possible compensation, and I don’t think this one is necessarily the ideal one, I added this one simply to get an idea of how much recursive farming could impact the proposed compensation.
It’s worth noting that both the supply and borrow columns for assets have been converted to USD value using the coingecko prices for that day, and the supply columns have been multiplied by each asset’s collateral factor
The spreadsheet in question can be accessed here
I’ve also made a simple web app that generates account history charts, as shared in my posts above, and also computes the recursive factor for any account, which can be accessed here (It requires a browser with Metamask).
In addition to sharing the code used for this, there is further possible work that has been suggested by different members of the community, which might also be relevant for deciding on possible compensation schemes.
- Calculate the prices of liquidations, as some accounts that had non-DAI collateral seized lost more than the 8% liquidation incentive.
- Calculate what accounts would have gotten liquidated on that day due to other collateral assets crashing in price, had DAI remained at parity with the global market price, and to what amount they would have gotten liquidated if that is the case
- Check if there are other accounts that might have gotten liquidated due to the DAI price, but for which the liquidator might have repaid a non-DAI loan. These would not have been included in the originally shared liquidations spreadsheet.
I appreciate any feedback here, and if there’s some form of soft approval from the community, and no important issues with what I’m proposing, I’m happy to continue work on next steps, including possibly creating a new formal compensation proposal.
Finally I’d like to sincerely thank @kybx86 for getting the ball rolling, not only on a proposed compensation, but I think more importantly on starting to address the issue of DAI market risk the protocol currently faces.