- 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)
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, 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)
The liqor liquidation fee and platform liquidation fee for the asset and
liab token are both payed by the liqee.
The platform liquidation fee is added to the Bank's
collected_fees_native and tracked in collected_liquidation_fees.
(cherry picked from commit 8383109f0d)
- require borrows <= deposits, even if vaults have more tokens
- change min_vault_to_deposits_ratio to be about max utilization
Reviewed and audited as part of the v0.21.1 release, original
commit was 5c2f857112
Previously, freeing would be impossible if a canceling fill or out event
was already in-flight - then the order would no longer be on the
orderbook.
Now, FillEvent and OutEvent store the order id and can check if the open
order slot on the account has been reused already. That allows canceling
orders to always free up the user slot immediately.
- since there's no borrowing or asset weight, don't put staleness or
confidence restrictions on the oracle
- disable the tcs fees, they are not enabled anywhere yet
(cherry picked from commit 5f8f717430)
- since there's no borrowing or asset weight, don't put staleness or
confidence restrictions on the oracle
- disable the tcs fees, they are not enabled anywhere yet
- limit deposits (via deposit, flash loan, tcs)
- limit potential deposits via openbook settle
by restricting placable orders via potential_serum_tokens
- introduce Serum3PlaceOrderV2 for this purpose
- account for new limits in liquidator, max_swap
(cherry picked from commit 42e31ae859)
- track min bid, max ask
- track maximal token outflow from oo
- add serum3_place_order_v2 with mutable receiver bank
- placing openbook orders is restricted to a certain distance from the
oracle
(cherry picked from commit 81501837a9)
- limit deposits (via deposit, flash loan, tcs)
- limit potential deposits via openbook settle
by restricting placable orders via potential_serum_tokens
- introduce Serum3PlaceOrderV2 for this purpose
- account for new limits in liquidator, max_swap
- track min bid, max ask
- track maximal token outflow from oo
- add serum3_place_order_v2 with mutable receiver bank
- placing openbook orders is restricted to a certain distance from the
oracle
* program: optimize cu usage in token deposit, by computing health only if user is being liquidated
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>