You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As discussed, we want to have a dynamic gas price, based on a per-stream
priority
.TL;DR
Suggested mechanism:
Set priority:
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:
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.
The text was updated successfully, but these errors were encountered: