What IceRoot is for
IceRoot is a minimal, non-programmable network for keeping digital assets under post-quantum keys throughout their lifecycle. Post-quantum signatures are the security foundation. Continuity of ownership is the purpose: an asset can launch on IceRoot, stay, arrive from another network, recover onto IceRoot after an incident, and later move on, all without smart contracts.
This page follows the draft protocol, a working specification whose parameters, economics, and validator rules may change. The production Rust node is still being built, a reference devnet runs now, and the public testnet has not launched. About IceRoot explains who builds IceRoot and why; Network status covers updates.
Launch
Section titled “Launch”- A new native asset. A project creates its asset through Seedbed, IceRoot’s asset creation and distribution platform. The whole supply is created once, at creation, and never grows. If IceRoot meets the project’s needs, the asset simply stays. See Launch a native asset.
- A launch before a mainnet. A project launches its asset on IceRoot while it builds its own chain. When that chain is ready, the project names the destination, opens exits, and holders move. A project can launch on IceRoot without being tied to IceRoot, and a move out is an intended outcome of this path. See Launch before your mainnet.
Preserve
Section titled “Preserve”- Planned chain retirement or consolidation. A project that no longer needs its own blockchain moves its asset to IceRoot. This is a planned decision, not a failure.
- End-of-life chains. The lifetime of an asset does not have to equal the lifetime of the blockchain on which it was created. Holders of an asset on a chain that is winding down can keep their ownership record on IceRoot.
- Long-term holding. An asset whose activity has slowed can stay recorded on IceRoot for as long as its holders keep it there. A balance needs no activity to remain in place.
- Leaving a smart contract. A project can replace an ERC-20 or proxy token with a standardized IceRoot asset to reduce its attack surface. This is a routine change, not an emergency measure.
- Recovery after an incident. A project whose network suffered an incident declares a recovery point and a recovery policy. Validators reproduce and certify the resulting list, and the holdings arrive on IceRoot, from where they can later move to a rebuilt chain.
- Post-quantum planning. Projects meant to last for decades may prefer to move their assets to post-quantum keys as planned work, on their own schedule.
Migrating in needs a supported source network. At mainnet launch that is Ethereum (ERC-20 tokens); each further network needs its own Connector adapter and registration by the validator quorum. Registration also records a network’s class, classical or post-quantum, and a classical network’s cut-off, after which consensus refuses new asset registrations from it, lists that reach past it, and late bindings; see Migrations and continuity. The migration guide covers the migration paths above.
- Migrating out. Holders move an asset to an allowed destination chain through a recorded exit, whether the asset was created on IceRoot or migrated in.
- A temporary home while rebuilding. An asset leaves a chain that is being rebuilt, stays on IceRoot in the meantime, and moves on to the rebuilt chain when it is ready.
- Planned project migrations. An asset can move from Chain A to IceRoot, or from Chain A to IceRoot and on to Chain B. Migration is not reserved for chains that have failed.
What IceRoot is not
Section titled “What IceRoot is not”- No EVM or other virtual machine, and no application runtime.
- No user-deployed contracts and no executable token code.
- No on-chain DeFi: no lending, liquidity pools, or automated market makers. Two assets trade through one all-or-nothing atomic swap operation, and order books and matching run off-chain.
- No freeze, seizure, clawback, or transfer-tax logic, and no programmable compliance rules. No operation lets an issuer freeze, seize, tax, or redirect holders’ balances.
- Not a stablecoin or real-world-asset platform. Assets whose issuers need freezes, clawbacks, or compliance scripting do not fit the model.
- No minting after creation. Every native asset has a fixed supply set at creation.
The absence of these features is part of the security model. IceRoot is a deliberately plain ledger for ownership and migration, and asset behavior is defined once, in the protocol, and is the same for every asset.
What standardized assets change
Section titled “What standardized assets change”Many projects need issuance, ownership, transfer, burn, and migration, and nothing more. On IceRoot, these are standardized protocol operations that work the same way for every asset. A holder, wallet, or exchange learns what an asset can do by reading its ledger record, not its code.
IceRoot removes arbitrary executable token logic as a class of asset-level complexity. Hidden logic, malicious contracts, upgradeable proxies, administrator backdoors, and bugs in contract code or its dependencies have no per-asset code to live in.
Standardized assets do not make every project trustworthy. A project can still mislead its holders, markets can still be manipulated, and a team can still abandon its work. Check the AssetID that a project announces, and treat a familiar name or ticker as a label, not as proof.
Who decides
Section titled “Who decides”IceRoot provides the tools and verifies. Projects decide.
- Canonical assets. Projects and communities announce on their own channels which AssetID is their canonical asset, and that responsibility is theirs. The verified-asset list reflects such announcements.
- Certification. Validators certify a migration list when they reproduce it from its declared inputs. A certification means the list was reproduced, not that the migration is endorsed.
- Neutrality. IceRoot and its validators do not judge which party legitimately represents a source project, which block is legitimate, or which balances are deserved.
- No company required. A project team or a community can prepare a migration list, and validators reproduce it from the source chain’s own data in either case. If an asset’s issuer opted in to co-signing, the asset’s migration authority must also sign each of its lists.
What is not supported
Section titled “What is not supported”Restructuring and mergers are not supported. Combining two source assets, such as ABC and XYZ, into one new asset has no migration route. Each IceRoot asset maps to one source asset, because a migrated asset’s AssetID is derived from its source network and its source asset.
An asset that leaves IceRoot and later comes back from another chain by migration registers as a new asset with its own AssetID. A custody gateway is the exception, because its units never leave IceRoot’s supply.
Post-quantum keys
Section titled “Post-quantum keys”Every signature the protocol verifies, from block 1, is ML-DSA-65 (FIPS 204). An asset held on IceRoot is therefore controlled by post-quantum keys from the moment it arrives. An asset’s history before it arrived keeps the strength of its source chain and of the route that carried it; migration does not change that history. See Cryptography.
Choose a guide
Section titled “Choose a guide”| I want to… | Read |
|---|---|
| Create a new asset on IceRoot | Launch a native asset |
| Launch on IceRoot first and move to my own chain later | Launch before your mainnet |
| Bring an existing asset to IceRoot | Migration guide |
| Recover holdings after an incident | Recover after an incident |
| Move an asset from IceRoot to another chain | Migrate out |
| Build a reproducible migration list | Snapshot Builder (planned) |