Hello Polkadot community,
I am seeking technical and governance advice regarding xcDOT that remains associated with an EVM account I control on Moonbeam.
After Moonbeam stopped producing blocks, I contacted Moonbeam support and asked whether my xcDOT could be migrated or redeemed. I was informed that they could not assist with an individual xcDOT migration.
Thank you for any guidance from the Asset Hub, XCM, Moonbeam, and OpenGov communities.
I am replying to bump this thread as I am in the exact same situation. My xcDOT is currently completely stranded in my EVM wallet following the Moonbeam shutdown.
Since Moonbeam block production has ceased permanently, regular users have no standard path to bridge or interact with these assets. However, as noted, the real native DOT backing these wrapped xcDOT tokens remains completely secure within Moonbeam’s Sovereign Account on the Polkadot Relay Chain/Asset Hub.
Because Moonbeam infrastructure is winding down, a manual migration from their side is not possible. This leaves OpenGov and the Technical Fellowship as our only realistic path to resolution.
We need a technical solution, such as an OpenGov runtime instruction or an official state-mapping claim portal that can verify frozen EVM balances and credit the equivalent native DOT to our Polkadot addresses.
To help any core developers or Fellowship members reviewing this thread, I am ready to provide my verified EVM address, frozen balance, and historical tx logs to serve as a technical case study.
Could a member of the Fellowship or Asset Hub team please weigh in on the feasibility of an XCM-based or runtime recovery path for these stranded sovereign assets?
Just off the top of my head, these locked DOT could theoretically be moved from the old Moonbeam accounts to the equivalent (same address) Asset Hub EVM accounts?
This would obviously require a Root track Referendum and I may be missing something else here, though..
I don’t know for sure, because ton of stuff changed. But it could be that these accounts are not accessible on AH. Maybe with the revive stuff.
Generally I think this is a reasonable ask and probably something OpenGov could vote on. But someone should get the latest moonbeam state and get all addresses that have their tokens locked up. So, this could be only one proposal and not multiple. The address extraction should be done by some tool that everyone can verify that the list is correct.
If the original addresses are not reachable on AH, someone could write a smart contract that takes a signature from the old moonbeam style address and then sends the funds to a AH account. Before this smart contract is written, the list of accounts is required.
Thank you for weighing in. I agree that a verified signature from the original Moonbeam EVM address could provide a straightforward way to prove ownership of stranded xcDOT. The Moonbeam explorer is still available and, as far as I can tell, balances and addresses can still be verified, so a transparent list of affected accounts should be possible.
The key point is that xcDOT represents native DOT, not simply an abandoned Moonbeam token. Users should not lose their native DOT because the chain hosting its representation was shut down.
In my case, my xcDOT is my entire lifetime DOT holding. I don’t have a single DOT anywhere else. I’d really hope Polkadot/OpenGov can find a trustless, verifiable recovery mechanism rather than leaving these assets permanently stranded.
After an initial investigation, the total xcDOT supply in Moonbeam’s terminal state is 233,451.672748423 xcDOT.
Because no complete backup node is available, we reconstructed a candidate holder set using multiple public RPCs, blockchain explorers, and indexed data sources. We ultimately identified 11,785 non-zero addresses, with a combined balance of 233,450.6800114108 xcDOT. 0.9927370122 xcDOT remains unattributed.
The current results are public here:
Every published balance includes a corresponding Substrate state proof and can be independently verified against Moonbeam’s terminal state root. This means the balance data does not require trusting any particular RPC, explorer, or indexing service.
These addresses likely include different account types such as EOAs, contracts, multisigs, and AA / smart accounts. For ordinary private-key-controlled addresses, control may be proven by signature, while contracts and smart accounts may require different recovery paths.
This is still only a preliminary recovery dataset. It does not represent a final determination of ownership, claim eligibility, or a recovery plan, and there may still be issues I have missed.
The full dataset, proofs, and verification tools are public, and I have also posted the results on X for wider community review:
If anyone finds an issue with the terminal-state anchor, address set, balances, proofs, or recovery assumptions, please point it out publicly.