Migrations and continuity
The draft whitepaper describes assets arriving through certified source records and leaving through recorded exits. Assets stay transferable while hosted on IceRoot.
Two starting points
Section titled “Two starting points”Seedbed is the native asset creation and distribution experience. It describes an asset and its initial allocation without deploying a token contract. A Seedbed asset has a fixed supply, and vesting schedules use time-locked transfers.
An external migration starts from an existing network. Its records must connect the source asset and source event to an IceRoot asset and receiving account.
Proposed inbound flow
Section titled “Proposed inbound flow”- Register the source network and asset, with a fixed lifetime issuance cap and an explicit trust model.
- Publish a manifest that maps source holdings to receiving IceRoot accounts.
- At least 36 of the 53 validators independently rebuild and attest to the manifest using their own Connectors. Each validator reads the source chain through its own node or a publicly declared provider, and no provider serves more than 17 validators.
- Submit the certified lines in order, in chunks of up to 256. Recipients are fixed before certification.
At mainnet launch, the draft supports one source network: Ethereum (ERC-20 tokens). Each further network needs its own Connector adapter and registration by the validator quorum.
The draft supports snapshots and source-chain burn events. A certified manifest is creditable immediately:
- Before its first credit: the quorum can cancel it.
- After its first credit: a mistake requires correction using existing units.
There is no optimistic credit or pending state inside the proposed consensus model.
What a route must explain
Section titled “What a route must explain”| Question | Why it matters |
|---|---|
| Which source event is accepted? | Identifies the evidence for a transfer |
| What establishes source finality? | Determines when the source record is usable |
| Who verifies or authorizes it? | Makes the trust model explicit |
| What prevents reuse? | Prevents the same source event crediting twice |
| What happens on failure? | Defines retries, cancellation, or recovery |
| Which destination accepts it? | Connects outgoing records to their intended network |
Each route must name its trust assumptions. A custody gateway holds existing units on behalf of users; its operator has a different role from a validator-certified migration.
Hash time-locked transfers support swaps with other chains, but they complement migration rather than replace it. A swap moves units that already exist on each chain; it never creates units of a migrated asset or counts as a migration credit.
Exits and their limits
Section titled “Exits and their limits”In the draft, MIGRATE_OUT destroys units on IceRoot and records an allowed destination, destination account, and unique exit ID. The destination must verify and honor that record. IceRoot cannot force it to credit the user, and the proposed exit has no refund.
The record has three important limits:
- Burned and migrated out remain separate counters.
- Source-to-destination account links are public and permanent.
- The lifetime cap bounds a compromised certification quorum; there is no additional issuance delay or rate limit.
The explorer’s current sample migration states illustrate the interface. They do not define the proposed consensus state machine.