Dynamically adjust memo length for L1ToLongtail according to the data length limits of any chains

[NeOMakinG]

Overview

As far as we know:

• DOGE and BTC are limited by a OP_RETURN length of 80 bytes. Therefore we decided to disallow these particular bridge&swap and give them more love in a follow-up PR regarding the complexity.
• THORChain has a memo size limit of 250 bytes
• BCH has an OP_RETURNS limit of 220 bytes (In case of a single OP_RETURN output, only up to 220 bytes of data can be stored, because you need 1 byte for the OP_RETURN opcode, 1 byte for the OP_PUSHDATA1 opcode, and 1 byte for the length of the data.)

Map the byte size

We need to select the actual size:

• If the chain is UTXO and DOGE or BTC => 80 bytes
• If the chain is UTXO and BCH => 220 bytes
• If the chain is EVM or IBC: 250 bytes

If we can't meet any of these conditions, just return an error so it's safer, and this chain should be added to this mapping, it has probably been forgotten while supporting it.

This way we will support any chains limits in an holistic way.

Final Asset Address length

THORChain allow to use only X number of characters, and it will fuzzy search in the 1inch token list:

• If only one token match, it will use it
• If no tokens match, it will use the string as it is and let the aggregator do his own work or throw
• If multiple tokens match, the first one will be used (Ref: https://gitlab.com/thorchain/thornode/-/blob/v1.131.0/x/thorchain/handler.go#L468-491)

We need to find a way to reduce the final asset address length (eg: https://gitlab.com/thorchain/thornode/-/blob/v1.131.0/common/tokenlist/ethtokens/eth_mainnet_latest.json), as far as we know, 2-3-4 chars are not enough and are colliding with multiple addresses, we have some solutions:

• Slice the final asset address into parts of differents sizes => 2, 3, 4, 5, X... characters, and loop over the 1inch list to find the smallest slice matching only one unique asset.
• Choose an arbitrary number that should be unique (spoiler alert it doesn't look like a reliable way to implement this feature)

minAmountOut of the final asset

We need to implement a dynamic adjustment of the final asset's minAmountOut in the memo.

Reduce the length of the minAmountOut value depending on the actual memo length overflow, be careful that the value should be acceptable and the 2 last numbers of the memo are the exponents as specified in the THORChain aggregator code.

Examples:

• You actually have a length of 85 bytes assuming that the selected chain is an UTXO and BTC/DOGE => We need to reduce the size to 80 bytes. It means we can actually loose 5 precisions from the minAmountOut to make it pass
• You actually have a length of 224 bytes assuming that the selected chain is an UTXO and BCH => We need to reduce the size to 220 bytes. It means we can actually loose 4 precisions from the minAmountOut to make it pass
• You actually have a length of 256 bytes assuming that the selected chain is an EVM/IBC => We need to reduce the size to 250 bytes. It means we can actually loose 6 precisions from the minAmountOut to make it pass

Please make sure the precision is good enough, even if it's already another security.

References and additional details

You will be able to find a lot of details in https://github.com/shapeshift/web/pull/6731

THORChain memo length documentation: https://dev.thorchain.org/concepts/memo-length-reduction.html THORChain aggregator memo informations: https://dev.thorchain.org/aggregators/memos.html

Our @gomesalexandre 🐐 did a wonderful out of date POC for the minAmountOut logic: https://github.com/shapeshift/web/pull/6772/files

Acceptance Criteria

• DOGE and BTC L1ToLongtail are supported and working
• Tested as much as possible
• unit tests are written and testing that the memo is adapting properly depending on the chain and the length difference

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

No response