THORSwap trades refunded at "Emit asset is less than price limit"

[gomesalexandre]

Overview

Some of our trades are currently being refunded with cause: Refunded: Emit asset {actual} less than price limit by -{limit - actual}

We need to investigate the current limit memo to ensure our THOR Txs consistently go through.

These account for a small portion of ss affiliate trades (~1 per day)

There seems to be a constant to these happening on larger streaming swaps (5000+ USD)

References and additional details

• Refunded Txs: https://runescan.io/txs?affiliate=ss&type=refunded

• All Txs: https://runescan.io/txs?affiliate=ss&type=all

• addSlippageToMemo
  

  web/src/lib/swapper/swappers/ThorchainSwapper/utils/addSlippageToMemo.ts

  Lines 33 to 39 in 9a6cde4

  	const limitWithManualSlippage = subtractBasisPointAmount(
  	bn(expectedAmountOutThorBaseUnit)
  	.minus(affiliateFeesThorBaseUnit)
  	.toFixed(0, BigNumber.ROUND_DOWN),
  	slippageBps,
  	BigNumber.ROUND_DOWN,
  	)

Investigate slippage configuration tweaking for larger trades, streaming options, as well as potentially deducting some other fees (?) to get the final limit memo

Acceptance Criteria

• We do not see larger THOR streaming swaps being refunded

Note, this will require some confirmation from the runescan link above that we do not see refunds for that reason anymore

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

N/A, may require multiple PRs until we get the heuristics right

[gomesalexandre]

For a similar quote on THORSwap (10,000 USDT -> DAI), we use a limit of 984349769151 while THORSwap uses 0 for streaming swaps.
Interestingly, their memoStreamingSwap is =:ETH.DAI:{recipientAddress}:0/3/53:t:30 (no wallet connected, hence the {recipientAddress}) vs. our final memo being "=:ETH.DAI-0X6B175474E89094C44DA98B954EEDEAC495271D0F:{recipientAddress}:984349769151/10/0:ss:0"

Takeaways:

• we use an interval of 10, vs. THORSwap using 3. This should however yield better rates, at the cost of slower execution
• they use a streaming quantity of 53 while we use 0, which in the memo language, means automatic quantity.

Another thing to mention here is the notion of final memo: we pass the memo we get from the quote through addSlippageToMemo to recompose a memo with the limit we've calculated, however, the original memo doesn't have any limit, i.e: "=:ETH.DAI-0X6B175474E89094C44DA98B954EEDEAC495271D0F:{recipientAddress}:0/10/0:ss:0". This is on par with THORSwap's memo which also doesn't have any.

Notes:

• the interval of 3 seems to be constant in THORSwap
• the streaming quantity seems to be variable, indicating optimizations on their side, but using 0 and letting the THOR API decide the best quantity should be safe
• the limit is consistently 0

A good starting point would be to use the new max_streaming_quantity property returned by the quote endpoint, which would guarantee a (possibly better?) quantity.

Q: is it even feasible to have reliable limit for larger trades while including our affiliate bps deduction logic, or should we go with 0 with user-facing warnings that the price limit is not guaranteed and is subject to a change because of xyz?