The prdoc for the XCMv3 removal (pr_13629.prdoc) has a line the announcement here doesn’t have: “Assets trapped under a v3 hash become unclaimable.” I wanted to know how much that is on Polkadot, so I pulled every AssetsTrapped event for the relay and Asset Hub from Statescan and checked each hash against AssetTraps storage today.
On the relay, 299 trap entries from the v3 period are still unclaimed, with 673.7 DOT in them. On Asset Hub there are 177, with 263.2 DOT and a bit of USDT and USDC. On both chains the v3 period runs from June 2023 to April 2024, when the runtimes moved to v4.
Most of it belongs to ordinary accounts, not parachains. That’s 636.9 DOT across 224 accounts on the relay and 262.6 DOT across 116 accounts on Asset Hub.
How it got there
All but one of those account traps came from limitedTeleportAssets between the relay and Asset Hub. On the relay, most of the ones I opened show KilledAccount, then AssetsTrapped, then Attempted failing with FailedToTransactAsset. The account sent its whole balance, got reaped in the same transaction, and what the program had withdrawn went into the trap. On Asset Hub they fail with the same error, but the accounts weren’t reaped and most still hold DOT. A wallet team asked about these here in May 2024, and the answer then was claim_assets with the exact assets from the event.
Why the removal ends it
pallet-xcm stores a trap as a count under blake2_256(origin, VersionedAssets), so the version is part of the key. claim_assets reads the version from the assets you pass and makes it the ticket, GeneralIndex(3) for these, and ClaimAsset converts the assets to that version before hashing. Once v3 is removed, VersionedAssets has no V3 variant. The extrinsic can’t decode V3 assets and into_version(3) returns an error, so the count stays in storage and nothing can reach it.
Today it still works. I dry ran the claim with DryRunApi_dry_run_call against the live runtimes, for the largest account trap on each chain: 127 DOT on the relay, 52 DOT on Asset Hub. With the V3 assets exactly as in the event, both calls succeed and emit AssetsClaimed with the trap’s hash. One planck more and they fail with UnknownClaim.
XCM v5 already did this to v2. The same PR that added v5 removed v2, whose assets used index 1. The relay still holds 91 hashes from May 2022 to June 2023 under that index, 238 DOT across 1,384 traps, all trapped by parachains, and nobody has been able to claim them since v5 went live in May 2025.
Francisco’s post (XCMv3 to be removed in stable2612) puts stable2612 on 17 December and the first chains dropping v3 in early 2027.
What can still be done
On Asset Hub it’s one call from the same account: polkadotXcm.claimAssets, assets as V3 with the exact amount from the event, any beneficiary. 109 of the 116 accounts there still hold DOT for the fee.
The relay is harder. All 224 accounts hold nothing on the relay today, so someone first has to teleport DOT from Asset Hub back to that account, more than the 1 DOT existential deposit plus the fee, and then call xcmPallet.claimAssets the same way. Parachain traps (60 on the relay, 52 on Asset Hub) need a message from that parachain, so each one goes through that chain’s governance.
On the runtime side, I recomputed every remaining v3 hash on both chains, and every index-1 hash on the relay, from the origin and assets in its event, and all of them match. So a one-off migration could take a list built off chain, check that each old key is in AssetTraps, and move its count to the hash of the same assets as V5. It needs no v3 types in the runtime, and the same list would also bring back the 238 DOT from the v2 period. I haven’t written it, and someone who works on pallet-xcm will probably see problems with it that I don’t.
I only checked Polkadot’s relay and Asset Hub. Kusama and every parachain running pallet-xcm have their own AssetTraps.
If you run a wallet or a parachain whose users teleported in early 2024, do you have a way today to find their traps and build the claim for them?