Why not just launch an ERC-20 or an SPL token?

Choose ERC-20 for Ethereum’s applications and tooling. Choose IceRoot for native assets with a defined migration path.

Asset ID, supply counters and migration provenance are part of the native record.

See the comparison →

Choose SPL for Solana’s ecosystem. IceRoot connects an asset’s native record to its source and future destination.

IceRoot is not a general-purpose application platform. Explicit operations and a small protocol surface keep the security problem more bounded.

Fixed operations make behavior consistent and easier to inspect. Each protocol change can be specified and tested independently.

Only within narrow limits. The protocol is feature-complete at mainnet, and there is no feature roadmap after it. Later releases carry security fixes, maintenance, parameter changes through milestones (the reward table, for example) and improvements that do not touch consensus: node tooling, the API and indexer, wallets, SDKs and Connector adapters for new source networks. A consensus change beyond that needs clear demand for something the design did not plan for, or a small, clearly useful improvement.

Mono Labs R&D LLC builds IceRoot for asset continuity and Monolythium for programmable applications. LYTH is planned to launch on IceRoot and later migrate to Monolythium under the same rules as any asset. ROOT is IceRoot’s separate token for fees and voting; holding LYTH, SXP or ARK does not confer a ROOT allocation. Heartwood follows ARK and Solar’s protocol lineage through a new Rust implementation and IceRoot-specific changes. It does not carry over their networks or balances. The engineering background and planned external audits are covered in About IceRoot.

About IceRoot in the docs →

No. Seedbed creates an asset through a native protocol operation.

Try the Seedbed walkthrough →

No. Standardised behaviour is intentional. Projects needing arbitrary programmable asset logic should use a general-purpose platform.

Yes. Holders send and receive assets through native transfers.

Yes. One transfer pays up to 256 recipients, and large distributions use several transfers. Vesting schedules use time-locked transfers that no one can revoke.

Yes. Native burn destroys units from the holder’s balance. Burned and migrated-out supply are recorded separately.

Website, description and logo live in a hosted metadata document. Only the asset authority can point the asset to a new one; the name, symbol and decimals never change.

No. No operation lets an issuer freeze, seize, tax or redirect holders’ balances, or create more units: every native asset’s supply is fixed at creation.

An asset’s authorities can only replace its metadata or manage its migration routes. Check the Asset ID before using an asset.

Privately, through GitHub private vulnerability reporting, which covers every iceroot-network repository; never in a public issue. The team acknowledges a report within 3 working days and publishes a GitHub advisory for each fixed report once the fix is live, at the latest 90 days after the report, or 120 days for a consensus fix that needs its one extension. Good-faith research that follows the published rules is authorized.

Reporting and research rules →

Yes. Anyone with a GitHub account except the team can earn ROOT for security reports, confirmed bugs and accepted code, documentation and tests in the iceroot-network repositories. Validators and related parties earn at the same rates, and related-party payouts are marked. The provisional table runs from 250 ROOT for a confirmed bug to 50,000 ROOT for a critical vulnerability. Rewards earned before mainnet are credited at genesis to the mainnet address you bind; after mainnet, the team pays approved rewards by hand once a month.

Bounty table and rules →

The networks have different security models. IceRoot keeps application execution outside its protocol.

Its core, consensus and migration dependencies are evaluated on their own merits.

Read the security scope →

No. Every signature verified in IceRoot consensus is ML-DSA-65, but a migrated asset’s history is only as strong as its source network and the route that carried it.

A classical source network such as Ethereum has a cut-off, fixed in advance and only ever moved earlier. IceRoot accepts no burn from after that point, and after it certifies no snapshot list and accepts no late account binding, because once a signature scheme can be forged, a new proof made with it no longer shows who owned what. Burns from before the cut-off can still be certified later, lists certified before it are still credited, and post-quantum sources have no cut-off.

PQ ownership has boundaries →

Yes. There is no mandatory departure date.

A supported route moves ownership to the destination and records the transition against the IceRoot Asset ID.

How migration works →

The project or its community. 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. IceRoot verifies migrations; it does not decide who speaks for a project.

Yes, through a recovery migration. The source project declares a recovery point and a recovery policy, and at least 36 of the 53 validators reproduce the resulting list before it is certified. IceRoot does not decide whether an incident happened, which holders are legitimate or which transactions are reversed.

How recovery migrations work →

No. Each IceRoot asset maps to one source asset, so a migration cannot combine two source assets into a new one. Each source asset can migrate on its own.

LYTH is planned to launch on IceRoot and later migrate to Monolythium, a separate network built by the same company. No live route exists. A destination must verify IceRoot finality from signed block headers, reject duplicate exits and be on the asset’s allow-list. See the Roadmap for development status.

Route requirements

Rooting is the concept of an asset moving toward the network it intends to call home. It is separate from ROOT, the network’s native asset.

Exchanges can integrate the asset interfaces. Each exchange decides what to list and which requirements apply.

Not in consensus. IceRoot settles a trade with a native atomic swap, all or nothing, and supports swaps with other chains through hash time-locked transfers. Order books and matching run off-chain, where anyone can build them.

Wallets warn before a swap with a classical chain past its cut-off. Consensus does not refuse it, because nothing on the IceRoot side relies on classical cryptography.

ROOT is the native asset. It pays every fee, 90% of which is burned, carries the vote weight in validator elections and pays validator rewards.

ROOT on the Network page →

The public testnet has not launched, and the Discord link is not published yet. The team handles participation case by case on Discord. To run a validator, apply there and prove that your node has synced completely; accepted operators receive testnet tokens for registration and a validator role. The team handpicks validators by availability, contribution and participation, with no points formula or minimum bar, and anyone who runs more than one validator loses their mainnet seat. How the 10M ROOT participation pool is split is not decided yet, and testnet balances never carry over.

What running a validator involves →

No. IceRoot does not sell ROOT, before or after launch: there is no public sale, presale, private round or VC round. The team and distribution pools never sell ROOT. ROOT is earned by contributing to the ecosystem, by taking part in the public testnet and the launch, and by running a validator. The 100,000,000 ROOT created at genesis are split into seven labeled pools: security and bug bounty 30M, team 20M, developer ecosystem 15M, testnet and launch participation 10M, ecosystem campaigns 10M, long-term reserve 10M and community and ambassadors 5M. 18M of the team’s 20M will be locked on chain in 16 quarterly tranches, and the explorer is planned to show each pool’s allocation and balance and to link every payout from the five program pools to its public program entry. The team account and the two block-reward funds will appear with their balances and transfers, without entries. There is no Monolythium allocation at genesis; related-party grants follow the same rules and disclose the relationship.

ROOT supply and distribution in the docs →