liquidator: split TCS triggering and liquidation job
Concurrent execution of candidate lookup and tx building/sending
- Also added an health assertion IX to protect liqor in multi liquidation scenario
- And a timeout for jupiter v6 queries (avoid blocking liquidation because of slow TCS)
Add a sequence check IX
This new IX `SequenceCheck` can be used to avoid having multiple concurrent TX in flight causing unexpected result (multiple borrow for example)
- New permissionless instruction to regularly charge collateral fees
- Bank and group configuration to set rate and interval
- Keeper addition to call the instruction
Previously, we tried to keep track of "other" and "trade" realized pnl.
An issue occured when a perp base position went to zero: the way we
computed the trade pnl included potential non-trade unsettled pnl.
That caused follow-up trouble because the value could change sign and
reset the settle limit for trade pnl.
This change aims to simplify in some ways:
- explicitly talk about oneshot-settleable pnl (fees, funding,
liquidation) and recurring-settleable pnl (materialization of settle
limit derived from the stable value of the base position when reducing
the base position)
- instead of directly tracking realized settleable amounts (which
doesn't really work), just decrease the recurring settleable amount
when it exceeds the remaining unsettled pnl
- get rid of the directionality to avoid bugs of that kind
- stop tracking unsettled-realized trade pnl (it was wrong before, and
no client uses it) - we already track position-lifetime realized trade
pnl
(cherry picked from commit ae5907ba3a)
Previously, we tried to keep track of "other" and "trade" realized pnl.
An issue occured when a perp base position went to zero: the way we
computed the trade pnl included potential non-trade unsettled pnl.
That caused follow-up trouble because the value could change sign and
reset the settle limit for trade pnl.
This change aims to simplify in some ways:
- explicitly talk about oneshot-settleable pnl (fees, funding,
liquidation) and recurring-settleable pnl (materialization of settle
limit derived from the stable value of the base position when reducing
the base position)
- instead of directly tracking realized settleable amounts (which
doesn't really work), just decrease the recurring settleable amount
when it exceeds the remaining unsettled pnl
- get rid of the directionality to avoid bugs of that kind
- stop tracking unsettled-realized trade pnl (it was wrong before, and
no client uses it) - we already track position-lifetime realized trade
pnl
Serge Farny
Christian Kamm
microwavedcola1
Adrian Brzeziński
microwavedcola1
GoodDaisy