ZRX,BAT, and WBTC Parameter Update

11

I understand Gauntlet is a company and can’t give up the “secret sauce” to their analytical methods. But I’d love to see more specifics on model inputs (+ maybe outputs). Eg for the liquidity and volatility data, which specific sources are used and what is the method of computation for aggregate final numbers. Or any probability distributions of expected losses (net insolvent) so people can understand the nature of the risk to the protocol (eg thin or fat tail).

It’s tough for me to get fully behind the proposal when I can’t inspect the underlying model assumptions.

3 Likes
12

Hey - we’re looking into the recent liquidations but in the spirit of sharing data, we published some quick numbers to Google Data Studio and made the link public for people who are interested:

We saw some liquidations, but just as a reminder, our stress tests are focused on worst-case volatility, like we saw last March. It was a tumultuous couple of days, but nowhere near as bad as we saw last March. I grabbed this quick chart from BitMex to help visualize:

image
image929×474 61.6 KB

Definitely let me know if you see anything interesting in the liquidations data!

2 Likes
13

@jmo

I respect and appreciate your suggestions, which are always backed up by numbers.

This proposal is a big part of Liquidation
I think we should take all possible measures to prevent users from liquidating, including publicizing it on social networking sites and displaying it on the website!

2 Likes
14

We’re going to move forward with a proposal here. We realize that lowering collateralFactors can cause liquidations and should not be done lightly, however the risk posed to the protocol due to WBTC insolvency is too great not to take action. We’ve re-run the simulations with updated results:

image
image697×680 22.3 KB

These results show that risk in the protocol continues to increase as volatility continues to stay high and WBTC liquidity actually appears lower than it was last week - our last stress tests assumed 250mm daily volume for WBTC and these most recent results assume ~120mm:

image
image1753×984 32.9 KB

We’ve included all of the liquidity assumptions above as @monet-supply requested. We also have updated our suggest parameters to avoid liquidations, as more people have been taking advantage of the higher collateralFactor.

Collateral Current collateralFactor Recommended collateralFactor
ZRX .60 .65
BAT .60 .65
WBTC .75 .65

By lowering the CF for WBTC to .65 instead of all the way to .6, we can limit the immediate effect on borrowers. Some quick numbers here on liquidations for different values of WBTC:

70: [‘0xfa8c56fd100c7c55ef39e0af075c618b59714f91’, ‘0x1702f2d0df7c99011a690461c34e51bd81cbab48’, ‘0xd762205476ea5649c689a8a703488572c8b3007d’]
Total collateral: 4,729,790.58 USD
NOTE: FIRST ONE IS LARGEST (4.7MM) AND IS RECURSIVE WBTC

65: [‘0x15200b08325069ea4edd0cec4baf75853b200b5c’, ‘0x3f9a8d828ebc441eb1ad6942118586f331454743’, ‘0x51a33a5bba82f8ebd0fe2192a25ca2e60b9dc32f’, ‘0x59149937397a77368a3a37ee359d1ff61d9df011’, ‘0x61f5d50cdf7813190d125c0e32b195c6fc0f6ffd’, ‘0x8877889ff4a0fa0415d7572cbc871ede200e2f78’, ‘0x8fd1fa7ba628a0a170ae53139552dbd1aec9c22b’, ‘0xd749940ac368792ffb33745653cb1e7b7d0b7a17’, ‘0xddef74bd1ef4915546ee9371928123475eb2a354’, ‘0xf14662b6b7edfebe645d783afef03a6ce615dfe0’]
Total collateral: 9,821,799.23 USD

