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, 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.
- 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
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.
This introduces the ability to use oracle peg orders on perp markets.
This PR has significant non-backwards compatible changes, for example all
order trees are now in a single account instead of separate.