* 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.
Tcs orders always store prices in a fixed "sell per buy" style, but users
can create them in either price direction. When they look at them later,
the ui needs to know what their preferred style is for this order.