Managing SAs on multiple Reserve chains for same asset

Ecosystem
,
1

Asset Hub as a DOT reserve

Multiple parachains in the ecosystem are currently facing a dilemma:

How to handle DOT reserves on chains other than PolkadotRelay? Nowadays in particular, handling Polkadot AssetHub as a reserve for DOT - which is seeing many new usecases.

The main problem with “ChainX” allowing multiple chains as a reserve for DOT (or any asset for that matter) is that “ChainX” needs to balance its SAs (sovereign accounts) on the reserve chains so that when their users “claim” a reserve asset (i.e. transfer DOT to Relay or AH) their SA there has liquidity to handle it.

Generalizing the problem before looking at solutions

The problem is not limited to DOT. The problem ultimately comes from having both reserve-based transfers as well as teleports allowed in our ecosystem.
Once you allow a teleport between two chains, then both of those should be able to act as reserves, otherwise the teleport doesn’t make sense.

E.g.: ChainX registers TOKX as a “ForeignAsset” on AH and teleports liquidity there. ChainX actually wants to allow AH to act as a reserve for them. That way, TOKX is automatically exposed to all the other chains/bridges/CEXs/etc that are already (or will be) integrated with AH.

The “users” of TOKX will have the same issue: TOKX’s reserve is split between AH and ChainX.

Solution(s)

Automated SAs rebalancing

Unfortunately, there is no alternative scalable option I can see other than supporting these multiple reserves and (auto)balancing SAs.

The silver lining here is that the problem is generic and asset/chain agnostic, and we can decide on some mechanism to auto-balance these SAs, that every chain can use.

E.g. idea: a dedicated pallet for balancing chain’s SAs on other chains. Root/admin can register several SA locations per asset along with some % distribution for each, that periodically polls the remote balances of those SAs and moves liquidity around to stay within configured distribution %.
Or could be some on-demand balancing protocol remote chain registers their SA on the local chain along with a “low balance threshold” that triggers an XCM notification to the owner chain that local SA needs re-topping.

The point is, we decide we need some autobalancing, then someone implements a generic mechanism that all chains can use.

Drop “Teleports” :see_no_evil:

Unlikely, but worth mentioning.

Everything is a reserve transfer. DOT on AH is not exactly the same DOT as on Relay. DOT reserve transferred from Relay can only be reclaimed on the Relay, same for DOT reserve transferred from AH.
For generic assets, “foreign assets” on AH are also not fungible with same assets coming from their “owner” chain, they have to be kept/tracked separately if we want to not worry about SA balances.

My 2c: it’d be easier for chains, but worse UX for users and the ecosystem.

P.S.: some existing discussions here too: pallet-xcm: add new extrinsic for asset transfers using explicit XCM transfer types by acatangiu · Pull Request #3695 · paritytech/polkadot-sdk · GitHub

5 Likes
2

Currently we only have this problem because of the teleport of AH <> Relaychain.

I have yet to see other “valid” usage of teleporting albeit it might exist ,I don’t think anybody outside of sharded chains would want to use it to transfer tokens unless we have something like spree. It would be huge security concern. That’s why I think disabling teleports or solving this on the problematic chain instead of passing this to everybody else might not be so crazy idea as it might seem.

Some random alternatives to what you proposed could be moving balances of DOT completely to AH, which might not be trivial for relaychain (i.e. Staking) but would go in line with separation of concerns.

Or allowing virtual stacked reserve for the actual chain (in this case AssetHub <> Polkadot) it would be up to them to stack up the parachain account balance from both sources. (Can we use storage proofs here?) we will probanly have async problems though as para block could spend the same funds as relay.

3 Likes
3
  • Teleporting DOT with other system chains (not just AH)
  • Teleporting parachain native tokens with AH

Yes, obviously. That’s why reserve transfers exist.

This adds other problems though. The idea that parachains can teleport their native tokens with AH means that everyone only needs to connect to AH and use it as a reserve location to accept all tokens in the ecosystem, which is N connections, while using each para as a reserve location is N^2 connections.

That’s precisely what we are working on.

1 Like
4

Parachains will likely want to interact with DOT on multiple system chains: BridgeHub, Collectives, Coretime, People, etc.

But, I agree that Asset Hub is “the painpoint”, because:

  • it has the most varied interactions,
  • asset transfers to/from AssetHub usually involve multiple assets not just DOT, which complicates matters.

I’m not sure disabling teleports altogether will improve the situation that much because of then having to deal with “stacked reserves” and their balances which is not that different than dealing with current SA balances.

I do however see a low-hanging fruit:

“All roads lead to Asset Hub”

Parachains move their DOT reserves from the Relay chain to Asset Hub. Subsequent DOT transfers to and fro all go through Asset Hub.
While this is slightly less efficient than interacting directly with another system chain, it eliminates the SAs managing problem for parachains. They have single SA account on AH holding all their reserved DOT.

This is IMO the least disruptive and fastest solution. Back-of-the-envelope implementation plan:

  1. Relay chain provides an easy way to transfer DOT to any other parachain, but going through AssetHub - teleport to AH then reserve transfer to dest - I can implement this in pallet-xcm and expose it as an easy to use extrinsic - reverse direction should be just as easy,
  2. Parachains migrate their DOT reserves from Relay to Asset Hub, then can even stop accepting the Relay Chain as trusted reserve of DOT. In practice, this is a multi-phase process:
    2.1. There will be a window where both Relay and AH have to be accepted as reserves and parachain has to manage SAs - this window can be big or small depending on how fast a Parachain works with wallets to switch over the “transfer method” for DOT to their chain.
    2.2. When deciding to close the window, just teleport SA balance on Relay to SA on AssetHub, stop accepting RelayChain as a trusted reserve of DOT.
2 Likes
5

I was also thinking all roads to asset hub is best, but it might be also problematic as it could break current integrations i.e. for Bifrost vDOT Minting / voting in governance, for the fellowship, salary being bought by polkadot governance and later transferred to assetHub and for any direct governance or treasury action i.e. Polkadot governance DOT LPing in Omnipool or HydraDX DAO voting in Polkadot governance.

I can see that it could work but we need to make sure we don’t break any of this.

3 Likes
6

As a stop-gap solution, I proposed that messages for DOT withdrawal in AssetHub should be routed first through its “true reserve chain” (just terminology for Relay Chain as most parachains see the Relay Chain as the reserve chain for DOT).

Xtokens enabled a flow in which two separate XCMs were sent. The first one was to move DOT from a parachain SA in the Relay Chain to a parachain SA in AssetHub. The second one was to withdraw some DOT in AH to pay for XCM execution fee and transfer whatever asset you needed. This approach relied on:

  • The first XCM message will be executed successfully in all chains
  • There is some DOT buffer in parachain AH SA so that the XCM fee can be paid and after replenished by the first XCM message

Nevertheless, if we route the message through the Relay Chain, we ensure that the message to the relay chain succeeds in routing the message to AH. The message would be something like (Moonbeam InitiateReserveWithdraw → Polkadot WithdrawAsset, ClearOrigin, BuyExecution, InitiateTeleportAsset → AH all of the required instructions). I guess the main issue here is ClearOrigin in the relay chain.

IMO, this is a good approach, but it feels somewhat complex to implement, especially if we are moving away from Relay Chain as a DOT reserve. But wanted to share it here just for discussion.

1 Like