GUSD - how to address deppeging concerns

The recent events around Gemini and GUSD is a good opportunity to discuss the infrastructure that would allow the Gearbox community to promptly react to deppeging events.

We first give an overview on the recent news about GUSD, then discuss how it can be monitored, and mechanisms that allow for prompt responses.

Recent events

Gemini dollar (GUSD) is issued by Gemini, a New York trust company regulated by the New York State Department of Financial Services.
Last weeks there were 2 events the raised some concerns on its stability:

  1. Genesis trading filed for a bankruptcy, and reported that Gemini is its biggest creditor, with over $600m exposure.
  2. MakerDAO had a very tight community vote to off-board GUSD from its system. Had the vote passed, it would result in a massive redemption of $0.5b of GUSD.

While these news are somewhat alarming, the insolvency of Genesis, and the exposure of Gemini were already known. Further Gemini CEO repeated his early statements about the segregation between Genesis trade, and the Gemini company (and GUSD, which, according to his words, is not a property of the company).

Further, even a minimal decrease of the GUSD liquidation threshold in Gearbox would have result in liquidations of over $3m.
Hence, during this period of time, the RiskDAO did not issue a strong recommendation to take any actions. However, the situation is on-going, and it is a good opportunity to discuss on the infrastructure that would allow the Gearbox community.

How to monitor stable coins

The DeFi stable market (including custodial coins like USDC, USDT and GUSD) is dominated by Curve finance price formula. While these coins are also traded on centeralized exchanges and on uniswap v3, it is eventually the passive curve liquidity that dictates the price (as opposed to the active binance and uniswap v3 liquidity).
Further, curve formula is asymmetric, so when the price pegs away from 1, the effective liquidity is getting smaller, which in turns, contribute more to the future deppeg.

The graph below shows the USDC/UST liquidity changes that led to the eventual deppeg.
The timelines are in millions of blocks.

Other than dex liquidity, we also measure the backing of the entire coin, however this is relevant only for decenteralized stables such as LUSD and sUSD.

Finally, like for all other assets, we also check for open liquidations and big accounts.
However, our system is not real time, and parts of these checks are only executed daily.

A more robust backend can be built that would track, in a real time manner:

  1. DEX liquidity - with focus in uni v3 and curve.
  2. Decenteralized stable backing.
  3. Open liquidations.
  4. Big accounts.

We note that (1) would naturally also alert when the price deppegs, as a sharp liquidity drop would precedes it.

Our code is open source with an MIT license, and we would be happy to provide it to gearbox backend team as a reference and use.

Further, it is also important to monitor crypto news and twitter. We are investigating an automatic system for it, but currently it is at a very experimental phase.

How to react

Currently the only allowed promptly reaction is to freeze the operation of the contracts.’
This makes sense in catastrophic events, such as chainlink oracle errors.

A more standard response to an increase of risk is to:

  1. Reduce the liquidation threshold; and/or
  2. Decrease the total collateral cap for this asset (will be supported only in v2.1)

The daily stress tests we run are trying to predict the behaviour also under tougher market conditions, but of course cannot fully model the likelihood for big accounts or to concerning market news.

One way to improve the response time is for the community to nominate a multisig with a clear mandate to promptly react to new events.
The on-going events around GUSD makes this discussion not only theoretical.
I think the discussion should focus on 3 possible actions:

  1. Do nothing
  2. Have a multisig with a clear mandate to act quickly for a given objective/measurable metrics (e.g., dex liquidity change). And RiskDAO can work on accurately defining these metrics.
  3. Have a multisig with a mandate to work also based on fud and news. This is somewhat of a slippery slope, but the current GUSD events are a good example for how an action might be needed, despite the fact that nothing tangible happened.
4 Likes

depeg insurance though etherisk DIP? wouldn’t do the job ? or to complicated?

I feel having a multisig with clear mandate and focus on key metrics to give a go ahead to changes to take place would be nice … but what would be an ideal response time for such a multisig ?
ImmuneFi used to offer a War Room kind of service … not sure if they still do ? would be interesting to compare cost vs multisig.

This is not live yet, right? Once it is, then it depends on how much it would cost.

The ideal response time is 0… But in practice even 24 hours response time is better than the current state.

I am not familiar with immunifi war room service, could you share some material on that?

what size of multisig would be appropriate for this? Balancing the risk of too slow a response vs the (very real, but less quantifiable?) risk of some kind of capture of multisig members, by hacks, legal, or just plain old corruption.

Would be interesting to look at existing multisig response times on financial/tech multisigs as a comparison as well

1 Like

Aave has a guardian multisig with 6/10.
Compound’s guardian is 4/6.
But these are only for pausing operations, not changing parameters. And I do not know if they were ever put to use.

Following their CRV bad debt, there is an ongoing discussion there about setting up a risk council multisig that could also change liquidation thresholds with 4/6. See here.

Note that (afaik) gearbox already has the guardian functionality, and this proposal is more of the flavour of a risk council.

Imo, the current gearbox multisig is assumed to be trusted enough to execute the community decisions, but I do not know how how quickly it can respond (maybe @RV_ivangbi could shed some light on that).
So the question here is more about the size of the group of people who could make the decision and convey it to the multisig, and not the size of the multisig itself.

As a basis for discussion, maybe having RiskDAO with one vote, gearbox core team with one vote, and a community member (selected by the community) with another one vote is a reasonable structure.

1 Like

According to GIP-17, the pausing of the system is not an issue in response time - it’s instant. For unpause is different, it’s 3/10 with the same set of signers as during GIP-17, so the response time on both should be VERY quick.

As for liquidations during crises, I believe I heard once devs discussing a separate role for that, but can’t be sure. Rules are not yet fully set u for that, which they need to be? cc @apeir99n @0xmikko @Van0k

I have thought about this many times, I think I almost never sleep at a time when many sleep. I also keep my hands on the keyboard. Therefore, I could be useful and respond in time in such a situation. I am not a developer and will not be able to initiate, but I can definitely be the one to quickly sign.