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

TxManager only cares about most profitable candidate #118

Open
haydenshively opened this issue Oct 31, 2020 · 0 comments
Open

TxManager only cares about most profitable candidate #118

haydenshively opened this issue Oct 31, 2020 · 0 comments
Labels

Comments

@haydenshively
Copy link
Owner

haydenshively commented Oct 31, 2020

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.

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

No branches or pull requests

1 participant