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.
- 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
* Serum3 open orders: Fix health overestimation (#716)
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.
(cherry picked from commit 2adc0339dc)
* Changelog, version bump for program v0.19.1
* ts: ts patch for the PR
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Co-authored-by: Christian Kamm <mail@ckamm.de>
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.
Instead, check for any liquidatable assets in liq_token_bankruptcy.
Bankrupt accounts may use the same operations as any other
negative-health account.
* Add logging
* Added new_fixed_order_account_retriever to allow us to more easily access oracle prices outside of health calculations for logging purposes
* Add token balances logging to token and token liquidation and add logging to margin trade
* rust format
* fix clippy errors
* Address PR requested changes
* fix flash_loan
* Recalculate raw_token_index in token withdraw to account for position becoming inactive
* Fix retrieving oracle for logging
in get_mut_or_create(), return the raw index into the account's token
positions as well as the index into active positions only. The latter
index is useful for indexing into banks in the health account list.
* Add logging flash_loan2 and flash_loan3
* Refactoring flash loan logging
Co-authored-by: Christian Kamm <mail@ckamm.de>
The latter is important when we want to compute health for two different
accounts. Then the remainingAccounts would hold the union of the
necessary accounts, and each health check would need to look for the
accounts that it needs.
This patch al so reduces the compute needs for fixed-layout health
checks significantly (Deposit for an account with 8 tokens and 7 markets
takes 65k instead of 70k cu)
Christian Kamm
microwavedcola1
Nicholas Clarke
microwavedcola1