60: [‘0x071341196d71b14f04b84463f9b9b56f3b5ed333’, ‘0x2898e036dcaa7a94ea96761193cbe6c54d587bc5’, ‘0x29664e652ca8f8f2d95de3b33cc0ae7247fc0aa9’, ‘0x39f230c044c2a9a67ae95caac639e67145e533a7’, ‘0x3d624933c49df28059d07f950254abb92aa4dc8b’, ‘0x44428c4cfbe9e319ca00a5d955a417f4b6e080e9’, ‘0x444e01dcb3a1ec1b1aa1344505ed7c8690d53281’, ‘0x505008a654c321d93b7d2ebdf6389aaa876b16ab’, ‘0x5140c2e3be04d48e9b7c5fdf016bbea6a88b2b65’, ‘0x57d1e246d2e32f6f9d10ec55fc41e8b2e2988308’, ‘0x59f075a6a9a11b4437d33c0cddb6f5226a4bea87’, ‘0x63dcafd6b547e7cfb2e67386db3d06d67aa71c49’, ‘0x78b58e4197c04d320a33c582ecc3e7e885f26a58’, ‘0x7cd982fdbeaa7a3d13de73d50e2030fde2aba3e1’, ‘0x815afec2721dc50ca75c633906147a46c439e52e’, ‘0x8626e72944f62aad5d85e60b8d34471f7d5ef980’, ‘0x8b349d17392f266d87d518bf71426b2921cc35ee’, ‘0xb145ed57fdf5b6f4fc7d8ec9a2f03026a218f000’, ‘0xbececc0d46b3f06b0096c6b2bbc6e429fe7bd911’, ‘0xc8ebbaaad5ff2e5683f8313fd4d056b7ff738bed’, ‘0xcc60721776b70023ae3196b3a9994e911aa66854’, ‘0xd28bfaea8c886ff6424141278a928f3cde2741f1’, ‘0xe24286adfc053f76888aa51d9a94f6c1519b4cba’, ‘0xfd4bb054392dcd5acb07be4d9e287c7684c87606’]
Total collateral: 33,722,887.95 USD

Obviously, we could lower the parameter in smaller increments, but as proposals take 5 days, this is too slow as the current risk level is so high.

6 Likes
15

Proposal is live: CP039!

2 Likes
16

Just a quick question. Since I don’t see adresses duplicate at 65 and 70 CF, i assume assets for liquidation at 65 CF do not include assets going for liquidation at 70 CF? So basically if CF is set to 65, then we going to put 4 729 790 + 9 821 799 for liquidation?

I still believe decreasing CF in steps is more responsible action: lowering it to 70 first with second followup proposal lowering it to 65 going next would be a better approach.

If timing is critical, than second proposal could be put to vote before first one finish, giving it 24 to 48 hours delay after first proposal put, to give time for borrowers to adjust their positions after execution of first part to avoid being put for liquidations.

As for everything in general i think it should already be put to vote, as not much remained to discuss here really. I think all main arguments are already being presented. I still not really convinced about liquidity assumptions your model gives. As i look at that massive onchain liquidity for wbtc-eth (Uni 355M + Sushi 729M + 1inch 535M= over 1.5B) and it’s hard to believe that even 100M trading volume = low liquidity. Besides for last 24 hours only uni and sushi created 37M+38M = 75M of WBTC trading volume, so 125M doesn’t look accurate at all. Could all CEX combined generate less trading volume for WBTC than only 2 DEXes alone.

Yet, i believe, lowering CF is still good idea, as WBTC market is huge on Compound, and after all the bull run it would be smart to stay on safe side, and decrease amount of risk users could take on WBTC. So i’m for your proposal, just not quite convinced by the arguments of low liqudity.

However, I’d say better be safe than sorry, so if your model say that we should derisk WBTC market, than we should. Maybe your model is somewhat right, who knows.

4 Likes
17

I’m very happy to see this proposal go live. I think switch to 65% for this was a good compromise on reducing the impact of this change.

1 Like
18

Can you share what exchange/markets you are using to get the ~120mm daily volume?

19

Binance
Uniswap
Sushiswap
etc.

The only market with any real volume not included is Curve , which accounts for 10-30mm in volume. So best case, the current collateral would blow through the collective order book 4 times instead of 5 times, which is still, very very bad

20

Looks like it is missing the below:

  • 1inch

  • Curve

  • Bancor

  • Balancer

  • Dodo

  • FTX

  • Bitgo mint/burn

  • Coinlist

1 Like
21

@getty How much liquidity do you think there is? We ran the earlier sims with an assumption of 258mm volume and the results were still clear - WBTC poses a huge risk to the protocol. We can talk about exchanges all day but the question is - why do you think the protocol is safe? Sure, we can add more features to our model, but shouldn’t the protocol move forward with the best information it has? The question I have for people who oppose this is not “what features should we add?” but “how could you possibly think this is safe?”

22

Fair question

Stepping back for everyone reading this thread, I want to explain the scenario where the protocol loses money. If any loan goes to liquidation and the collateral value (minus the liquidation incentive 8%) is below the value borrowed, the protocol will take on losses. An asset with 75% CF has ~17% of wiggle room. Although, once a loan goes to liquidation, it will likely be eating into a portion of the 17% cushion immediately.

For the protocol to lose money someone needs to have a loan reach the liquidation point, for there we either need a liquidator not to liquidate or we need the market to gap ~17%, and then the protocol starts taking on water. I am not going to say this is impossible, but it is very unlikely. Liquidators are highly incentivized to liquidate loans, and users are incentivized not to get liquidated. The primary concern that users/protocol can’t control is if the market does, in fact, gap ~17% in 10-30 minutes.

