Snowbridge: pallet-assets Max consumers limit for sovereign accounts

[alistair-singh]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

Sovereign accounts hold many assets as they are the accounts where assets are held in reserve on Asset Hub for all reserve-based transfers. Users do not interact with the sovereign account, they just initiate a transfer to a destination parachain, which in turn involves the parachain sovereign account. This leads to situations, for instance with Hydration parachain, where the maximum consumer limit is hit, causing the transfers fail with:

xcm::execute  TRACE: !!! ERROR: FailedToTransactAsset("Account cannot exist with the funds that would be given")

This results in user funds being trapped.

Request

This issue is currently being worked around using the touch extrinsic on a pallet-assets, which allows a deposit to be paid so that the account can exist with the asset. The issue with this approach is that touch requires governance as it needs to come from the origin of the parachain in order to touch the parachain sovereign. There is also touch_other extrinsic which allows a user to touch on behalf of an account, but this origin here is limited to the asset freezer or admin, in cases where the freezer or admin is a sovereign account (Snowbridge sovereign for bridged assets) then this would also require governance.

We need to provide some way to do this without a governance request for each asset being transfered.

Solution

Possible solutions:

1. Increase the maximum consumers. This is not ideal as it will just bump up against the new limit in time.
2. Do not check consumers for sovereign accounts as a special case. Not sure if this is possible to detect at the time of asset deposit.
3. Do not check consumers if an account has ED of some sufficient asset, i.e. has a provider.
4. Lower friction to using touch_other by allowing any account to put up a deposit (not just the asset freezer and admin). That way dapps can rememdy this in the app, for example the user doing the transfer can put up the deposit if this case is detectedthe

Are you willing to help with this request?

Yes!

[acatangiu]

I am in favor of option 4, it's pragmatic and easy to do.

Quick feedback on the other options:

1. this just kicks the problem down the line and can also be potentially problematic at scale (raises the limit for everyone)
2. this is very hacky, muddles the boundaries between components (pallets and runtime)
3. how do we reap the account? without consumer count, it can be incorrectly reaped and losing non-sufficient assets