Problem Statement:

See original, Weight Based approach

Opportunity

See original, Weight Based approach

Theoretical Method - Standard Stable Math

Without rewriting all stable math equations the directional fee handling can be changed atomically prior to swaps meeting the surge criteria in a hook which supersedes the trade functionality of a pool. Every swap is subject to the hook functionality.

Relevant Variables inherited from Stable Math

n: number of tokens or assets

swapFee: the base swap fee of the pool

Note all uses of B for balances in this document are referring to virtual balances which assume any rate provider multiplied by the nominal amount of tokens is already considered:

$$ B_{vitrual}=B_{nominal} * rate $$

Hook Mutable Variables:

1. deviation (γ): Defines the percentage off-peg the asset pair can be before a surge factor will be implemented on the pool’s fee.
   1. For simplicity we will use a rate provider ratio, as opposed to spotPrice

$$ spotPriceAfterSwap <\frac{rate_{in}}{{rate_{out}}}*(1 - γ) $$

This implies the need for balance in and sum of balances after a swap is made using the base fee to still be simulated and or calculated, but not executed when the criteria above is met. If the value falls within the designated threshold the transaction is executed identically to a current stable swap path.

An expected value for γ in a 2 token (n=2) would be 0.1. This would mean surging would occur if any token reaches 60% of the total of balances.

1. surgeCoefficient (μ): Is an amplification coefficient to amplify the degree a fee increases upon the threshold being triggered.
   1. A directly proportional increase in the swapFee in response to the lack of correlation of asset Balances is not enough of a deterrent to swappers, or maximal benefit to liquidity providers.

Fee Calculation

Fees are assumed to be taken on the tokenIn for the purpose of the sample calculations, however basing this on tokenOut would not change the outcome. In either case the user receives less tokens out and liquidity providers retain more value in the event of surging.

The only specific handling that will need to be done is at the cross over of the threshold to properly charge a fee at the exact point of breaking the γ plane. This ensures a user is only charged an increased fee on the portion of tokens in their swap which is across the surge point.

$$ \frac{rate_{in}}{{rate_{out}}}*(1 - γ) = allowablePrice $$

$$ surge = (\frac{allowablePrice}{spotPriceAfterSwap} - 1 ) \\ - \\ TBD $$

$$ If(spotPriceAfterSwap < allowablePrice, surge * swapFee \ , swapFee) $$