Having worked in crypto full-time for the last +3 years as a trader, I have seen significant volatility and understand the danger of cascading liquidations. I have also seen the market rapidly mature and develop liquidity.

Why do I think it is safe:

  • The available liquidity for WBTC onchain and offchain is unmatched by any coin on Compound other than ETH & the stables.

  • I have researched the primary WBTC accounts, and they are all far away from liquidation, and I know many of them will go to great lengths not to be liquidated.

  • I have minted and burned significant amounts of WBTC and am familiar with the significant OTC players.

  • I have researched and participated in many of the WBTC onchain and offchain exchange/pools to know what is and isn’t possible.

I deal in reality and function and less in theory. With the state of WBTC liquidity and the state of accounts using WBTC on Compound, I think it is safe. Are we taking a risk, yes. It is a risk worth taking, yes.

If I had more time I would love to write a more detailed post, maybe next time this goes to governance I’ll try to write something more formal.

My primary concern is that the oracle price does gap, which causes underwater loans and protocol debt. That is why I am pushing for oracle improvement because the current Coinbase and poster situation is not acceptable.

23

I’ll go as far as to say that hoping users top up collateral during a downturn is not a great way for the protocol to mitigate risk.

These anecdotes are helpful in understanding your experience, but to be clear, we at no time intended to question anyone’s expertise as a trader. What we are trying to do is build the best model possible, over time, and get community feedback while we do so. I think one piece of feedback that is clear is that we should include liquidity from Curve, and we’ll continue to look into that.

Now our model focuses on liquidation cascades, which are a real concern given the quantity of WBTC on Compound. While you present interesting feedback on our model, it’s not clear to me how you have taken into consideration these cascades or any of the other things we included, like gas price spikes, price correlations between borrowed and lent assets, etc. We know our model is no perfect - not model is - but it feels the counter argument is to throw the baby away with the bathwater in favor of finger-in-the-air reasoning.

24

I don’t take your comments personally, so no concern there. I know we all want what is best for the protocol. I kind of treat it like arguing with friends/family. We might get a bit dirty and harsh but generally, we all like one another.

I truly wish I had the time and resources to build my own risk model so it does seem like “finger-in-the-air reasoning” because I certainly don’t feel like that is what I am doing but I can understand if that is how it comes off. I care deeply about these parameters and understand that what we do with them can have big implications.

While I haven’t built a model to handle gas price spikes, looking at price correlations and user’s accounts is fairly easy to do. As complicated as this process might seem only a few things really matter: users’ accounts, liquidity, and liquidators.

We should focus on protocol growth and robustness instead of limiting it. I believe we can grow the protocol and make safer at the same time.

1 Like
25

Actually, i would like to suggest different approach with WBTC situation. There’s one thing i don’t parlticulary like about WBTC on-chain liquidity, is that ever since Uniswap introduced WBTC-ETH pair to their liquidity mining program, that became main focus, and most incentives introduced later incentivese that particular pair.

And of course, everybody like it, btc and eth grow together, fees from trading accumulating and some incentives are on top. All great till it drops. And we know when it crashes it crashes all together. That pair isn’t really ideal for Compound liquidations, and since Compound WBTC market is so big, it actually create risk for all DeFi ecosystem. If Compound WBTC market could be pushed into liquidations deep enough, it can potentially send all DeFi on a quick ride to goblin town.

To create some sort of stability anchor for facilitation of liquidations Compound needs liquid enough WBTC-USDC pair on-chain. Like hundreds of millions size.

I would advocate for Compound to create liquidity incentive program. To decrease distribution of COMP from USDC and DAI markets, and forward that portion to staking LP Uniswap WBTC-USDC. I think that is in best interest of Compound, as well as DeFi ecosystem overall.

2 Likes
26

So I know there has been a lot of talk about liquidity assumptions, so we went and updated our data input pipelines to just assume much more liquidity for WBTC (350mm as opposed to 120mm):

image
image676×672 20.8 KB

If liquidity is actually much better than we assume, then the expected WBTC losses to Compound in a Black Thursday event are around $40mm instead of closer to $100mm. But this is still more than 10 times the risk across all other assets combined.

27

A couple of points, some may have been repeated in some form by others:

  1. Your model seems to be extremely sensitive to liquidity assumptions and your liquidity assumptions seem a bit off to me. Baseline you have COMP ($140MM) as having more liquidity than WBTC ($128MM) and UNI ($610MM) having 5x more liquidity than WBTC on chain. Checking 1-inch right now, WBTC has far lower slippage than either asset for large transactions (a $50MM trade to USDC incurs 14% slippage for WBTC, 40% for UNI, and 73% for COMP). This seems to be the biggest weakness in your simulations in my opinion. Going from $128MM to $350MM is a good step but arguably, WBTC should be rated at a liquidity level above UNI.

