BTW from a technical perspective it is also better to do this change to async backing now, before the state of asset hub is bigger and we may need to migrate more data.
Asset Hub Migration: monthly update
Delayed progress on the migration
The timeline has been updated to reflect our current estimation of the most realistic timeframe for the Kusama migration. We’re expecting about a 6 week delay due to complications with integrating the new staking mechanism and the migration tests not going through. Apologies for the inconvenience, but we want to ensure everything is properly set up before proceeding.
Sunsetting AHN, continuing with the migration on Westend
We plan to roll out the migration on Westend in mid-April. This will allow Parachains to test their runtimes with the migrated state of Westend.
We are currently gathering feedback on the overall migration process from test participants and will integrate this feedback into upcoming testing phases.
Asset Hub Next will be sunsetted by mid-May. If you haven’t had the chance to test it yet, feel free to do so until then. The materials can be found here (visible only if you’re in the telegram support channel), or see above the last monthly update.
Asset Hub Migration: monthly update
- The staking changes are now merged
- Migration code is complete and ready to roll
- Update on the timeline: AHM on Westend is scheduled for May 8, Asset Hub Next will be sunset 4 weeks later
- Implementation retreat follows the week after migration on Westend – a chance to review the design end-to-end and do a dry run before Kusama
Hi @joyce , would you be able to provide an update on the migration date?
Polkadot Staking Dashboard disabled Westend in production on the 8th in preparation for the migration, but I’ve now been advised that it is happening next week?
Would you be able to shed some light on what has been happening internally? The actual block number of the migration start would be really useful so we can do our own date calculations too.
Many thanks
I have a small suggestion about how wallets and DApps should treat AHM, which I will interim post here. I have raised this with the owners of the official FAQ to also integrate it in there.
Generic DApp Migration Flow
Assume the relay chain in which the migration happening is RC
, and the corresponding asset-hub is AH
. RC could be either Westend, Kusama or Polkadot, for example.
The overall takeaway is that most DApps would work normally on RC until migration starts. Once it finishes, they would have to switch their RPC endpoint to AH. The question is when and how to do this:
- Look into the list of pallets in
RC
(from the metadata, which you can get via PJS or PAPI) and see ifpallet-rc-migrator
is present. - If no, migration is not even planned yet. Connect to RC
- If yes, check if
pallet-rc-migrator::migration-stage
storage item. Then:- If set to
Pending
, connect to RC. Migration is still not happening, and RC works as expected. - If set to
Finished
, connect to AH - If any other state, show a banner that migration/maintenance is ongoing.
- If set to
During migration/maintenance is ongoing
:
- You should not allow users to submit any transactions as they will 99% fail, and it will only incur fees.
- To show user data is a bit more tricky. A user’s data (their account, proxies, staking info) might be still on RC, or on AH, depending on how far we are into the migration. I suggest these options:
- Simplest option, you can not show anything. Not user-friendly, and user might panic.
- Best is to show the aggregate of the user’s data in RC and AH.
- Middle ground would be to cache the last know user-associated data on your backend, and temporarily use that.
The nice thing about implementing the above is that it can already be a part of DApps code today, and it won’t interfere with anything. Moreover, you can use tools like chopsticks to test the migration starting (see start_data_migration
in pallet-rc-migrator
).
All of this can be seen in this diagram:
Hi there, I have been missing out on AHM for a long time and recently learned about this.
I feel it needs to be addressed ASAP and have consulted several documents but have not had the desired results.
I know a few things in bits and pieces.
- ED can be lowered, or ED can be replaced by an Asset other than DOT.
- Tx fee can be paid by Asset other than DOT.
Where are the functional differences between Polkadot Relay chain and Assethub as summarized above?
The Word migration plan you guys are presenting says that you will present a tutorial to the migration, but I could not find it.
I need help from the development team.
Status Update
We carried out the Asset Hub Migration on Westend, migrating Staking, Governance and Balances along with associated functionality off the Relay Chain. These are now on Asset Hub.
Bugs and fixes
The migration was largely successful and has provided valuable insights. During the staking migration, we encountered an unexpected issue where an excessive number of messages were sent. This was due to the backpressure system not being properly engaged for this specific pallet. The issue did not surface in earlier testing, as the message volume was insufficient to trigger it.
Testing with the complete state helped uncover this edge case, which temporarily stalled Asset Hub. Recovery took approximately three hours and involved targeted corrections to Asset Hub’s state. Thanks to this process, we have improved our understanding of the backpressure mechanisms under full load and identified enhancements to future migration testing scenarios.
Following validation of the corrected state, staking has now been successfully re-enabled on Westend.
Next Steps
Now that we have migrated these functionalities to Asset Hub, we will continue to sunset Asset Hub Next as communicated previously. Any tests which were previously using Asset Hub Next can be switched over to Asset Hub, which includes the state.
Asset Hub Migration on Paseo
After polishing the migration with AHM on Westend, we are now planning the upcoming Paseo AHM. We will begin preparing the runtimes for Paseo based on the polished version of the Westend migration by the end of this week.
The Zombie Bite-based dry-running framework is complete, enabling us to simulate the migration using the actual Paseo state before live deployment. This will give us the ability to detect any issues before we go live on the live network, and avoid any issues like those we saw on Westend.
As mentioned before, you can refer to the documents below for guidance:
- Critical User Journeys for external testing
Please test these use cases and come back to us if any user journey is missing or not working as expected. - Asset Hub Migration FAQ
Check if you find an answer to your question here first - Migration timeline
We’ve updated the migration roadmap to reflect realistic timelines, please check them out and plan accordingly.
Thank you,
Parity Technologies
hey @ross,
hope the message above answers your questions. If not, let me know.
Here you can find an article about Asset Hub and here is a short description of the Relay Chain. You can think of the Relay Chain as the core of the Polkadot network — it takes care of finalizing parachain blocks and enables secure cross-chain communication.
Asset Hub is a system parachain governed by Polkadot’s on-chain governance (OpenGov). Its initial focus was on asset management (as the name already tells). However, we’re now expanding its scope to handle Staking, Governance and Balances. This is to improve the DevX and better support service providers, application developers, and its users.
Please join the Telegram Support Group to receive all updates, including guides and tutorials.
@joyce
Thank you for your response.
I am developing polkdot as an individual while holding assets on the exchange. I read the documentation you shared, telegram and some materials and understood what I have to do.
-
Regenerate the address
- I understand that the balance is moved to a different assethub address than the Relay chain during AHM because the prefix changes from 0 to 2.
-
Consideration of ED
- It was previously recognized that 1 DOT was required, but I understand that it will be lowered to 0.01 DOT. The validation logic needs to be changed with this in mind.
Since I am currently only dealing with DOT, I do not need to consider sufficient tokens.
- It was previously recognized that 1 DOT was required, but I understand that it will be lowered to 0.01 DOT. The validation logic needs to be changed with this in mind.
-
Change of endpoints
- The RPC endpoint needs to be changed to that of Assethub.
Please let me know if there is something wrong with my understanding.
[EXTERNAL] Asset Hub Migration success says “we strive to simplify the process as much as possible with clear, straightforward tools and instructions” but I haven’t found this yet.
Also, many developers would like to see a list of the differences in the logic that needs to be changed when migrating from polkadot to assethub, and the differences in the same specifications as before.
Furthermore, please let me know about AHM.
We are aware that XCM can be used to migrate balance to Assethub prior to mid-August.
My question here is what will the fees be?
Am I correct in understanding that there is no fee for the automatic transfer in mid-August, but there is a fee for moving the balance to xcm in advance?
Last but not least, I feel that many exchanges and developers do not know too much about this update.
I too have been following the SDK and js release notes, but only recently learned about AHM.
If many exchanges were not aware of this update, what does the developer team think about the state of awareness of AHM, as users will not be able to transfer funds when AHM occurs in mid-August?
Are there any plans to change the name of asset hub because it lacks brand reference. For example, if the asset hub chain is built into the wallet, users may not know that it belongs to Polkadot. If the name Polkadot asset hub is used, it may seem redundant. Why not call it dot-hub or jam-hub?
Questions on Identity Migration and the People Chain
As we know, staking, governance, and balances are being migrated from the Relay Chain to the Asset Hub to streamline user experience and reduce fragmentation. My questions are:
-
Is there a plan to also migrate on-chain identity (the Identity pallet) to the Asset Hub?
-
Will the People Chain, which currently handles identity, be merged or integrated with the Asset Hub as part of this migration?
With many core user functions moving to the Asset Hub, it would be great to have our on-chain identity (which is itself a valuable asset) managed in the same place. This would help reduce fragmentation and make the overall user experience much smoother.
Are there any technical or design reasons why this isn’t currently planned, or is it under consideration for the future?
I also apologize if this has already been mentioned here or elsewhere!
The address is not stored in state, only the AccountId
is. The SS58 encoding of addresses are network-wide; as in, your address on Asset Hub is the same as on the Relay Chain. The prefixes you are referring to (0 and 2) correspond to Polkadot and Kusama, respectively. That means the SS58 prefix for Polkadot is 0 regardless of the chain: Relay Chain, Asset Hub, People, Coretime, etc. Even with a different prefix, the encoding is purely a front-end rendering tool to help users disambiguate networks; the public/private keys associated with the addresses will remain the same. No action will be needed on the user’s part regarding addresses.
Almost nothing will change unless you are a validator (in which case some things related to session keys will change). What kind of application are you maintaining?
Correct, if you choose to teleport the assets yourself, you will need to pay tx-fees. If you instead let the system handle it, because balance transfers are part of the migration, no fee will occur. The transaction fee to teleport will be the same as any other teleport.
We are in touch with the bigger ones and many others. We are aware that we can’t know all of them. Of course we are open for exchanges to get in touch with us and we will provide support. We have also prepared a notion page that can be found in Google when you’re looking for keywords like “Polkadot integration failed” or similar.
Furthermore, we plan to have a banner on the Polkadot website close before, during and after the migration so that everyone is warned.
Polkadot was designed such that users don’t need to worry about which specific system chain they are using. Users should not see the words “Asset Hub” and there should be no brand reference. Users should just see that their assets are on “Polkadot”. There is no need to specify which system chain.
There are no plans for that currently in sight.
No.
The primary motivation for AHM is to get state and users off the Relay Chain. Maybe we should have called the project “Relay Chain Emigration” :). Since Identities are already off the Relay Chain, mission accomplished. As a future phase of Polkadot, of course we are open to arguments about re-architecting some of the system logic if it makes sense to have synchronous interaction between subsystems.
@joyce
Thanks for the response!
Your answers have deepened my understanding of AHM, and I deeply appreciate it.
And I realized that I have made some misconceptions.
I hadn’t found anything about Notion either, so that was very helpful.
I now have peace of mind that my AHM will work.
I will leave it to the automatic migration as it is a pain to deal with XCM.
My question here is, is there a document that outlines the specific steps for opt-in?
I have seen it discussed in the following issue, but have not found any practical documentation.
Thanks again for the support of the development team.
Users from EVM will first add a chain from chainlist, such as “Westend Asset Hub”, and then metamask will show it in the chain selection. External users don’t care about the system chain parachain, but they want to know which chain they are on. Currently, all they can see is “asset hub”. It is impossible to hide the chain name, not to mention that this is the entrance to the brand.
I disagree, that is just describing how things are currently. Yes, the words “asset hub” may show up in some engineering documentation, like in RPC URLs for wallet connection, but it need not be exposed to users. Even for developers, for all intents and purposes, Asset Hub is the default “contract deployment location” in the Polkadot system, so there’s no need to expose this detail. Deploying to Asset Hub is deploying to Polkadot.
Again I disagree. External users may care about the consensus system they are within, but not the chain. This statement is akin to saying that Netflix users want to know which Amazon EC2 instance they are streaming from. They don’t care, the boundaries of the world are “Netflix, YouTube, Amazon, etc.”, not the underlying architecture and components of each service.
If Polkadot wants to play behind closed doors, why bother with EVM compatibility? Metamask, the wallet with the largest market size, will hide the “asset hub” for you, thank God.
The reality is that users come from CEX, and CEX ask which chain. Current users have some funds on the Relay, and when you need to do things, as simple as setting an identity (people chain), or do something on the AH then not only do you have to request to sign an XCM to transfer funds (confusing for users if they don’t know they have to do things on another chain), but you also have to sign a second tx to set the identity or do something on AH, bc those 2 tx have 2 different origins, and you can’t batch them.
We, the Dapp devs do all we can to make these things easy for users, but saying “users don’t have to know”, is not true, they have to otherwise they sign things without knowing what they are doing, which is an open door to getting pwned.
Asset Hub Migration Monthly Update
Westend Migration
Asset Hub on Westend now fully supports the pallets Governance and Balances.
The staking enablement is still ongoing, until the team finds the root cause of this issue. While staking transactions are possible, staking elections are working in a degraded manner, only electing a subset of the nominators. Under certain circumstances, we observe a discrepancy between what the collator is producing, and what is executed in the relay chain validators. Note that this issue is causing occasional downtime for Westend Asset Hub.
Next up is the migration of Asset Hub on Paseo. More details about the migration above.
Asset Hub for Polkadot Vault users
If users import AssetHub metadata to generate accounts after the migration, they’ll end up with a new public-secret key pair — which won’t be linked to their original balance. @burdges wrote a short guide for Vault users explaining how to use an account on a different network than the one it was originally created for. Read his post and Polkadot Support article for more.
Migration process for UIs
We’ve added the General Dapp Migration flow to the FAQ, which includes a diagram that should support you when in doubt during/after the migration.
Stay informed about the migration
Check the What You Should Do section on this page for all links to important documents, chat groups, and channels that will help you stay updated throughout the migration process.
Hey,
Will there be two paseo chains that run revive?
The current one Paseo Contracts chain(paraid: 1111)
and soon the paseo assethub?
Thanks
~flipchan