AssetHub Vision

Ecosystem
1

GM everybody!

I want to share a few current ecosystem issues and how they point to a development direction for AssetHub.

The main argument of this post is: AssetHub should become the default chain to onboard users, tokens, and asset-based integrations (CEXs, DEXs, wallets)

This argument is a continuation of this thread.

Be advised: None of the solutions mentioned below are to be seen as universal or canonical or absolute. They are suggested as a way of thinking in default scenarios that can always be replaced by more suitable specific solutions for your use case.

1. New users should onboard to AssetHub, not the relay chain

New ecosystem users who are not onboarding to a specific chain (e.g. starting as a player on Mythical), but who are more generally saying “I want to check out Polkadot” shouldn’t onboard to the relay.

The existential deposit of 1 DOT does not sound huge to you right now, but imagine the DOTUSD exchange rate getting higher. Paying dozens or hundreds of USD to create an account on Polkadot would be a very bad UX.

ED on AssetHub right now is 1/100th and can be expected to go even lower in the future. New users should onboard to AssetHub (or any other suitable chain)

New users will not necessarily stake or vote, but they will most likely deal with other assets. So AssetHub is the more logical choice.

2. All parachain & ecosystem tokens should be available on AssetHub

AssetHub can already host parachain tokens as foreignAssets with XCM support. Parachain (and any other) tokens can be registered with their XCM Multilocation.

Making as many parachain tokens as possible available on AssetHub would allow for better integrations against CEXes, DEXes, Wallets, etc… and would generally make the life of EVERYONE so much easier.

On that note, it would also make it more likely that those teams make their tokens available for asset conversion and thus provide a gateway for abstraction wrapper SDKs like Apillon to have them instantly available for further development.

3. CEXes should integrate against AssetHub, not the relay chain

If we onboard all users to AssetHub, CEXes should follow suit. If we make more tokens available on AssetHub, CEXes can have one default implementation to make all kinds of tokens from the Polkadot ecosystem available for trading.

Any new token that wants to be made available for trading on a CEX could make sure it is registered as a foreign asset on AssetHub and make this known to a CEX and it could prepare the listing.

4. DEXes/DeFi products can easily integrate against AssetHub, but not so easily against other chains

It’s 2024 and opening XCM channels between parachains is still hard (one big underlying reason being that setting up message-passing subsystems between systems is generally not the most enjoyable experience). But opening an XCM channel from a parachain to AssetHub is comparatively easy because there is established systematic knowledge and operational procedures.

If we make lots of tokens available on AssetHub, DEXes and DeFi products can integrate against AssetHub to access those tokens and make them available in their systems.

5. Wallet experience and development could become easier by primarily working with AssetHub

Wallet users get regularly confused by which chain their token is on (I have 100 BNC in my wallet but they are not on Bifrost. On which chain are they?). This creates a lot of bad UX and customer support tickets.

Wallet developers have to deal with the mess of having the same token on multiple chains and hiding that fact as well as possible from the simple user while making it transparent to the advanced user. It is not enjoyable for anyone.

Having more tokens available on AssetHub and making it the default to deal with them there would simplify the lives of many people.

What do you think?

Is this the right way to conceptualize this? Am I missing something?

I believe that finding consensus on these ideas would allow us to finally arrive at a liquidity configuration for the ecosystem that would allow us to leave some problems in the past that have strained us for much too long.

21 Likes
2

in the long run, i dont think this matters since dot supply is inflationary but the ED does not scale with the dot supply.

everything else makes sense, but in the past ive heard complaints from other parachain teams that they don’t one chain to “siphon” liquidity from other parachains.

1 Like
3

I really hope this type of confusion is a problem of the past. We’ve pushed an asset-centric portfolio model at Talisman for years now which shouldn’t leave the user in any doubt which chains their token balance exists on.

I think this is a sustainable model for the future as well. Whilst folks might (and let’s say should) use AH as a “home base” for their balances, I wouldn’t want to design a wallet that informs the user’s mindset into thinking they can’t/shouldn’t hold an asset on it’s native chain.

Aside from pushing back on that point, agree with everything else - esp. making AH more prominent for new users :slight_smile: .

6 Likes
4

Yes yes yes yes yes.

6 Likes
5

I don’t think AH has to be more prominent. It may play a bigger role behind the scenes, but we should abstract this architecture away from users. People should “use Polkadot”, not “use Asset Hub”. I do think you guys at Talisman do a nice job of this, maybe it’s just wording.

6 Likes
6

Hi Tommi,

Nico here from Velocity Labs, where our mission is to make Polkadot into the best platform for DeFi applications. We firmly believe that Polkadot offers developers unparalleled infrastructure, boasting flexibility, scalability, and decentralization – fundamental pillars for any DeFi endeavor.

However, our current reality falls short of this ideal scenario. In most of our issues could be boiled down to two main causes:

