What IceRoot is
IceRoot is a network for creating and holding digital assets, migrating them between networks and recovering assets from a source chain. Its design uses post-quantum signatures and fixed protocol operations, with no user-deployed smart contracts. ROOT pays network fees and provides vote weight.
Mono Labs R&D LLC builds IceRoot and Monolythium. The team needed an asset network with post-quantum signatures and migration, found none available, and is building IceRoot for everyone to use under the same rules. LYTH is planned to launch as an asset on IceRoot and later move to Monolythium. The two networks are separate, and ROOT has no token link to LYTH, ARK or SXP. Heartwood Core is a new Rust implementation; its protocol design draws on ARK Core and Solar Core. About IceRoot has more.
What running a validator involves
The specification calls for 53 seated validators. The IceRoot team is to select mainnet's first 53 operators from public testnet participants who have shown commitment and reliable uptime, and each confirms a validator independence statement during selection. Publishing a portal profile does not register a validator, reserve a seat or establish eligibility for a distribution.
- Run a relay and a separate forger, keep the account key off servers and run each consensus key on exactly one forger. One key on two forgers can sign two blocks for one slot, which leads to jailing and withheld rewards; there is no stake slashing. Missed slots earn no block reward but carry no penalty. Monitor uptime and finality, and install releases before their activation heights.
- Run the Connector separately from the relay and forger to reproduce and attest migration lists. Certification requires 36 of the 53 validators. Source access uses an operator's own node or a declared provider; the limit of 17 validators per provider is an onboarding policy, not a consensus rule.
- Declare your operator, hosting provider and country, and your source-chain access; the explorer reports concentration from these declarations. Publish any reward-sharing terms, keep a standing proposal current and explain your contributions.
Read Operating a validator, the operator hardening guide and the proposal guide when preparing your setup. This portal accepts Heartwood devnet signing identities from the browser wallet; it does not support mainnet ML-DSA-65 sign-in.
Seats, votes and names
Voting uses liquid ROOT without locking it. A non-empty vote names 20 to 53 validators, distributes 100% of its weight in whole basis points and assigns at most 5% to any one validator. Validator accounts cannot vote; permanent resignation restores ordinary account voting.
At each round snapshot, a liquid balance strictly above 5% of the current ROOT supply has zero vote weight. A balance exactly at the threshold still counts. Locked ROOT has no vote weight. Splitting funds across accounts is possible, and these rules cannot prove that operators are independent.
The election result is checked every 24 rounds, about 2.8 hours. Each check changes at most one seat, and the change takes effect once the block carrying the result is final. A directory rank is not proof of a seat. On-chain names use 1 to 20 lowercase letters, with reserved names and banned words excluded; names containing iceroot or heartwood are restricted to the team's genesis registrations. A name belonging to an account that has been a validator cannot transfer. Portal display names do not register or reserve these names.
Rewards, sharing and fees
Each seated validator gets one slot per 53-slot round. Slots are 8 seconds. Produced blocks pay 1.8 to 2.2 ROOT by seated rank, with 5% going to the Development fund and 5% to the Ecosystem fund. Missed slots and validators outside the seated set earn no block reward. The rewards calculator holds supply and other inputs constant and excludes fees and payout costs.
Sharing is voluntary. Under the specification, SHARE_DECLARE records a share, a one-day or seven-day payout interval and a payout address. Each declaration has a 25 ROOT surcharge plus the size-based fee. It pays nobody: operators make payouts separately, and the indexer measures what each voter was owed and received. There is no planned upgrade to enforce sharing by consensus. Saving a portal policy does not send a declaration.
Fees are paid in ROOT: 90% is burned and 10% goes to the forging validator. Validator registration carries a 250 ROOT surcharge, and name registration and name claims 125 ROOT each, on top of the size-based fee. The base fee rate and the remaining surcharges are not set yet.
Blocks and finality
An 8-second block slot is not an 8-second finality guarantee. The specified finality rule requires at least 71 blocks (568 seconds); typical estimates are 71 to 108 blocks with all validators online and no missed slots, not an upper bound. Finality progress is proven with up to 17 crashed validators, not against coordinated Byzantine forking. Integrations must check finalized: true before crediting value.
Source networks and cut-offs
Ethereum ERC-20 assets are the planned launch source. Ethereum is classified as classical. A source qualifies as post-quantum only when both ownership signatures and finality are post-quantum. No additional source network is promised here.
Every classical source has a cut-off set before certification begins: an IceRoot height paired with a source block. A quorum can move it earlier, never later. After it, new external asset registrations, snapshot certifications and late bindings are refused, as are event lists extending beyond the source cut-off block. Event lists whose whole range lies at or before the cut-off block remain certifiable, and already certified lists remain creditable. Post-quantum sources have no cut-off. Ethereum's cut-off values are not yet specified.
Wallets warn before an exit to a classical destination past its cut-off, or a swap with such a chain; consensus does not refuse them. IceRoot's signatures do not make the other chain post-quantum.
Genesis distribution
The specified genesis supply is 100,000,000 ROOT across seven pools. IceRoot has no public sale, presale or private round; neither the team nor distribution pools sell ROOT. Contribution, participation and validator rewards are the distribution routes. Genesis supply is not a maximum supply: block rewards add ROOT.
| Pool | ROOT |
|---|---|
| Security and bug bounty | 30,000,000 |
| Team | 20,000,000 |
| Developer ecosystem | 15,000,000 |
| Testnet and launch participation | 10,000,000 |
| Ecosystem campaigns | 10,000,000 |
| Long-term reserve | 10,000,000 |
| Community and ambassadors | 5,000,000 |
| Total | 100,000,000 |
Of the team allocation, 2,000,000 ROOT stays liquid and 18,000,000 is to be locked in the first blocks after genesis, unlocking in 16 quarterly tranches over four years. Pool accounts use 2-of-3 multisig. Every payout names its entry on a public program list, and payouts to parties related to the team are marked as related-party, with the relationship stated.
Validators, testers and builders are to earn shares of the 10,000,000 ROOT participation pool on the public testnet, under rules to be published before earning begins. Each participant binds a mainnet address, and earned shares are allocated at genesis; unearned or unbound shares go to the Long-term reserve. Testnet balances do not carry over, and reference-devnet balances do not establish a reward entitlement. There is no Monolythium genesis allocation; a later community campaign would need a reproducible snapshot and published eligibility rules.
Open details and updates
Hardware sizing, the onboarding and participation rules, the validator independence statement, the base fee rate, Ethereum's cut-off values, jail and withheld-reward durations and the payout grace window are not settled yet. Do not treat sample profiles or calculator estimates as operating requirements or promised rewards.
The protocol is meant to be feature-complete at mainnet. After launch, releases carry security fixes, maintenance, parameter changes at announced activation heights and improvements outside consensus; there is no feature roadmap after mainnet.
Follow network status and the documentation for updates. The whitepaper describes the working specification in full. You can sign in to prepare a proposal and publish contributions now.