Harm mitigation in liveness faults

[zmanian]

This is paper by Tarun Chitra(@pluriholonomic) et al observes that a liveness fault in a dex creates the possibility of unexpected losses for liquidity provides as price movements during the liveness fault are arbitraged against price movements during the fault.

The gamm module should track the time between blocks and if it exceeds a threshold value (maybe 1 hr) to start out with it triggers a pause on the swap messages and only allows removing or adding liquidity from pools.

It would also be good to allow instantly unstaking/unlocking LP positions in the event of extended liveness fault.

[ValarDragon]

Beat me to writing an issue on it =) !

The goals here:

• Get price to relatively quickly match whats on external markets via low risk arbs
• Maintain liquidity in the system, so price isn't easily manipulatable post-price balancing. (Needed for lending & leverage)
• Lower LP losses

The current state of things:

• CFMMs (taken to mean every LP having an identical liquidity distribution)

  • Price rebalances quickly (effectively 1 tx)
  • LPs take notable loss relative to unbonding pre price correction.
  • Large amounts of liquidity remain post adjustment, keeping on-chain lending relatively safe.

• Orderbook style (taken to mean every LP can express a unique / concentrated position)

  • Price rebalances taken O(price change) txs
    • Unconvinced this is empirically going to be a multi-block process
  • Concentrated liquidity positions all essentially take their worst case scenario, as extreme losses, with no ability to adjust.
  • There is very little liquidity remaining post adjustment, leaving the entire system quite vulnerable to oracle gaming

---

The problem for CFMM LPs imo is mainly that the risk they took is going to give a lot of money to arbers, without them getting the opportunity to take a stop loss in the middle, or profit from natural volatility.

The problem for orderbook style LPs is that they are basically rekt, and have huge PGA wars to be first.

Solution ideas:

• Expose liveness / recovery as on-chain parameters
• For CFMMs: Drastically increase swap fee during recovery, to mitigate the loss's LPs will take to external arbs. (For a multi-hour downtime, I think 20% swap fee, relatively quickly decaying back to .3% is totally fine. Arb's should be willing to take that in order to get profit on that 80%, LP's lose much less, liquidity remains in system)
• For orderbook style things: Trades can be temporarily halted during recovery as you noted in the OP, and only allowing adjustment of LP positions. This effectively elongates the application liveness failure for trading, but gives block space / gas for sufficient LP position adjustments.
• I disagree with the notion of allowing early unbond breaks for liveness. I think at most they should get to discount the liveness failure duration from their begin unbonding time. (This is the explicit risk they took with bonding durations)
• During periods of recovery / liveness failure, allow large surges of block space/gas to be used. (Temporarily increase gas bounds & bytes / block) This allows for improved recovery of the orderbooks.

---

Architecture:

I would like for the following fields to built into their own module:

• downtime measurement window = {say 1000 blocks for simplicity}
• avg block time over last 1000 blocks
• downtime_amount
• chain recovery time factor (If chain has had duration D of excess downtime in last 1000 blocks, takes time recovery_factor * D to recover)
• is_chain_recovering(downtime duration D) (If a downtime of duration D has occured over last 1000 blocks)

And then other modules can import this. This should actually be of utility throughout modules in the code, and we should make things consistent.

Then in gamm, perhaps we only care after 1hr of downtime. Or maybe we even care at 10 minutes.

[zmanian]

Increasing the swap fee is a probably a better solution to downtime than shutting down the swap because it minimizes harm to other parts of the economy that depend on the liquidity

[UnityChaos]

👍 Definitely on board with dynamically increasing swap fees after liveness failure.

I think if done right this would basically trade a slowdown in price adjustment, for transferring the arb subsidy mostly from arbers to LPers. Having the swap fee start out really high and fall over a recovery window would create a falling price game for arbers, where they get a larger profit if they wait, but whoever goes first gets it. If arbing is competitive (or well automated), then we would expect prices to be arbed within swap fee bounds repeatedly over the recovery window.