1. Accessibility: Transitioning from external venues into a Parachain is notoriously challenging. Whether users are arriving from CEXs or Ethereum, they require extensive Polkadot-specific knowledge to navigate their way in. If we consider the most accessible entry point into our ecosystem, it’s undoubtedly the relay chain (RC) through DOT. Staking, one of the few functions on the RC, has proven successful. I know there are other factors for its success but if it weren’t so accessible, we wouldn’t have ~6bn in DOT staked right now. Now, envision if all parachains, their tokens and functionality were as accessible as DOT in the relay chain?

2. Interoperability: This concept was foundational to Polkadot’s inception. Despite having the necessary pieces at the core protocol layer for this, reality has not met expectations. The flexibility of Substrate and XCM has unintentionally hindered the creation of general standards. The prevailing consensus is that XCM is complex to use and demands significant development resources for implementation and maintenance. Parachains encounter similar hurdles and often resort to parachain-specifc solutions where generalized out-of-the-box solutions aren’t available, thereby exacerbating the problem. Today, the end-user perceives Polkadot more as a collection of disparate systems than a cohesive app store.

Now let me provide more color into how AH plays a fundamental role in solving the two core problems mentioned above

1. AH as the Entry Point for Users

When compared to the Relay Chain (RC), AH is superior as an entry point into the ecosystem. However, there isn’t much functionality available on AH, implying that if users seek do more than just hold a token, they must move to where those functionalities actually exist (i,e parachains). This leads to the idea of abstracting away AH. Essentially, users would likely “pass” through AH in much the same way they do with the RC presently, but with the crucial difference that they could do it with any token registered on AH as well as with a much lower ED barrier. Users shouldn’t need to be aware of AH’s existence if their goal is to reach a particular parachain.

To make this a reality there has already been work done by the System Chains teams by adding Multilocations and AssetConversionPallet. More work needs to be done on the following points:

  1. Improved CEX and On/Off Ramp support for AH (in progress).
  2. Encouragement for CEX/On-ramps to utilize tooling like Asset Transfer API to enable direct-to-parachain flows (in progress).
  3. Implementation of an AssetConversionPallet to abstract away fee payments with non-sufficient assets (in progress).

Velocity is helping out by leading conversations with the relevant services providers to tackle #1 and we’re working closely with Parity and other parachains on #2.

2. Making All Tokens Available on AH

This feature has been live for some time, but unfortunately, only one parachain (afik) has registered its ParaToken there. There needs to be an incentive for teams to do so, which could come from enabling CEX/Custody/On-ramp support for their tokens from AH when they cannot do it from their own chain.

This initiative is more about coordination than engineering. Velocity will spearhead efforts to ensure that parachains are aware of this feature and its benefits, guide them through the registration process, and connect them with available service providers to expand token support.

3. CEXs on AH vs. RC

This is undeniably a resource-intensive task, and Velocity is dedicating time and resources to it. Our current conversations with CEXs revolve around supporting USDC and USDT on AH, which obviously requires them to support yet another chain on top of the RC. Chain integrations come at a cost, and we’re competing for engineering resources that these CEXs must allocate based on where they see the highest ROI for their business. Unfortunately, Polkadot doesn’t fare well in those metrics atm. Velocity has assisted with Binance, Gate, KuCoin, and ongoing conversations with others.

For those already on AH, with the ED conversation taking shape, we’re approaching them to support DOT deposits/withdrawals from/into AH. This outreach began recently, but we believe it could be a relatively simple task for them, given that their hot wallets on the RC already have addresses on AH. It would involve simply mapping those addresses and automating rebalancing with a teleports between RC and AH when necessary. We’ll provide updates on this as the conversations progress.

4. DEXs Integrating with AH Instead of All Chains

This is something that will become increasingly urgent in a coretime-centric world with numerous chains to integrate with. Improved support for AH and more standardization around XCM are necessary for this to materialize.

5. Wallet Experience

This isn’t solely a Polkadot issue but rather a broader multi-chain UX concern. Talisman and others have made significant strides in abstracting away the complexities of a multi-chain ecosystem, but there is still work to be done with other general points of interaction. For example, an ecosystem-wide block explorer is needed. Polkaholics have made some progress in this regard, and Subscan has enhanced its XCM analytics, but there still isn’t a platform/UI where users can view XCM messages or token transfers across the ecosystem without having to visit specific parachain block explorers.

6. Bridging
AH will also play a role in the way BH and Snowbridge will function and service the ecosystem. We were planning on putting out a separate post to discuss about the bridging experience in general. There is also a lot to be said there and a lot of work that can be done to actually improve it. More on that soon!

Happy to hear people thoughts on the direction we’re taking both in terms of AH and how Velocity is working towards that vision.

8 Likes
7

We definitely see the advantage of Asset Hub as an entry point into the Polkadot universe for CEXs, DEXs and ramps in terms of integration and maintenance effort, which will make it easier for parachains or para-objects to obtain liquidity. From the end-user perspective, it’s best if they only see “apps” and do not have the need to see “chains”. Obviously this is easier said than done :smiley:

