Thank you for the interesting simulations @bingen!

In any case, assuming that there are deposits in the Stability pool (again, if there are not, the question doesn’t make sense), after all the liquidations, including those that were initially healthy but were dragged down to the undercollateralized zone because of liquidations, the system would end up with a TCR equal or greater than initially.

While it's true that the TCR would always become higher after the liquidations, there can be a significant difference by how much, since the new approach only uses a smaller fraction of the stability pool for absorbing debt. See these results for example

So this avalanche effect can never be a problem for the whole system, but only for risky troves.

Well, this is somewhat questionable. The closer the TCR is to 150%, the higher the risk that it could enter Recovery mode if the price of ETH continues to fall. On the other hand, restricting loss for Stability Pool depositors may lead to a larger pool, making the system more resilient in situations where there is a large price drop over the course of hours/days, rather than a flash crash which suddenly leads to unprofitable liquidations.

So this would probably encourage users to maintain safer ICRs.

Users that receive debt & collateral shares from liquidations may top up their collateral (or repay their debt), which should help as well.

from dev.

Temporary solution for the audited version

Ban withdrawal of stability deposits while there are troves with an ICR < 110%, and make it clear to the auditors that we are aware of the remaining problem of front-running the ChainLink price update transactions. We could also say that we deem the risk to be rather low since front-running will only be possible in very rare situations, where ICR < 100% (assuming LUSD is at par with USD). We could mention that we are also looking into the alternative of redistributing troves below 100%.

from dev.

Possible solution: Factor in time for deposits

Inspiration: rewards for liquidity programs.

The idea would be that the longer the deposit has been in the pool the bigger the rewards it gets.

A first caveat is that the time should be capped so that once it reaches the maximum rewards don’t increase anymore. Otherwise, over time it wouldn’t be appealing for newcomers.

The problem is that mixing time + cap with the current Sum-Prod solution for compounding seems quite complex implementation wise.

So for now, we are dismissing this approach and trying to find better alternatives.

from dev.

Possible solution: Limiting the maximum gas price

@cvalkan: We'd then need to have our own gas price price oracle, which we could e.g. do by keeping track of the moving average of the last k transactions.

@RickGriff: Yeah it could be a way to go for withdrawals. It's not so critical that we keep the flow of withdrawal txs high, as it is with liquidations

I guess we could track gas price for the last k borrower ops and stability pool ops, but not include liquidations. Then limit withdrawals to close to the average of k.

from dev.

Possible solution: Redistributing (instead of offsetting) unprofitable troves

@cvalkan: I haven't ruled that out yet, but I'm a bit skeptical as long as we haven't analyzed it properly.
At least it would enable us to market stability deposits as an essentially "risk-free" investment, which may lead to a larger pool in the end.
However, the pool would also be less effective, and its effectiveness would depend on the fraction of troves that are below 100% and the ones between 100-110% in a large black swan event.
There's also an effect where a redistributed trove would make >110% troves drop to 100-110%, which could then be absorbed by the stability pool. So, we'd definitely need to factor in the avalanch effect.

from dev.

So a naive "counter" solution would make a liquidation tx revert if it has been front-run by a Stability Pool withdrawal:

• Liquidations and withdrawal txs each increment the same txCounter by 1
• Users must pass the current counter value as calldata, to liquidation txs and withdrawal txs
• When a liquidation is processed, if the txCounter > calldata counter, the liquidation reverts

There are a couple of problems with this though: it reduces liquidation throughput, and is vulnerable to griefing attacks (many small withdrawals).

Anyway, there's a simpler solution you mentioned Robert, where we just restrict deposit withdrawals if there are troves in the system at <100% ICR.

Then, the issue shifts to front-running of the oracle price update.

from dev.

Possible solution: Timestamp comparison

This is a variation of the notification period idea - instead of checking whether the depositor waited long enough, we check that sufficient time passed between their initial withdrawal tx and the next "unprofitable" liquidation.

We have a two-step withdrawal process. 1) The deposit can be withdrawn instantly, any time, and 2) the ETH gain can only be withdrawn after some fixed delay period d.

