Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic gas price cap #1

Open
d10r opened this issue May 29, 2024 · 0 comments
Open

Dynamic gas price cap #1

d10r opened this issue May 29, 2024 · 0 comments

Comments

@d10r
Copy link
Collaborator

d10r commented May 29, 2024

As discussed, we want to have a dynamic gas price, based on a per-stream priority.

TL;DR

  • priority is defined per stream to be liquidated, not per account (current code architecture doesn't accomodate that)
  • don't use priority buckets, but proportional mapping
  • just one execution queue

Suggested mechanism:

Set priority:

    if account netflowrate negative:
      if account insolvent: priority = NORMAL + k*flowrate
      else if account critical: priority = LOW + depositconsumed_share * k*flowrate

This is optimized for the current Alfafrens pattern. Allows accounts to remain critical or even insolvent as long as the net flowrate is not negative.
The use of flowrate as multiplier instead of just a few buckets allows to catch attempts to steal from the protocol during times of congestion. E.g. even if a liquidation were 10$, it should be done if it can prevent protocol debt of 100$.
k is to be set based on token value and a subjective opinion about how to map flowrate value to liquidation cost. As a rule of thumb, I suggest calibrating such that at NORMAL priority the liquidation tx cost matches the deposit value - thus 4h of flowrate.
NORMAL priority shall map to a value of 100.

The reason for including depositconsumed is to allow to take advantage of gas price fluctuations during the critical period.
This simple mechanism should have a net positive effect provided that the gas price value matching LOW and NORMAL prio do indeed statistically map to reality.
In a further (future) optimization, the application should keep observing the gas price and dynamically adjust this reference points. For a start, we can derive them from a static config value.

Run liquidations:

loop:
  get list of streams to be liquidated, ordered by priority desc
  get current gas price
  get subset of streams to be liquidated, where getGasPriceCap(priority) < current gas price
  chunk and run

NORMAL=100
LOW=30
gasPriceCapNormal = priority / NORMAL * NORMAL_GAS_PRICE

This is flexible and makes sure at any given gas price point we execute exactly what's worth executing according to the defined priorities.
Also the execution of highest prio liquidations first minimizes the chance that our own activity prevents high-prio liquidations coming later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant