Launch before your mainnet

A project can launch its asset on IceRoot while it builds its own chain, then move to that chain when it is ready. Launching on IceRoot does not tie the asset to IceRoot. On this path, a move out is the intended outcome.

This guide follows the draft protocol, which describes the intended mainnet. Check steps, fees, and interfaces against an actual release before relying on them.

How the path works

Phase	On IceRoot	On your chain
Launch	Create a native asset through Seedbed, distribute it, and keep the migration authority	Build and test
Prepare	Describe the planned destination in your metadata document	Implement the destination rules and test the route on the public testnet
Open	The migration authority adds your chain to the allow-list and opens migrate-out	Go live and verify IceRoot finality
Move	Holders submit MIGRATE_OUT, which destroys their units on IceRoot	Credit each exit once, by its out id
After	Holders who have not moved keep transferable units	Operate as your own network

Launch with the move in mind

Follow Launch a native asset, with these points in mind:

• Keep the migration authority. It sets the exit destinations and opens migrate-out. Consider a native multisig account for it. If the role is renounced, the asset’s exit destinations and lifecycle flags stay as they are permanently. If exits are closed when it is renounced, they can never open.
• Size the supply once. Every native asset has a fixed supply set at creation. Your chain’s own issuance rules are yours to design; IceRoot records how many units left for your chain and the record of each exit.
• Plan vesting across the move. Time-locked entries stay locked until their unlock times and cannot be moved early or revoked. Recipients claim on IceRoot and can then move while exits are open, so plan schedules and the exit window together.
• State your plan. You can name the chain you intend to move to in your metadata document. That is a statement, not a route: nothing changes on chain until the destination is on the asset’s allow-list.

Build a compatible destination

A compatible destination:

• verifies IceRoot finality from signed block headers;
• records IceRoot’s out id for every exit;
• rejects duplicates, so each exit is credited once.

IceRoot cannot compel a destination to act, and an exit has no refund. The correctness of your chain’s side is what protects holders who move. Test the complete route on the public testnet before opening exits on mainnet.

Wallets describe compatible destinations using the destination registry. It is an off-chain document that wallet releases bundle and that wallets update from iceroot.com over HTTPS. Users can change the feed URL or add others. The registry also records your chain’s class, post-quantum only if both its ownership signatures and its finality are post-quantum, classical otherwise, and, for a classical chain, its cut-off. Wallets warn before an exit to a classical destination past its cut-off; consensus does not refuse the exit. See Migrations and continuity.

Open the route

1. Name the destination exactly. The migration authority adds your chain to the asset’s allow-list of exit destinations. An exit to a destination that is not on the allow-list is rejected.
2. Announce it. On your own channels, publish the destination network, the asset holders will receive there, and when exits open. Holders should be able to check the destination against your announcement.
3. Open migrate-out. The migration authority opens the migrate-out flag. The flag cannot open until the asset has an allowed destination.
4. Holders move. Each holder submits MIGRATE_OUT with an account on your chain. The operation destroys the holder’s units on IceRoot, counts them as migrated out, never as burned, and writes a typed record naming the destination network, the destination account, and an out id.
5. Your chain credits. Once the exit’s block is final, your chain verifies it and credits the destination account once.

After the move

• Holders who stay. Holders who have not moved keep their units on IceRoot. The asset stays transferable, and no lifecycle flag or label freezes transfers.
• The exit window. The migration authority can close migrate-out again. Announce how long exits stay open; holders left on IceRoot after a close keep transferable units.
• Public records. Every exit and its destination account are public and permanent. The explorer shows migrated-out units separately from burned units.
• Coming back. If the asset later returns to IceRoot from your chain by migration, it registers as a new asset with its own AssetID and lifetime cap and never credits the original AssetID. A custody gateway is the exception, because its units never leave IceRoot’s supply.

Migration guide → · Migrate out →