Asset Hub Brainstorming Session - Call Notes and Discussion Continuation

[nico_a]

Hi Everyone,

I wanted to share some insights from a recent call where we discussed the current state of Asset Hub and Token Transfers and its impact on both DevEx and UX. Below are the notes from the call, along with the recording and some discussion points for further exploration.

Context of the Call:
The onset of meme coin season on Polkadot has brought a surge of activity to Asset Hub, while also highlighting some significant pain points users encounter during token transfers between parachains. Some notable instances of these challenges can be found in the following links:

• Forum Post on Sufficiency on AH
• Tweet Thread on Moving $PINK from Bifrost to Hydra

While these examples aren’t exhaustive, they encapsulate the general pain points experienced in the current state of Asset Hub and Token Transfer UX.

Call Attendees:

• Parity Engineers
• Parachain CTOs & CEOs
• Ecosystem Agents (Velocity Labs, Papermoon, Opengov.watch)

Desired Objectives of the Call:

• Identify the most urgent problems related to Asset Hub and Token Transfer DevEx.
• Establish improved communication channels between Parity core engineers and Parachain CTOs/Devs.

Notes of the Call:

Communication between Parity and Parachain Devs:

• There’s a recognized need for enhanced communication channels to facilitate better understanding between Parity and Parachains regarding issues and use cases.
• Focusing on common interaction points like XCM and System Chains can streamline communication and problem-solving efforts.
• Parachains require better visibility into potential breaking changes to avoid unexpected disruptions.

Discussion around Token Transfers:

• A lot of the bad DevEx comes from the lack of documentation specifically around XCM. Unfortunately, currently there is only 1 person working on XCM and although they are hiring more people, it’s been taking longer than expected.
• A lot of the issues are discovered already by users when they try to do things like moving tokens around and they push their frustration to the Parachains teams. Parachain teams then channel those frustrations to Parity as the root cause of the bad XCM and Token Transfer DevEx.
• One way of trying to solve for these issues is for Parachain teams to come directly to Parity with the specific problems that they encounter when using XCM or Asset Hub when they aren’t finding an optimal way of getting their ideal UX result. Parity can better cater to those specific issues and try to solve them as opposed to these being brought up once hundreds of users are encountering these issues.
• Although Parity claims to be users of most of the parachains on Polkadot, it is impossible for them to be experts on all of them. That’s where they rely most on Parachain teams coming to them with specifics around how the expect XCM and System Parachains to work for the specific use cases that they are building.
• Some parachains say that these use cases are also out of their control (i.e meme coins) and they don’t have a chance to voice the issues beforehand. Hydra sees most of the problems coming from the SDKs that Parity provides for them to use that don’t generally work in their intended ways. They agree that these the mayority of the use cases should be tested beforehand but at the same time because they don’t have troubles using the system, they have the trouble of not knowing what use cases are available (chicken-n-egg problem)
• Some see the issue of the lack of Product people on Parity rather than the lack of developers. Apparently this has been brought up with Pierre before and is currently an undergoing discussion to see if a Product Manager would fit into their team.
• Velocity Labs proposed to play this role of the Product Manager to bridge the gaps between Parachains and Parity. They are a team specifically focused on solving these issues for the ecosystem and have the resources and expertise to fill these gaps, specifically around Token Transfers.
• Everyone agrees that a lot of the issues boil down to the lack of tooling to abstract away all of these complexities
• Alberto also brought up some other ecosystem wide gaps like the lack of Custodian support which are gaps that exist when compared to other ecosystems
• There are some issues that are outside of tooling specific for just AH and are issues that parachains themselves need to solve for. One example of that is the diversity in types of token metadata and token standards, and the ways to calculate XCM fees. There needs to be some ecosystem coordination to be able to solve for the lack of standards around tokens to make token transfers and composability a lot easier.
• Given that XCM isn’t feature complete, we need to have an intermediary solution with an SDK that supports at least 90% of the ecosystem by having it recognize the 2 or 3 different asset types and token metadata types. With this, most of the new or existing parachains will be heavily incentivized to use the existing tokens and metadata types to be immediately supported by this SDK.
• Another problem that was brought up was the issue of RC and AH being both reserve chains for DOT and making it hard for parachains to be able to support DOT transfers from RC → Para → AH. We agree that there are ways to solve this but that we should implement the same solution for all parachains to avoid exacerbating the problem further by having hundreds of different implementations of it.

