- New permissionless instruction to regularly charge collateral fees
- Bank and group configuration to set rate and interval
- Keeper addition to call the instruction
The liqor liquidation fee and platform liquidation fee for the asset and
liab token are both payed by the liqee.
The platform liquidation fee is added to the Bank's
collected_fees_native and tracked in collected_liquidation_fees.
(cherry picked from commit 8383109f0d)
The liqor liquidation fee and platform liquidation fee for the asset and
liab token are both payed by the liqee.
The platform liquidation fee is added to the Bank's
collected_fees_native and tracked in collected_liquidation_fees.
- 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
(cherry picked from commit 42e31ae859)
- track min bid, max ask
- track maximal token outflow from oo
- add serum3_place_order_v2 with mutable receiver bank
- placing openbook orders is restricted to a certain distance from the
oracle
(cherry picked from commit 81501837a9)
- 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
- track min bid, max ask
- track maximal token outflow from oo
- add serum3_place_order_v2 with mutable receiver bank
- placing openbook orders is restricted to a certain distance from the
oracle
- 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.
- 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
Users can request token swaps to happen when the oracle price
is within a price band. Once the price is right, an executor can
trigger the swap. The executors are rewarded with a premium
over the oracle price.
This allows limit and stop loss orders on arbitrary spot pairs.
The PR comes with basic ts support and adjustments to the liquidator,
to execute available token conditional swaps.
Co-authored-by: microwavedcola1 <microwavedcola@gmail.com>
* 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>
- 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
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>
microwavedcola1
Christian Kamm
Adrian Brzeziński
microwavedcola1
tylersssss