With regards to the UX and DevEx surrounding XCM on Polkadot, we are hoping to improve this with Ocelloids as a universal solution to track cross-chain interactions. With our latest release of the Ocelloids Service Node and the Ocelloids Client Library, wallets and apps can already use our websocket subscriptions to notify users when their cross-chain transfers are executed on the destination. We also support long-running subscriptions delivered through webhooks to monitor all XCM filterable by sender.

We have a demo app that shows all the necessary information regarding a cross-chain transfer. It would be easy to aggregate the information across all chains and store in a database to provide a UI for ecosystem-wide cross-chain interactions. Of course, this won’t be a full-fledged explorer but users will be able to see if their transfers or XCM actions were successful, failures, and if their assets were trapped along the way.

We are currently focused on XCM but we do plan to generalize to other use cases. We recently decoupled the ingress layer, where block ingestion happens, from the execution layer, where processing, filtering and matching happens. We added support for asynchronous request-response to the ingress which means that by simply connecting with the ingress, you will be able to access both blocks and storage across all supported chains. This will pave the way, for example, to track cross-chain balances, assets and tokens holdings. With the same request-response model, we can also open up the possibility to relay signed transactions without the app or wallet having to directly handle connections to multiple chains, providing a supercharged middleware to abstract away the multi-chain world.

Re: standardization and coordination around XCM, it would be great if there are dedicated spaces for such discussions. Besides the lack of parachains registering their tokens on Asset Hub, we’ve also noticed that despite the introduction of unique TopicIds for XCMs and related runtime tools, parachains have not adopted this (or only partially), which makes correlating multi-hop XCMs extra difficult. It would be great to be able to discuss such issues with the relevant parties.

1 Like
8

Both Tommi and Velocity Labs have fair points.
I’m gonna add my feedback as CM and the users pain point i see on many channels, or i have to deal with when users are lost.

I can’t agree more with Tommi: let’s simplify everything.

  1. Should AH be the entry point for users ?
    Maybe not. But the ED “issue” for newbies is a pb for sure. It’s like the 20 locked DOT required to get your id verified, way too much.
    We are living in a BC world where users want 0.0001 ETH gas fees, so imagine 1 ED DOT !!
    If the eco wants the Degens, the shitcoiners, then the DOT ED is a pb. For standard users, it’s not as long as the DOT price is not mooning.

  2. I don’t see any kind of pain pts to do so.
    Users would like to x-chain tokens from chain to chain where an HMRP channel already exists but they just can’t. Work has to be done on both sides declaring a new token etc etc…

  3. Should AH be the entry for CEX/On-ramp solutions ?
    Definitely Yes.

  4. Not necessarly true, Nova/Talisman/Subwallet have demonstrated it’s now OK about the UX.
    The other pain point raised by lolshmizz or others on X is more about the use of different addresses format: if you think about it, it’s too complex.
    We should just stick to the generic address in the ENTIRE ecosystem and that’s it.

People are ETHEREUM-MINDED, 1 single 0x address everywhere: they are lost when they come to Polkadot.
That’s an OG mistake we made collectively.

For the same users, and probably the OG users too, AH/BH are a pain.
As a user, you don’t want to have to deal with these chains, they have to be abstracted.

You want a token to be moved from A to B.
Not From A to X to Y to B → ABSTRACTION REQUIRED

Summary of onboarding issues in general:

  • Users don’t even have to know they use AH/BH, we are losing everyone with this → ABSTRACTION REQUIRED
  • Users want simple actions: I send X on ChainA, I send Y on CEX (AH has to be abstracted here i insist), I send Z from chainA to chainB → ABSTRACTION REQUIRED
  • Users don’t want to have to teleport DOT on AH → ABSTRACTION REQUIRED
  • Users don’t want to deal with ED (the main one being the Polkadot 1 DOT)
  • Users want to use all tokens they have for gas fees. 1 chain = 1 gas fee token is a nightmare to onboard users → UNIFICATION REQUIRED
  • Users want 1 unified address → UNIFICATION REQUIRED
2 Likes
9

Just added a view for the aggregated subscription streams on the XCM Tracker Demo. Looks like this:

xcm-tracker-all-networks
xcm-tracker-all-networks1467Ă—965 166 KB

@Velocity_Labs Is it in the line of what you are thinking of?

Persisting the underlying information to a database will trivial, this is a UI but could be also done in a standalone CLI or TUI app.

Here the repo of the XCM Tracker Demo: GitHub - sodazone/xcm-tracker: XCM Tracker App

2 Likes
10

Additionally, I’d like to have contracts on AssetHub. It lowers the amount cross-chain interactions required for a bunch of use cases and thus improves UX :slightly_smiling_face:

2 Likes
11

A thread about sufficiency on AssetHub: Sufficiency on assethub

Very insightful regarding the different levels of understanding currently present around AH.

2 Likes
12

I just opened a thread discussing how the ecosystem should handle “the problem of multiple reserves” as evidenced by Asset Hub.

1 Like