Nantucket icon indicating copy to clipboard operation
Nantucket copied to clipboard

TxManager only cares about most profitable candidate

Open haydenshively opened this issue 4 years ago • 0 comments

See the following in TxManager:

/*
    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.

haydenshively avatar Oct 31 '20 03:10 haydenshively