An additional consideration on the liquidity front: WBTC is a proxy asset off-chain because for most exchanges, people would prefer to trade BTC directly rather than WBTC. People only trade WBTC when they want to shift dollars or BTC onto the ETH chain. So WBTC has infinite ‘shadow’ liquidity because liquidators can hedge WBTC risk with BTC reasonably well, although during a stress event, that may be less true.

  1. Regarding your simulation mechanics, is it happening at the account level or the aggregate protocol level? I think the former approach would be a fair bit more accurate depending on the distribution of collateralization among top accounts.

Overall, I think you make a reasonable point that Compound is taking on some extra risk with WBTC but I don’t think it’s as drastic as you think it is. And as a common sense test, assigning WBTC a factor of .6 or .65 (equivalent to BAT or ZRX) seems off as WBTC is probably more liquid than either asset by an order of magnitude at least.

I think the real risk you’re highlighting is the size of the WBTC market, so you may want to consider managing risk by targeting that variable instead.

1 Like
28

That’s not really good argument. You see, thing is in the event of liquidation, liquidator need to quickly sell WBTC, not BTC, as that’s what they get from collateral, and while technically it’s possible to directly redeem WBTC for BTC and vice-versa, even non-custodial, via RenVM, it takes some time, so liquidator need to have a lot of capital and willing to take bigger risks to be able to actually use that strategy. Usually it’s not the case, liquidators turn to go for “quick buck” by selling ASAP, getting their comission and be done with that. It’s not the most efficient, and likely not the most profitable way to do it, but it is how it is now. Thus they commonly sell literally at bottom and use huge gas fees also, sometimes far above any reasonable level (like customer pays, so who cares).

As for comparison with BAT and ZRX: size matters. WBTC dwarfs BAT and ZRX in size, even if you combine BAT and ZRX together and multiply it by 9, you still wouldn’t reach size of WBTC collateral. So it presents much more complicated task at liquidation.

Gauntlet simulation assumes there might be a need for market sell several hundreds of millions of WBTC, and trick here is it shouldn’t push price down that much, so 25% margin, collateral have, would be enough to cover liquidation and fee.

There is good reasoning behind Gauntlet concerns after all, even if we believe that their model isn’t quite accounting for on-chain liquidity.

And i think if they wouldn’t try to push it too much and too fast, it would get much more community support. We all can agree that after all, WBTC liquidity isn’t quite good as ETH. Just for a simple reason that very big chunk of on-chain WBTC is tied to ETH, rather than to stable coin. So there going to be another hop, through ETH to reach stable coins, and ETH would be falling too in simulated conditions.

I think it’s surely reasonable to decrease CF for WBTC from 75 to 70 just to get bigger margin in case of market crash. (actually it would probably be better there to begin with, and not going to 75 increase at all)

And maybe even from 70 to 65 as a followup, though i feel less certain about second decrease.

You see, in theory, after such a big runup, we should expect people taking more caution, and keeping less leveraged positions, but even if decrease to 60% CF creates about 30M of liquidations already it’s clearly not the case. 30M might not look big in comparison to overall market, but market sell even of that size would still create noticeble down price movement.

1 Like
29

In my opinion it was a bit shortsighted from you to include the WBTC parameter update in the same vote as the ZRX and BAT adjustment, considering that the WBTC parameter was just recently adjusted and the ZRX and BAT adjustments failed.

It would not surprise me to see this vote fail because of exactly this reason. Please consider to split numerous adjustments in separate votes in the future, especially if they alter recently deployed changes or include recently failed votes, as this will reduce obscuration and give a clearer picture of sentiment of voters in the protocol.

Consider this also in regards to the health of the protocol, as your deployment of this vote will now delay future votes until this one has passed, and we will be starting again at square one, without a clearer picture of why exactly it failed (if it fails), other than to go by the forum sentiment.

1 Like
30

One thing to note - we can only propose changes every five days. This is how compound governance works. There are over 50 parameters controlled across the 8 lending markets (9 incl. USDT) and you need to change these more than once or twice a year.

The community needs to be able to vote on what’s best for the protocol. If on principle, you only vote for changes that affect one parameter at a time, you will be most likely voting against the best interest of the protocol. It’s not a vote against the changes, which would be fine, it’s a vote for stasis