Closing Thoughts:

• Many challenges stem from a lack of tooling around XCM, Asset Hub, Token Standardsa and Token Metadata.
• Enhanced two-way communication between Parity and Parachain Devs is imperative, with regular calls planned to address ongoing issues.
• Velocity Labs will spearhead tooling efforts and leverage the DeFi Infra and Tooling Bounty to fund necessary developments.
• The formation of the Tooling Collective will also contribute to addressing gaps in tooling.

CALL RECORDING

Ideally we can continue the conversation on this thread or at least get other’s peoples thoughts on what they think the issues are and how their solutions should be approached.

[acatangiu]

I want to expand on one of the topics:

What: single asset can pay fees across the ecosystem

If we want minimal-friction UX, more apps flexibility, and to maximize adoption across the ecosystem (not just Asset Hub), we need ubiquitous support for same single asset being able to pay for all fees on all chains.

This single asset can be DOT or USDT or USDC (or other?), or even all three. The crux of the matter is to be able to pick one asset for paying fees then effortlessly glide across the Polkadot ecosystem.

How: JIT swaps or native weight trader

There is another thread discussing ability to completely use USDT/C for paying all fees on Asset Hub (on top of or as an alternative to already supported DOT): Sufficiency on assethub - #22 by joepetrowski

The plan for Asset Hub is to use pallet-asset-conversion and allow JIT swaps from any asset to DOT and thus effectively pay fees in that asset (where “any asset” could be USDT and/or USDC and/or anything).

The catch here is that for JIT swaps to work, the chain needs a local liquidity/swap pool for DOT and said asset. So, in practice, it won’t really be “anything”, but only assets that have pools set up against DOT and also have healthy liquidity in them so as not to get burned/pwned on swaps.
For our desired outcome of paying fees in USDT or USDC, this is fine, I expect on AssetHub to have a DOT/USDT pool and a DOT/USDC pool and both to hold healthy amounts of liquidity.

But what about all other chains?

We can’t realistically expect all Polkadot chains to deploy pallet-asset-conversion and USDT/DOT pools. Even if they did, we could never lock enough liquidity in all of them. It would just fragment the (not that big) existing market maker’s liquidity, and it’d be a bad idea anyway to force this kind of business-specific operation to chains that have unrelated business usecases (it’s a non-starter even for system parachains - who would provide liquidity on BridgeHub or Collectives, etc - they have a completely different purpose).

The only other way known to me is to configure weight traders for each of these assets we want to be able to use for fees, and natively pay with them.
This is (technically) very simple to implement, and has near zero maintenance overhead.
AFAICT the only challenge here is economical in nature - it takes away some of the utility of any utility token that was also being used to pay for fees.

Chains that really need/want that utility, could still maintain it by allowing adjustments to the stable coin weight trader to track the native asset (utility token) value (same principle as doing asset-conversion but maybe with more relaxed requirements - price tracking could be offchain, price adjustments could happen less often, etc).

Who: which asset?

The obvious choices for me are DOT and/or one/two stable coin(s). Both of which have advantages and disadvantages and need economic analysis, so we can spin that off to a separate thread if we agree we want it to begin with.

[joepetrowski]

@acatangiu

There is another thread discussing ability to completely use USDT/C for paying all fees on Asset Hub (on top of or as an alternative to already supported DOT): Sufficiency on assethub - #22 by joepetrowski

