Is your feature request related to a problem? Please describe.
We are observing MEV type of activity when users execute some typical sandwich attacks that enclose a normal stake or unstake operation between two malicious transactions that elevate/drop price within the same block before the victim realizes it.
Describe the solution you'd like
TL;DR: The solution is to aggregate all transactions within a block (or a short interval of blocks if needed) and reduce them to only one swap.
Problem statement
- See the proposed solution and research if a similar solution was ever implemented by anyone else before.
- Implement (using 3rd party implementation is preferable if their license allows).
Proposed solution
As user add_stake and remove_stake transactions are coming, instead of executing the swap right away (calling swap_tao_for_alpha and swap_alpha_for_tao), we should record all such orders until settlement.
Settlement occurs either in on_finalize, or in on_initialize in the next block (or one of the next blocks), or at any other time as requirements clarify over time. During the settlement:
- Add all TAO and all Alpha.
- If current_price * {sum of alpha} > {sum of tao}, we have excess Alpha.
- If current_price * {sum of alpha} < {sum of tao}, we have excess TAO.
- If current_price * {sum of alpha} == {sum of tao}, there is no excess.
- Execute a single swap to exchange the excess add received value to {sum of tao} (in case of alpha excess) or to {sum of alpha} (in case of tao excess).
- Distribute {sum of alpha} to buyers proportionally to their contribution.
- Distribute {sum of tao} to sellers proportionally to their contribution.
Above was is a simplified version of algorithm that doesn't account for limit orders, but we have limit orders (add_stake_limit and remove_stake_limit) that allow (1) setting the limit price, and (2) specifying fill or kill flag. In order to account these, sort all orders by limit price from best to worst (with non-limit orders coming at the end of the list). Best price for buy order is lower, best price for sell order is higher. Then, if final price is beyond the limit price of the order, modify the order to either reduce amount (if it is limit order) or remove it completely if it is fill-or-kill type. Then recalculate the final price and continue moving down the list of orders until the final price is better or equal than the limit price.
Describe alternatives you've considered
No response
Additional context
No response
Is your feature request related to a problem? Please describe.
We are observing MEV type of activity when users execute some typical sandwich attacks that enclose a normal stake or unstake operation between two malicious transactions that elevate/drop price within the same block before the victim realizes it.
Describe the solution you'd like
TL;DR: The solution is to aggregate all transactions within a block (or a short interval of blocks if needed) and reduce them to only one swap.
Problem statement
Proposed solution
As user
add_stakeandremove_staketransactions are coming, instead of executing the swap right away (callingswap_tao_for_alphaandswap_alpha_for_tao), we should record all such orders until settlement.Settlement occurs either in
on_finalize, or inon_initializein the next block (or one of the next blocks), or at any other time as requirements clarify over time. During the settlement:Above was is a simplified version of algorithm that doesn't account for limit orders, but we have limit orders (
add_stake_limitandremove_stake_limit) that allow (1) setting the limit price, and (2) specifying fill or kill flag. In order to account these, sort all orders by limit price from best to worst (with non-limit orders coming at the end of the list). Best price for buy order is lower, best price for sell order is higher. Then, if final price is beyond the limit price of the order, modify the order to either reduce amount (if it is limit order) or remove it completely if it is fill-or-kill type. Then recalculate the final price and continue moving down the list of orders until the final price is better or equal than the limit price.Describe alternatives you've considered
No response
Additional context
No response