Migrations · IceRoot Connector
Move an asset’s ownership record between networks. At least 36 of the 53 validators certify every migration list, and a lifetime cap bounds what migration can ever credit to an asset.
Registered with its trust label.
Identity, balances and transfer history.
Ownership recognized at its destination.
Journeys
Journey A · Existing asset
Existing network
Its rules or cryptography are being upgraded, rewritten, replaced, or retired.
IceRoot
The asset arrives through a supported route and stays transferable while the change happens.
Future network
When a route to it is supported and the project is ready, the ownership record moves on.
Journey B · New asset
Seedbed
The asset is created natively on IceRoot. No bridge is involved.
IceRoot
Holders send and receive it while the project builds its own network.
First dedicated network
It migrates out once a supported route to the project’s network exists.
The asset record links each stage of the journey. More use cases →
IceRoot Connector
Every validator runs an IceRoot Connector. It reads the source network through the validator’s own node or a declared provider, rebuilds each migration list and signs it. It runs outside Heartwood Core.
Source
Example network
Its own consensus and finality. IceRoot does not control them.
ConnectorSeparate process
IceRoot Network
The quorum decides
36 of 53 signatures certify a list. Each source event credits at most once.
Each source network has its own Connector adapter. Ethereum (ERC-20 tokens) is the only one at launch. There is no general-purpose bridge. Each network is also registered as classical or post-quantum. A classical one, such as Ethereum, has a cut-off, fixed at registration and only ever moved earlier; no burn from after it, and no snapshot list certified after it, is accepted. After the cut-off, new external asset registrations and late account bindings from that network are also refused. Lists certified before it can still be credited at any time, and an event list that lies wholly at or before the cut-off block can still be certified later. Post-quantum sources have no cut-off.
Each asset’s identity, decimals, mode, trust label, source finality rule and lifetime cap are fixed when it is registered.
An issuer’s migration authority sets exit destinations and can veto lists for its own asset if the issuer required its co-signature at registration. It can never create units or edit provenance.
Methods
Snapshot and burn events are the two modes of certified migration. A custody gateway is a separate, trusted arrangement and is always labelled as one.
A list records every holder of the asset at one source block. Holders bind their IceRoot accounts off-chain, typically by signing with their source-chain key.
The source chain’s record up to the snapshot block, and at least 36 of the 53 validators rebuilding and signing the list.
The trust label, the source finality rule and the lifetime cap, all fixed when the asset is registered, plus the source network’s class and, for a classical network, its cut-off.
A snapshot of a chain that is still live is labelled a distribution, not a succession.
Route detail
Compare the required route details using three example networks.
Recovery migrations
IceRoot provides the tools and verifies the result. It does not decide whether an incident happened, which party speaks for a project, which block is legitimate or which balances are deserved.
The source project declares the source block its recovery is built from, and announces it on its own channels.
It chooses strict ledger reconstruction, or a policy from a small fixed menu. The policy is explicit, versioned and hashed.
A deterministic snapshot turns the source chain, the recovery point and the policy into one canonical migration list.
At least 36 of the 53 validators rebuild the list from the same inputs and sign it. The policy hash is committed in the certified list.
Balances derived from the declared recovery policy are credited under the asset’s lifetime cap. The asset can later move to a rebuilt chain.
Strict reconstruction follows the source ledger exactly as it stands at the chosen block. A policy-adjusted list uses a small fixed menu: a declared recovery point, excluded addresses, and the treatment of escrow and contract holdings. Nothing outside the menu is available.
An IceRoot-certified migration list was reproduced from its declared inputs by at least 36 of the 53 validators, each with its own Connector and source-chain access. Certification means reproduced, not endorsed.
What cannot be reproduced is not certified.
Projects announce on their own channels which IceRoot Asset ID is their canonical asset, and that responsibility is theirs. The verified-asset list that wallets and the explorer show only reflects those announcements, and anyone may publish another list.
Each IceRoot asset maps to one source asset, so merging several assets into one is not supported.
Snapshot Builder
Planned tooling · not built yet
The Snapshot Builder is planned tooling; it does not exist yet. It will let a project build a migration list with the same deterministic code that the validators’ Connectors use to rebuild it: one implementation for both, running outside consensus.
An exact block and block hash, or the declared recovery point.
Every holding rebuilt from source-chain data.
Included supply checked against the source supply.
Canonical ordering and serialization, with a reproducible list hash.
Validators rebuild the list independently and sign it.
No floating point, timestamps, locale effects, central APIs, spreadsheet edits or undocumented exclusions.
Every migration or recovery will come with a report that states:
A command line will sit underneath any web interface, so a website never becomes the trusted source of a list.
$ iceroot-snapshot build --network ethereum --asset <asset> --block <height> --policy <policy>Example of the planned command line. Names and options may change.
Adapters are planned as projects need them: one for EVM networks, and others, for example, for Solana SPL tokens and Cosmos SDK chains.
Building a list is not certification. At launch, certified migration supports one source network, Ethereum (ERC-20 tokens). Other networks can be added later by the validator quorum, each through its own Connector adapter.
Each network is registered as classical or post-quantum. On a classical network such as Ethereum, a snapshot list must be certified before the network’s cut-off, which the quorum fixes at registration and can only move earlier.
Moving on
An exit destroys the holder’s units on IceRoot and records the destination, which must be on the asset’s allow-list. Projects choose when to move; there is no mandatory departure date.
The destination verifies IceRoot finality from signed block headers and rejects duplicate exits. An exit has no refund, so destinations are allowed with care. Wallets show whether a destination is classical or post-quantum and, for a classical one, its cut-off, and warn before an exit to a classical destination past its cut-off; consensus does not refuse the exit.