The plan for Asset Hub is to use pallet-asset-conversion and allow JIT swaps from any asset to DOT and thus effectively pay fees in that asset (where “any asset” could be USDT and/or USDC and/or anything).

There are some subtleties here that I think are important to note. Primarily, the goal of asset conversion is not to “completely use” other assets like USDT/C for fee payment, but is actually in the direction of your post, which is only to use DOT for fee payment. The way things stand pre-asset-conversion, sufficient assets are valid fee-paying assets. As in, the system natively converts the DOT amount required to an asset balance and the signer actually pays that asset to a collator.

Asset conversion, on the other hand, actually makes DOT the only valid fee asset, it just provides an abstraction layer and mechanism that can (under the conditions you note) convert any asset to DOT so that the user doesn’t need to be exposed to the fee-payment mechanism.

When it comes to parachains interacting with Asset Hub, it means they can use DOT, their parachain native token, or the user’s token (like USDT/C) for fee payment and not expose more complexity to the user. When it comes to two parachains (not AH) interacting, then yes they need to agree on some fee asset and I agree that DOT is a reasonable choice.

@acatangiu

The catch here is that for JIT swaps to work, the chain needs a local liquidity/swap pool for DOT and said asset. So, in practice, it won’t really be “anything”, but only assets that have pools set up against DOT and also have healthy liquidity in them so as not to get burned/pwned on swaps.

Second, this is an extremely small catch. Since chain developers have control over the XCM programs they send from their runtime, and AH supports foreign assets, and creating pools is permissionless, it stands to reason that if My Parachain wants to send XCM programs paying fees in MYPC tokens, then it will register the MYPC asset and create a pool. Adding liquidity to the pool is basically a fee-paying escrow DOT account. With respect to “healthy” liquidity and getting burned, we are talking about extremely small amounts here. Most transactions on AH are well under 0.01 DOT fees, and you don’t need large amounts of liquidity to facilitate that.

[acatangiu]

On a separate topic that was mentioned in the call: I just opened a thread discussing how the ecosystem should handle “the problem of multiple reserves” as evidenced by Asset Hub.

Managing SAs on multiple Reserve chains for same asset

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 re…

[joyce]

Following up on the call we had last Wednesday, here are the notes:

Foreign Assets Registration process

Parity will enhance the documentation on how to create and use of foreign assets, this will also be added to the XCM cookbook.

User stories

@joyce will be collecting use cases that are currently problematic (for users and/or for the parachains). All parachains should submit a detailed description of their use cases and the steps taken in this sheet until May, 17th. This will serve as the foundation to set up a project for: improving documentation, creating new guides and improving AH and its functionality.

The results of this use case investigation will be presented in the next Asset Hub Brainstorming Session. Going forward Joyce (PM) and @liamaharon (Dev) are the main POCs for all topics related to Asset Hub.

Velocity’s Token Questionnaire

The token economy survey is still open and waiting for responses, the results for this will also be shared at the upcoming Asset Hub Brainstorming Session. For now, this questionnaire is only geared towards Parachains in order to find quick wins in terms of their token implementations/standards and bridges. In another round we can think of extending this questionnaire further to wallets and other stakeholders.

Fee payments with generic assets

The asset conversion pallet is live on Polkadot and working, here’s a JavaScript script that Joe generated, it showcases how to create a pool, make a transaction, swapping assets in the pool in order to pay the fee and paying fees in that token.

We currently can’t pay XCM delivery fees with any assets other than DOT/KSM, but non-XCM transaction fee payment works fine - here is the issue to it.

Long term vision for the usage of the asset conversion pallet should be that users and parachains can use Asset Hub and pay their (transaction) fees with the parachain’s assets without having any DOTs, for that we also need to maintain the pools funded.

Existential deposits via Asset Conversion

