* program: optimize cu usage in token deposit, by computing health only if user is being liquidated
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
* Fixes from review
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
---------
Signed-off-by: microwavedcola1 <microwavedcola@gmail.com>
- 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
- Only ever give an incentive when pnl is at least 1% of the position
value. That way large positions (like $100k in SOL-PERP) don't get
settled on 0.1% price fluctuations. The price now needs to change by
1% for settlement to occur.
- For low health incentives, cap the percentual incentive at 2x the flat
settle fee. We want to give the settler incentive to use these first,
but the settler doesn't take on risk, so the reward doesn't need to be
large.
Many instructions now return PreparedInstructions instead of a direct
Instruction or Vec<Instruction>. That way they can keep track of the
expected cu cost of the instructions for the compute limit instruction
that gets added once all instructions are made.
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.
* tests: Upgrade tx log capturing
Instead of overriding the system logger to intercept the logs, we can
now ask solana to return the logs of a tx execution directly.
This speeds up tests a lot because we don't need to hold a global lock
on tx execution anymore!
* tests: Improve token, serum, perp cu test
* benchmark: add a few more operations
- Change fixed to be a git dependency (no more submodules!)
- Upgrade fixed to a version compatible with borsh 0.10
- Upgrade openbook-v2 dependency (for anchor compat)
- Move services from mango-feeds repo into bin/
- Update mango-feeds-connector
Co-authored-by: Christian Kamm <mail@ckamm.de>
Co-authored-by: Riordan Panayides <riordan@panayid.es>
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.
- The AccountExpand instruction can now shrink accounts by reducing
the number of token/perp/serum/tcs/perp oo slots.
- A new AccountSizeMigration instruction can permissionlessly shrink
accounts that are too large and migrate them to the v3 layout.
- 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
* Account size: Don't fail on unrelated resize
If the account was previously resized to larger than is allowed now,
don't fail unrelated resizes.
* Further reduce account size limits
Out of caution and future-proofing. Can always raise again.
Perp settle pnl needs 6 accounts plus 2 health account lists that could
be nearly fully disjoint.
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.