Add New Account Creation Mechanism on Asset Hubs

[joepetrowski]

Asset sufficiency only serves two purposes: fee payment and account existence. Using the Asset Conversion pallet allows fee payment to handle fee payment in any asset and has already been implemented. We can also use Asset Conversion to create accounts. This change will make non-sufficient assets almost as featureful as sufficient ones in a secure way.

[gavofyork]

As I mentioned in the call yesterday I don't think it's sensible to force users to have to exchange their currency (e.g. USDT/USDC) into the single native token merely to store the asset on asset hub.

[joepetrowski]

As I mentioned in the call yesterday I don't think it's sensible to force users to have to exchange their currency (e.g. USDT/USDC) into the single native token merely to store the asset on asset hub.

Yeah I will change this to propose this as an option, but keep sufficiency.

[lucasvo]

I think this is a good proposal. Generally I was originally supportive of sufficiency to improve the UX but it does create a two class system and putting a burden on everyone integrating AH to implement two paths - or worse possibly only implementing logic for the "most important" assets (i.e. the sufficient ones) and not supporting other assets. At current prices the existential deposit is less than an ERC20 token transfer on Ethereum Mainnet so asset sufficiency shouldn't be that important.

I am a bit torn about what I am to say because I hate making things more complex but this warrants discussion: I am not sure if we should change the default transfer function or expose this through a second transferMaybeCreate function (with perhaps a maxDeposit parameter that would make the tx fail if the deposit would become too costly). It will be impossible to know how much the fee in the token actually will be and this could vary greatly between the transaction being approved by the user and it being included in a block; a large LP could remove liquidity or a lot of other transactions could happen first. I would rather be able to explicitly allow for this than having only one transfer function.

[joepetrowski]

I am a bit torn about what I am to say because I hate making things more complex but this warrants discussion: I am not sure if we should change the default transfer function or expose this through a second transferMaybeCreate function (with perhaps a maxDeposit parameter that would make the tx fail if the deposit would become too costly). It will be impossible to know how much the fee in the token actually will be and this could vary greatly between the transaction being approved by the user and it being included in a block; a large LP could remove liquidity or a lot of other transactions could happen first. I would rather be able to explicitly allow for this than having only one transfer function.

Yes, I included the transfer logic as an example to express the logic in a way that was more clear, but not as implementation instructions. For sure it could be a new dispatchable that allows the sender to put a limit on how much of the asset is consumed to create the account.

[joepetrowski]

Going to close this as it's stale, and I think that it's largely solvable on the front end. Wallets can offer to batch a swap in front of a transfer if they see that the destination account doesn't exist.

[acatangiu]

With asset-conversion being available on Asset Hub, and the DOT existential deposit being lowered to 0.01 DOT (below 1$ even if DOT price goes up to 99$), I propose we reopen this proposal and make it an automated mechanism on Asset Hub, removing all complexity from source chains or front ends.

On receipt on AssetHub of any asset amount that doesn't satisfy destination account ED, up to 0.01DOT is swapped from the transferred assets to satisfy the destination account ED, and not fail the transfer.