feat(slippage): smart slippage for high fee orders

[alfetopito]

Summary

Fixes #4736

Calculates smart slippage based on fee percentage relative to sell amount.

This change intends to cover small orders where a small network cost variation can make them untradable.

The proposed logic, which still need to be discussed and reviewed, works as follows:

1. Compares the % the fee is compared to the total sell amount
2. If < 1%, does nothing. Which means, delegates to BFF's smart slippage calculation value
3. If >= 1% and < 5%, suggests 2% slippage
4. If >= 5% and < 10%, suggests 5% slippage
5. If >= 10% and < 20%, suggests 10% slippage
6. If >= 20%, suggests 20% slippage

These will take precedence over smart slippage from BFF.

⚠️ Tooltips not updated, still pending Mindy's texts

To Test

1. Make sure the Launch darkly flag is on
2. This will depend on current network conditions, so play around with input amounts to get it within those ranges
3. Place the order

• Should trade somewhat fast, hopefully. Not guaranteed, though.

Note: In gchain/arb1 the fees are very small, so the trade amounts need to be tiny in order to test it. I observed that even with high slippage they won't trade, likely because the trades are too small to be considered by any solver.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
cosmos	✅ Ready (Inspect)	Visit Preview	Sep 23, 2024 4:28pm
cowfi	✅ Ready (Inspect)	Visit Preview	Sep 23, 2024 4:28pm
explorer-dev	✅ Ready (Inspect)	Visit Preview	Sep 23, 2024 4:28pm
swap-dev	❌ Failed (Inspect)		Sep 23, 2024 4:28pm
widget-configurator	✅ Ready (Inspect)	Visit Preview	Sep 23, 2024 4:28pm

[alfetopito]

Needed to drop the quote from appData otherwise it enters into an infinite loop.

[alfetopito]

Open for debate. Too much? Too little? More levels?

[elena-zh]

Hey @alfetopito , great job!
Slippage percentages applied correctly for different fee thresholds.

Besides the question I reported in the thread, there is a nitpick I'd like to report: I can see that a slippage percentage can be changed when a final quote is loaded

Loaded:

Not sure what we can do with this.. Maybe ad a 'loading' effect to these fields? But, AFAIU, in a separate task.

Btw slippage of 20% looks a bit to scary for me :)

[alfetopito]

Hey @alfetopito , great job! Slippage percentages applied correctly for different fee thresholds.

Besides the question I reported in the thread, there is a nitpick I'd like to report: I can see that a slippage percentage can be changed when a final quote is loaded Loaded:

Not sure what we can do with this.. Maybe ad a 'loading' effect to these fields? But, AFAIU, in a separate task.

I added a crude loading indicator when either:

• The dynamic slippage is selected
• The dynamic slippage is suggested

Btw slippage of 20% looks a bit to scary for me :)

🤷

[elena-zh]

Hey @alfetopito , thank you for adding the loading effect! Looks the way better now!

[fleupold]

I think the suggested values make sense. Maybe a more generalizable strategy would be something like:

• let %gas be the fraction of gas fee of total volume
• suggest slippage := max(smart_slippage, %gas / 2)

This way we would allow at least 50% price movement of the gas estimate itself (which usually should become irrelevant or equal to default slippage when fees are <1%). I think this approach would be more flexible and not necessarily override the smart slippage (in case the underlying token is very volatile)

Was bucketing things an attempt to reduce the number of discrete values we have?

[alfetopito]

Superseded by #4982