RFC 11 (rejected) proposed using asset conversion to create new accounts/funding the existential deposit. When transferring assets to accounts without existential deposits, you could convert the asset to acquire the existential deposit by debiting it via the asset that you’re sending. Problem with that was that users would be confused if the amount of assets arriving would be less than the amount sent. Another problem is that currently parachains can’t tell if the account exists/has existential deposit on asset hub or not, ideally you could pull this information from an XCM call and tell the user, which can then decide if they want to proceed with the transaction or not.

General goal is to allow users to do balance transfers in any asset and cross-chain, the question is now where the complexity should reside. More discussion around this will follow on the forum.

Ramp network has an implementation of Parachain deposits using asset conversion ready, it will be rolled out after testing and if it works Parachains can integrate it as well.

Issue with DOT as a reserve on RC and AH (forum post discussion here)

Forum Post TL;DR: Migrate the DOT reserves of all parachains into Asset Hub and have Asset Hub as the main hub for the reserves of all assets, not only DOT. So you only have to have application specific channels and not asset specific channels in order to do transfers.

The migration should be done Parachain per Parachain and be individually adapted, so that everyone moves to the new logic - Parity is willing to support teams with technical questions to that. Still a generic migration would be desirable, for that the only solution currently proposed is to create a pallet that automatically handles your software accounts.

Having Asset Hub as the main reserve location could also open up the possibility of staking via Asset Hub.

Address format unification (forum discussion here)

Will be discussed with UX/UI teams (wallets, etc.)

XCM fees estimation

Parity has designed and proposed some runtime APIs that would make it easy to estimate complex multi-hop, multi-chain asset transfers. The proposal can be found here and they’re awaiting feedback.

Funds stuck when sending meme coins through Asset Hub

Some users faced an issue with transferring assets from HydraX to AssetHub. USDTs were trapped during the transfer due to a misconfiguration of the fee. The amount of USDT sent was too small to cover the processing fees on AssetHub, leaving the funds stuck and inaccessible, even though the amount of DED included in the transaction was big enough to cover all the fees. There is a mechanism allowing users to claim their assets, but it doesn’t help because the trapped amount is too small to pay the necessary fees. The current claim mechanism expects all fees to be covered by the claimed amount itself, even governance won’t help here since the amounts are too little. Parity wants to work on a better claiming mechanism.

Related issue by @xlc : https://github.com/paritytech/polkadot-sdk/issues/901

Transfers from Kusama’s treasury to a Parachain’s Polkadot account

The goal is to add KSMs to the Hydra DX Omnipool, which is on Polkadot. The plan is to transfer KSM from the Kusama treasury to Hydra using the Kusama<>Polkadot bridge. However, the existing reserve transfer process only allows hopping between asset hubs, preventing a direct transfer from the Kusama relay chain to HydraX.

Hydra is asking for a XCMs call to facilitate the transfer, which will include multiple hops from Kusama to Hydra. Parity already has a solution for that which will be included in XCMv5.

Action items

@nico_a and @joyce to present the results from the token economy survey and the use cases

@joepetrowski to open up the discussion on ED again

@acatangiu to share the XCM call for facilitating transfers from Kusama to Polkadot

CALL RECORDING

[spazcoin]

@joyce I’d like to add a use case to your spreadsheet.

from a non-dev perspective, I’m trying to create XCM calls in Polkadot.js for Parachain governance to control funds in their sibling accts on other chains, such as depositing treasury funds into the Omnipool. I expect to be able to pay XCM transfer fees in either the native asset of the XCM sending chain or the XCM receiving/executing chain. (so either CFG or HDX for an XCM call from Centrifuge governance to HydraDX chain)

This shouldn’t need pallet-asset-conversion. I’m not worried about pre-calculating the estimated cost. XCM call can simply withdraw a number of tokens that should usually be “enough” and then RefundSurplus at the end.

