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.
- 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
- 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
Which applies to the in token amount of swaps only.
Charging a deposit fee on flash loans was a bad idea:
- It incentivizes flash loan users to make the deposit a separate
instruction, defeating the purpose.
- For swaps, it makes traders pay a loan origination fee in in-token and
a deposit fee in out-token, leading to more complex bookkeeping and ui
display.
Instead, charge a fee on the in-token for all flash loans explicitly
marked as swaps only.
- Rename the new "swap fee" to "deposit fee" and let it apply to all
deposits, not just for Swap-type flash loans.
- But don't apply it to withdrawals (effectively giving rebates!)
Result of audit feedback
This lifts an unnecessary restriction, making it possible to do things
like flash loan and then liquidate with the resulting balances in a
single transaction.
The "no mango ix after FlashLoanEnd" limitation was unnecessary:
After the flash loan ends, the mango accounts are in a valid state
again. And it's impossible to use a two FlashLoanEnd for a single
FlashLoanBegin for the same reason that isolated FlashLoanEnds are
rejected.
It looks like it wasn't possible to exploit the program by
re-initializing the user-owned token accounts used in flash loan because
the later use of health_ais with the health computation would error out
if any token account was included there.
However, the check and a few others were too indirect. In this patch:
- We pass the number of loans into FlashLoanEnd explicitly (verified
from FlashLoanBegin)
- Add explicit checks for token mints, so it's no longer possible to use
token accounts for foreign mints in Begin when the loan amount is zero,
and it's clearer to see that the bookkeeping in End won't break if the
user reinited the account for a different mint.
- Also add a few other extra comments and checks.
The updated FlashLoanEnd instruction is called FlashLoanEndV2
* 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.
* Onchain interest calculation
* Fix to TokenBalanceLog for token_liq_bankruptcy (was previously using liqee liab position for liqor liab position).
* Log cumulative interest when token position is deactivated.
- Pass the group to Begin and End and ensure it is the same.
- Enforce target token accounts can't be group-owned.
- Now End can consistently derive the number of vaults/token accounts.
Instead, check for any liquidatable assets in liq_token_bankruptcy.
Bankrupt accounts may use the same operations as any other
negative-health account.
Christian Kamm
GoodDaisy
microwavedcola1
Nicholas Clarke
microwavedcola1