Previously, if the funding or interest updating instruction wasn't
called for a long time (like for a solana downtime or the security
council halting the program), the next update would apply funding or
interest for the whole time interval since the last update.
This could lead to a bad downtime situation becoming worse. Instead,
limit the maximum funding and interest time interval to one hour.
* in perp settle fees, dont error, rather return early
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fix bug: only account for borrows we are offsetting
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fix
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Bank: Unittest for net borrow limits
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Co-authored-by: Christian Kamm <mail@ckamm.de>
This fixes a security issue where bankruptcy related instructions could
be called inside a health region. Now health regions are limited to
compute optimization like when placing multiple orders in one
transaction.
This limitation also makes it impossible to abuse health regions for
flash loans. Use the FlashLoan instructions for that purpose.
* support name edit for token and program
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* undo
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
This allows the security council to say "users can't create new borrows
against this token/perp anymore". In some emergency situations this can
help reduce risk exposure.
For example, if the price of a wrapped asset permanently depegs from
its underlying or there is a successful long-term attack on an oracle,
this (and reduce-only) would significantly reduce exploitability until
the DAO's decision for how to resolve the issue goes through.
* 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>
Previously liquidation would overestimate the amount required, because
it used the oracle price for computing the health gain from
liquidation.
Now it uses the correct (stable price adjusted) price for figuring out
the amount of liquidation required, while still executing at
fee-adjusted oracle price.
- don't store internal order ids: unneeded
- provide the maker client order id for user correlation
- store fees as f32 to waste fewer bytes
- new FillLogV2
- Rename to perp_liq_base_or_positive_pnl and perp_liq_negative_pnl_or_bankruptcy
- Deal with situations where overall asset weight is zero and base position reduction
would not improve liqee health
- Add ability for liqors to take over positive unsettled pnl if that improves liqee health
Speeds up the linking step, needs way less disk space for test binaries
and executes tests significantly faster.
Test execution went from 35s -> 29s for me and compilation improved a
lot.
* return order id from a perp place order ix
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fix
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* zero out perp position and orders for a broken market
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fix
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* client code
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* skip iteration if the incoming order has no lots to process
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
This includes trade pnl, funding and fees. Tracking this makes it easier
for uis to display a consistent position overall pnl value that doesn't
decrease by settling.
Co-authored-by: microwavedcola1 <microwavedcola@gmail.com>
This replaces the previous distinction between trusted and untrusted
markets, they are equivalent to setting the asset weights to 1 or 0
instead.
This way, we can weigh positive pnl in the trusted case at less than 1
which is more correct from a risk point of view and allows for more
flexibility when it comes to liquidation.
Co-authored-by: microwavedcola1 <microwavedcola@gmail.com>
The new instruction allows the liqor to take over negative pnl (limited
by liqee settle health and settle limits) before applying the bankruptcy
logic.
It's likely for perp pnl to oscillate and be settled in positive and
negative direction repeatedly. If the user's USDC balance is <= 0, every
settlement of negative pnl will increase borrows and cause loan
origination fees.
Over time the fees accumulated this way could be significant. Skipping
loan origination fees for borrows created from perp settlement avoids
that.
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.
While the flag is true, deposits that don't bring the account health
over the init threshold are forbidden. This makes it impossible for
users to drag out liquidation by continuously depositing tiny amounts.
Liquidation and perp pnl settlement may not bring spot amounts to
exactly zero. Having a small spot amount < 1 native token can otherwise
make the liquidation get stuck and not move one to the next phase.
* Client: Rework max_swap function
Determining the amounts at which the health function changes slope
becomes too difficult when serum3 open orders come in.
Instead, generally find the function's maximum and then work with that.
* max_swap: Add test for swapping into a trustless token
* ts port
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Co-authored-by: microwavedcola1 <microwavedcola@gmail.com>
Liquidator, liqtest and rust client fixes
- Make rust MangoClient fully async
- Update and improve liquidation test setup scripts
- Update liquidator to use versioned transactions
- Update liquidator to use mango and jupiter account lookup tables
- Use jupiter v4 api to get versioned transactions
Perp liquidation is still not fully good. See discussion aboult perp_liq_pnl_with_token.
* dont do checks force close flag is used explicitly
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* comment
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* comment
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fix ts
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
- Don't return result as I80F48, f64 is more honest
- Allow access to avg entry price per base lot without division
- Reset break even price when position changes sign
- Fix occasionally-failing fast division test
- Fix sign of break even price -- it can now be negative if the
position has broken even.
It is tracked in the StablePriceModel and updated on
TokenUpdateIndexAndRate and PerpUpdateFunding instructions.
The stable price is used in health computations.
Now the oracle price and a "safe" price go into the health computation and
init health uses the min of both for assets and the max for liabs.
This has far-reaching consequences for how serum and perp health need to
be computed because many intermediate values depend on the prices, which
now differ for init and maint health computations.
The biggest change is that the serum3 reservation totals need to be done
for each health call from scratch.
This PR increases the health CU host per serum3 market and perp market
significantly, check the test_health_compute tests.
Since Bank can't expand the existing OracleConfig, add a new one to Bank
and (temporarily!) copy over the old value to the new one in
TokenUpdateIndexAndRate.
Add some reserved space to OracleConfig to make this easier in the
future.
Breaks the PerpMarket and PerpPosition layouts
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.
* Perp instruction logging
* Onchain funding calculation
* perp_spot_transfers field on perp positions
* Logging on register token, perp market
* Additional fields on update token index logging
* maker and taker volume fields on perp position
This adds three new options to perp markets:
- a flat fee, that is paid for all perp settlements
- given that they exceed the configured min settle amount threshold to
be eligible for fees
- and a fractional fee, that only applies when the benefiting account
has low health and gradually becomes bigger as the account slides
towards liquidation
* 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.
* ts: use price factor in maxSourceForSwap
ts: max perp bid and ask
ts: mocha test for max swap
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* ts: comemnt
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
Because it's not correct to think we'll always swap at oracle price.
That was an ok assumption for liquidations, where we'll swap at slightly
better than that, but not for jup.
Perp settle pnl: Limit to maint spot health
We want to isolate perp markets. As such, it's not acceptable to convert
arbitrary perp losses into spot token borrows.
The safe amount for this conversion is given by the account's
maint health -- with all perp markets ignored.
* Perps: fix position lifetime; explicit closing
When an order is placed and the position needs to be created, the
settlement token is marked as in use. The perp position and the in-use
flag are only released with the new perp_close_position instruction.
* Tests: Factor out common floating-point comparisons
* Rename PerpClosePosition -> PerpDeactivatePosition
Direct access to base_position_lots and quote_position_native is not
allowed anymore.
Fixes an issue where quote_lots were used instead of quote_native, and
also takes fees into account for the entry price.
- Clarification of close_order vs close_all_orders
- Remove of get_ prefixes
- Remove find_min/find_max/find_min_max, duplicated with
min_leaf/max_leaf
The identity
a * b = -((-a) * b)
does not hold for I80F48, probably it's rounding to -inf.
This meant that withdrawing the full native token balance could
fail because the magnitude of -position * price was bigger than
position * price.
- 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.