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
/*
TODO
Note that this will only force the exponential thing for the _first_ candidate
that gets sent off to the smart contract. If more candidates are added to
later bids, the condition no longer necessarily holds.
To make it apply to those cases as well, (1) the logic would have to be moved
elsewhere (probably to the `cacheTransaction` function) and (2) upon addition of
a new candidate, check whether that new candidate is the most profitable
(idx 0 in the `borrowers` array). If it is, then have some logic that decides
whether hopping up to a new exponential curve makes sense given how close/far
we are from `maxFee`
*/
This can be fixed while still only caring about profitability of the best candidate. That said, we should probably look into other ways of optimizing transactions for maximum profit. It may be possible to liquidate a bunch in a single transaction and save on gas, making something profitable that otherwise wouldn't have been. This is especially the case with Chi, because Chi adds too much overhead to be super useful for a single candidate, but that overhead is constant -- so if we liquidate many candidates, the overhead is the same, but the gas savings are much larger.
Note that changing this will require changes to both TxManager.js and Liquidator.js, as both make assumptions based on the "best candidate only" heuristic.
The text was updated successfully, but these errors were encountered:
See the following in TxManager:
This can be fixed while still only caring about profitability of the best candidate. That said, we should probably look into other ways of optimizing transactions for maximum profit. It may be possible to liquidate a bunch in a single transaction and save on gas, making something profitable that otherwise wouldn't have been. This is especially the case with Chi, because Chi adds too much overhead to be super useful for a single candidate, but that overhead is constant -- so if we liquidate many candidates, the overhead is the same, but the gas savings are much larger.
Note that changing this will require changes to both TxManager.js and Liquidator.js, as both make assumptions based on the "best candidate only" heuristic.
The text was updated successfully, but these errors were encountered: