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.
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.
- 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
- 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
- token_edit can set it up to gradually scale to new target values
- security admin can abort an ongoing change via token_edit
- all health computations are now time dependent and get the weight
based on it
- when the change is done, the keeper "cleans up" and moves the new
values into the default fields
When bids or asks crossed the oracle price, the serum3 health would be
overestimated before.
The health code has no access to the open order quantites or prices and
used to assume all orders are at oracle price.
Now we track an account's max bid and min ask in each market and use that
as a worst-case price. The tracking isn't perfect for technical reasons
(compute cost, no notifications on fill) but produces an upper bound on
bids (lower bound on asks) that is sufficient to make health not
overestimate.
The tracked price is reset every time the serum3 open orders on a book
side are completely cleared.
This changes perp market margining to no longer assume all pnl is in USD
while settlement is in USDC. Instead, a configurable settle token is used for
pnl and settlement, defaulting to USDC.
There is no difference while the USDC price is forced to $1 and the init and liab
weights are 1. But with this patch, it becomes possible to change that.
For now it is not recommended to use a token other than USDC or USDT (or
another USD targeting stable token) for perp settlement.
The patch also updates all insurance vault use to be aware that the insurance
fund is not in USD but in USDC and apply the USDC price before payouts.
To do this, the previous PerpLiqNegativePnlOrBankruptcy was replaced by
a new PerpLiqNegativePnlOrBankruptcyV2 instruction.
Co-authored-by: microwavedcola1 <89031858+microwavedcola1@users.noreply.github.com>
* Vendor `fixed` crate to have checked math in release mode
* remove all cm!()
* drop superfluous parens
* drop use of checked_math crate
* manual removal of redundant checked_* functions
To do that, split up the Accounts objects and the instruction
implementations.
GPL code is only used when the "enable-gpl" feature is enabled. That
means compiling the program or running tests need explicit feature
activation now.
Due to the safety features in v4, the init health can differ from maint
health a lot more than it used to in v3. This is because of stable-price
adjusted oracle prices used in init health, and the weight scaling based
on total deposits and borrows used in init health.
The effect is that once an account becomes liquidatable, it could be
liquidated a lot until it reaches init>=0.
The original idea of liquidating until init>=0 was just to provide some
buffer, such that liquidated accounts wouldn't immediately become
liquidatable again.
This patch decouples the buffer idea explicit from init health by
creating a new LiquidationEnd health type. Liquidation proceeds until
the LiquidationEnd health becomes positive.
Co-authored-by: microwavedcola1 <89031858+microwavedcola1@users.noreply.github.com>
This gives us better compatibility with released anchor versions.
Instead of using AccountLoaderDynamic<MangoAccount>, we now use
a standard AccountLoader<MangoAccountFixed>. This will generally work
(except for load_init(), which is dangerous).
A new trait, MangoAccountLoader, provides load_full(), load_full_mut()
etc on the AccountLoader<MangoAccountFixed> to create accessor structs
that can read and write to the dynamic part of the mango account data.
- Loan origination fees: The previous approach of tracking the reserved
amount did not work because OutEvents will also reduce the reserved
amount. This means we can't know if it was an OutEvent-cancel or an
order execution that caused the reduction.
Instead, we now track the amount of borrows that was made (without
applying origination fees) in place order. Whenever we try to settle
and the amount of tokens on the oo account is less than the potential
borrows, we can be certain that the borrow has actualized.
- Place order is no longer automatically followed by a settle.
This can reduce compute use when people want to place multiple orders
in sequence. Now they can use the HealthRegion instructions to place
their orders, settle once at the end, and then have health checked.
- Vault check: Place order previously rejected valid orders because it
didn't consider that there could be free tokens on the oo account.
- Tests: Some infrastructure for less verbose serum testing.
While a serum open orders is active, the base and quote token positions
for it are locked to active. It's pointless to check if they need to be
deactivated after place/settle etc.
You can do
- HealthRegionBegin
- ... mango instructions ...
- HealthRegionEnd
and the account health will only be checked at the start and end
instead of for every instruction.
Christian Kamm
Lou-Kamades
Nicholas Clarke
microwavedcola1
microwavedcola1
riordanp