feat: Check Destination sufficiency with an optional destApi

[andrew-ifrita]

If provided use destApi to make additional calls to ensure that receiving accounts will be sufficient and that no assets will be lost when accounts are reaped.

This is somewhat of a band-aid, as accidental loss of assets is still possible at the protocol level. This at least improves the user experience when it comes to transferring assets until we can investigate fixing the root of the issue at the protocol level.

General Idea

Throw and error or raise a warning if the receiving account will not be sufficient following the transaction.

Motivation

Make it harder for assets to be accidentally be burned by sending them in insufficient accounts which will be reaped.

Goal

• Don't break any existing API
• Verify receiving accounts are (or will be) sufficient
• Warn users

Downsides

• Verification only happens at the time of the tx building
  • future account changes could still result in assets potentially being lost if the destinations are no longer sufficient
• Additional API calls

Questions

• Do we want to throw and error and kill the tx building, or simply warn the user?
  • If we throw an error, should we add an optional bypass to ignore these checks

[andrew-ifrita]

I can add a few tests, but it should be good enough for review at this point.

[andrew-ifrita]

Reviewing this a few days later: I would say I'm missing MultiAddress support.

Similarly, (probably an edge case), but the pattern here won't work if sending to multiple destination chains. I need to investigate that a little. We could add a mapping of destination API to asset, but I'm not a fan of the UX. Although it would be mostly consistent with what currently exists and UX could be improved afterwards edit: actually while possible with XCM, this breaks the current design since we explicitly provide a single destChainId

[andrew-ifrita]

Ok, discovered one more issue which is accounting for XCM execution fees being deducted along the way which can lead to a transfer being below the existential deposit and then being lost to account reaping. This is a blocker. Test case is already in place, Relay chain to Asset Hub throws error if destination is insufficient after execution fees.

I have yet to add foreign asset support, but that is less pressing, as it would only cause false positives on the insufficiency check which won't lead to loss of funds, unlike the false negatives if fees are not accounted for.

edit: Moving to draft in the meantime

[andrew-ifrita]

Closing as this has gone stale.