This is necessary for new liquidator feature of rebalancing using limit orders:
We need to close the token and market slot so that it's available for new liquidation, but at the same time, it's possible that the min order quantity for a given market is still bigger than allowed max withdrawal.
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)
* Programs: remove anchor close has it is done manually anyway
* Programs: fix a bug where a pegged order might be skipped even if it was valid
(cherry picked from commit 905cc01414)
(cherry picked from commit 47c2707cfe)
This ensures casts of local variables don't run into alignment
differences.
(cherry picked from commit d9c4f69e0e)
(cherry picked from commit 676da3a084)
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)
The following instructions now allow skipping banks and oracles if health
and the token position balance is not negative:
- token_withdraw
- token_deposit
- serum3_place_order
- perp_place_order
- flash_loan
They also allow skipping oracles that are stale.
* add RaydiumCLMM oracle type
* add deserializing raydium pool state
* test: consolidate clmm oralce unit tests
* test: add failure check to test_orca_fallback_oracle
* test: add test_raydium_fallback_oracle
* restore get_quote_oracle()
* ensure RaydiumCLMM is a valid fallback type
- apply recurring settle allowance constraint also in
available_settle_limit
- bank constraints on util0, util1
- cleanup
- perp liq: take over oneshot and recurring limits separately
(cherry picked from commit efe4a1ae3d)
- apply recurring settle allowance constraint also in
available_settle_limit
- bank constraints on util0, util1
- cleanup
- perp liq: take over oneshot and recurring limits separately
- New permissionless instruction to regularly charge collateral fees
- Bank and group configuration to set rate and interval
- Keeper addition to call the instruction
* perp: auto close perp market account when needing to open a new one with no slot available
* rust_client: do not send health accounts when deactivating a perp position (not needed on program side)
* rust_client: add perp place order command
Previously serum3_place_order would fail when deposit limits were
exhausted on the payer token side. Now the failure only happens when
payer tokens need to be borrowed.
(cherry picked from commit a4cddf3129)
Previously serum3_place_order would fail when deposit limits were
exhausted on the payer token side. Now the failure only happens when
payer tokens need to be borrowed.
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
Lou-Kamades