Allow One Chain to be an Account Provider for Another

[joepetrowski]

A few of us had a discussion about enabling a system where an account in one location (e.g. the Relay Chain) would grant the account owner the ability to create accounts in remote locations (e.g. a system parachain) based on its existence in the provider location.

A system like this would allow accounts to exist on Asset Hub (e.g. to be able to send them assets) provided that the receiver has an account on the Relay Chain.

Full discussion below:

---

kianenigma

hey, not sure what is the status here but I wanted to bring up something about dealing with existential deposit:

I think it is reasonable to assume if an account has ED in the relay chain, it is eligible for an account across all system chains. We can't really say this about other sovereign parachains, but for system chains it is a reasonable assumption.

then, there would be two options about achieving this:

1. teleport to all chains, simple but a but cumbersome.
2. an async verification whereby you transact on the relay chain, an addition lock is put on your ED, a message is sent to system chains that will increase your account's provider counter

I am guessing this might have been discussed in the proposal related to funding accounts in the AH and I was not following it, but I thought it is worth bringing it up here one more time

joe

I quite like this idea, but they both still require the account holder to do something. I think for something like sending an asset to an account on AH that you know exists on the Relay Chain, you want to be able to make another account exist. So you'd have to transact on the Relay Chain and note a target account. But then that holder would need a way to free their account too (otherwise you could just lock other people's balance)

AlexBirdo | 🇩🇪

Most airdrops require the user to 'claim' funds thou

I've never got an airdrop without having to make a tx on my side

joe

Yeah I mean perfect then

You can make it a two-phase process, teleport the ED if necessary and then claim

muharem

what do yo mean here by claim? do we have such functionality/call in asset hub?

why I am asking, if we have such functionality and call for it, it can be even one phase process. it could be some web page with one button to send one xcm program which will teleport from RC and execute the claim with Transact instruction

joe

We don't have a claim function, but I don't see how it could be done in a way that's better than just issuing the asset, because you would need to store (AssetId, AccountId) => Balance, which is what we already store for the assets.

I think in this case when you are claiming from an issuer, you already trust the asset issuer, so a claim function on some app would make the issuer mint the tokens to your account

kianenigma

I quite like this idea, but they both still require the account holder to do something.

maybe.. what if this process of propagating your existence to all system chains is permissionless, so anyone can do it?

The contract is that if you create an account on Polkadot and put ED to it, you get an account on all system chains. Assuming there is good ways to clean up your account in all chains via a UI, it seems like a good contract to me.

So, in this case, it needs no user interaction.

This is all to enable some kind of a 100% no interaction airdrop, I think if transacting is part of the deal, then yeah teleport to all system chains is "easiest". it is still kinda shitty that I need to have eg. 7 DOTs put aside to transact on 7 system chains though

joe

System chain ED is 0.1 DOT (0.01 on AH) 🙂 So 1 DOT for Relay and 1 more would get you up to 10 more chains

The main question is if the permissionless call locks an additional amount on the Relay in order to issue a provider on the para. I don't think you want people to be able to permissionlessly lock other people's funds.

kianenigma

SO if the RC has the highest ED, having ED on RC should imply ED on any system chain that has a smaller ED.

(and for now let's assume ED won't ever change)

I don't think you want people to be able to permissionlessly lock other people's funds.

I was iffy about this as well, but I think this is one of the few reasonable tradeoffs that we can accept. Yes, it is a small issue, but so long as there is a way to kill your account, it is an acceptable tradeoff. I would rephrase it like this:

1. killing your account is already complicated if you have multiple consumers etc. If we make it slightly more complicated by you first needing to drain your account on all system chains, it seems fine to me. the benefit will then be that AH can be the airdrop-hub as well :)
2. If this allows someone to make it impossible for you to re-claim your ED (eg sending you some non-transferrable asset on AH that prevent your account from ever being reaped, idk), then I agree it is an issue.

I think to have sustainable airdrops, it is either this, or the disposable-parachain idea

joe

True, we could just say that Relay account implies a right to an account elsewhere. So no need to hold more funds on the Relay, just that it covers all.

But maybe tracks how many remote accounts have been created based on it, and to remove your RC account you need to drop that to 0

[burdges]

An ED something we enforce: If it drops too low then chain logic takes some action. It's problematic if this action requires sending multiple messages.

It's definitely sensible if the parachain is temporary somehow, like maybe a specific session forked off by a game chain, or a validator ellection chain that runs PJR tests forked off from the staking chain (or relay chain) using some O(1) chain state copy.

A temporary subtree makes sense too, like if the original account is locked, then we can take action based upon its contents in another chain, which maybe relevant for governance: We vote based upon governance locks in another chain, which enters us into a subtree. We tally votes by summing over the subtree, and then O(1) drop the subtree.

You could've longer term ones where the users locks on the original chain, and the unlock operation requires a Merkle proof that the account no longer exists on the delegated chain.

In all these cases, we provide a Merkle proof into the original chain, which the recieving chain processes. It's much more efficent if we merge these like we (should) do for PoV data.

You could've locks that require messages before unlocking too here, but then you're consuming relay chain time unecessarily.

[acatangiu]

I don't like that we have to add even more complexity to make the system "usable", but seems like this is the status quo and a necessary evil right now.. I would however try to minimize or do the simplest "patch" possible instead of a complicated generic solution (hoping the patch will also go away later).

AFAICT the "root cause" of this issue/situation/pain-point is that most of the Polkadot users have accounts on the Relay chain, whereas all assets related activity happens on AssetHub.

• So first of all, I would not try to "patch" this for all system chains, just AssetHub should be enough, no? Does anyone have any practical usecase requiring this on another system chain?
• In the future, with JAM, there will be no more DOT/ED on Relay Chain so AssetHub (maybe Plaza) will be the main entrypoint for DOT for any and all users and this whole issue will just go away.

[joepetrowski]

In the future, with JAM, there will be no more DOT/ED on Relay Chain so AssetHub (maybe Plaza) will be the main entrypoint for DOT for any and all users and this whole issue will just go away.

Yeah, in re-reading my own issue I kind of agree. I wouldn't even think about JAM here, way too far out.

If we go the Plaza direction, we should do a "rip the Bandaid off" maneuver and get staking and most accounts there and just kill them on the Relay Chain.

Some applications will require a bit of DOT on People for Identity or Collectives, but the former is a "one time thing" in most cases, and in the latter I think it's a reasonable expectation that members of collectives are "power users" and we can expect a bit more out of them.