Although I don’t see it documented, I heard from the Hydra team that you have to use the native asset of the sending chain, but I’m having issues with that failing silently or resulting in “Corrupted State” when testing with Chopsticks. From other forum discussions perhaps the fees can only be paid in DOT? That doesn’t make sense for XCM transactions not originating or executing on the relay chain or a system chain. (specific calls and errors here: silent fail or corrupted state from XCM calls? · Issue #751 · AcalaNetwork/chopsticks · GitHub)

[joyce]

thanks @spazcoin, I gave you editor rights. As mentioned above:

We currently can’t pay XCM delivery fees with any assets other than DOT/KSM, but non-XCM transaction fee payment works fine - here is the issue to it.

This might be related, but we will have a look at the chopstick issue as well to be sure and reply there. Thanks for providing the link here.

[IkerParity]

Thanks for the detailed write-up @joyce !

@joyce

Hydra is asking for a XCMs call to facilitate the transfer, which will include multiple hops from Kusama to Hydra. Parity already has a solution for that which will be included in XCMv5.

Do we have a main reference to follow the new functionalities and progress around XCMv5?

[joyce]

hey @IkerParity, here is a meta issue linking to all changes that will be included in v5.

[joyce]

Summary of the AH user story outcomes

We’ve got replies from 2 teams. 3 out of 9 cases are rather business related, than technical.
The feedback shows that there’s a lack in documentation and awareness about the scope of features provided from the system. With that said, we will arrange a Webinar for both Asset Hub and Bridge Hub, where we will explain the implementation concepts of both and showcase how to conduct the user stories that are currently requested in the feedback form. We will inform you about time and date of the Webinar.

Coming to solutions that we can provide for now:

We’re currently working on a guide to show how parachains can pay fees using other assets than DOT. For now, there’s also a Polkadot JS API documentation provided.

We highly recommend to use AH as your DOT/KSM reserve instead of the Relay Chain.

[joyce]

…and we’re excited to invite you to our upcoming Asset Hub and Bridge Hub Webinars!

You will find an invitation to each webinar under this calendar link. The agenda and presenters are yet to be confirmed, so make sure to subscribe to the calendar in order to stay in the loop. In general, we plan to cover the commonly requested use cases and explain the underlying concepts of the technology. There’s no need for registration – simply subscribe to the calendar and join us on the day if you’re interested.

Asset Hub Webinar
Date: July 17th, 2024
Time: 4:00 PM - 5:30 PM CET
Platform: Google Meet

Bridge Hub Webinar
Date: July 18th, 2024
Time: 6:00 PM - 7:30 PM CET
Platform: Google Meet

We look forward to your participation!

[joyce]

We’ve restructured the webinar and will be holding a series instead of just one AH and one BH webinar.

Please find below the agenda for the upcoming AH Webinar (Jul 17th, 4PM CET):

UX fragmentation in Polkadot as a Heterogeneous Multi-Chain Ecosystem

• Heterogeneous multi-chain what?
• How we handle “trust”:
  • Chains sovereignty, inter-chain trust assumptions
  • Chains’ sovereignty, inter-chain trust assumptions
• How sovereignty and heterogeneity fragments the ecosystem
• Core case study: cross-chain asset transfers
• Core case study: On/Off ramps, CEX integrations
• Ecosystem-level solution without sacrificing benefits: AssetHub System Chain
• AssetHub trust model, ForeignAssets
• AssetHub as a proxy for accelerating exposure to new integrations
  • On/Off ramps, CEX integrations,
  • Bridges integrations,
• Un-fragmented cross-chain asset transfers user stories

The first webinar will be held by @acatangiu

[taqtiqa-mark]

@joyce

Polkadot as a heterogeneous multi-chain Ecosystem

Can you clarify the scope of “multi-chain”?
Does it extend to ETH, SOL, etc., etc. Or is it limited to parachains?

[joyce]

We will discuss how using Asset Hub directly provides access to existing bridges, but we won’t cover how to integrate bridges into one’s Parachain. The first webinar will solely cover the theoretical part. We will have live demos in the webinars that follow.

[joyce]

Moved all topics related to the Webinars to: Asset Hub Webinar Series