• Upon a withdrawal, record the timestamp t
• Track the timestamp of the last "unprofitable" liquidation (ICR < 100%). Let's call this l
• When depositor attempts their ETH gain withdrawal (step 2)), compare their withdrawal timestamp t to the last unprofitable timestamp l. If they're too close together, i.e. (l - t) < minDuration, we consider it front-running, and they lose all their ETH gain.
• After d ends, their is a limited withdrawal period w, in which the depositor can pull their ETH gain out. This ensures they can't just wait indefinitely for further unprofitable liquidations to occur, and make (l - t) > minDuration.

It's clunky though.

The main problem I see is a depositor might accidentally get penalized, if they happen to withdraw their deposit just before an unprofitable liquidation.

Also, some front-running may be missed, if a second unprofitable liquidation occurs after the minDuration, but within the withdrawal period w.

Though I do think overall it would mostly deter front-running: if you front-run unprofitable liquidations, there is a good chance you lose all your ETH gain.

Maybe food for thought... but I like it less now that I wrote it out explicitly, actually.

from dev.

When depositor attempts their ETH gain withdrawal (step 2)), compare their withdrawal timestamp t to the last unprofitable timestamp l. If they're too close together, i.e. (l - t) < minDuration, we consider it front-running, and they can't lose all their ETH gain.

I don't quite understand the rationale of this. Front runners want to get their transactions processed before the unprofitable liquidation, but here they are penalized for being too late. Is this a probabilistic way of penalizing front-running, assuming that a significant fraction of those front running attempts will fail?

Possible solution: Two-step withdrawal process with a simple notice period

We have a two-step withdrawal process. 1) The current ETH gain can be withdrawn instantly, any time, and 2) the LUSD deposit (as reduced by further liquidations) can only be withdrawn after some fixed delay period d. Further ETH gains that accumulate after the withdrawal are split between the depositor and the stability pool

1. On withdraw(), the system records the current time (or block height) and pays out the pending ETH gain to the depositor, withholding the LUSD deposit. The ETH gain payout is recorded as well.
2. Liquidations affect all deposits, including the ones that have already been market as "withdrawn".
3. On confirm(), the system checks if the minimum waiting period d has passed, and if yes, returns the deposit (as reduced by liquidations that have occurred in the meantime) to the depositor.
4. In case of liquidations upon withdrawal, x% of the ETH gain that has accumulated since the withdrawal is returned to the depositor, while (1-x)% is fed back to the stability pool. The recorded ETH gain from step 1 allows to calculate the accumulated ETH gain, without needing to take new snapshots of P or S.

If we set x to 0.909 (or slightly higher), there won't be a real penalty in the sense of a net loss on average, since a deposit marked as "withdrawn" would only lose the collateral surplus gain. In other words, the LUSD that is taken from the deposit is replaced by an equivalent amount of ETH.

This should discourage borrowers from leaving their deposits in a withdrawn state for a longer period of time. Loss evasion by front running is still possible, but it would also lead to a loss of the gains.

from dev.

Bingen is going to analyze the direct redistribution approach.

from dev.

Possible solution: Redistributing (instead of offsetting) unprofitable troves

After some simulations for this solution, it seem promising, for the following reasons:

• The avalanche effect gets smaller the farther the TCR is above 150%. If it was below, the question makes no sense because in Recovery mode it already behaves that way (actually, as @danielattilasimon pointed out, this similarity is another upside of this solution)
• In any case, assuming that there are deposits in the Stability pool (again, if there are not, the question doesn’t make sense), after all the liquidations, including those that were initially healthy but were dragged down to the undercollateralized zone because of liquidations, the system would end up with a TCR equal or greater than initially. So this avalanche effect can never be a problem for the whole system, but only for risky troves. So this would probably encourage users to maintain safer ICRs.
• The implementation is simple, and we already have it for Recovery mode (as mentioned before)
• The probability of having a system with a TCR over 150% but at the same time having a significant amount of troves under 100% seems low. With this I mean that if the downside is only that the Stability Pool is less effective, or any other “minor” thing, but it has not any security implication, I think it would be reasonable to adopt the solution given that the implementation and the UX is simpler.

loss_evasion_frontrunning_with_SP_TCR_120.pdf
loss_evasion_frontrunning_with_SP_TCR_150.pdf
loss_evasion_frontrunning_with_SP_TCR_200.pdf

from dev.

This:

Ban withdrawal of troves with an ICR < 110%

should be:

Ban withdrawal while there are troves with an ICR < 110%

right?

from dev.

Yes, just fixed it.

from dev.