Protocol design
The whitepaper is a working draft of the intended mainnet. This page maps its proposals to the current implementation.
The network records ownership through standardized accounts, assets, and transactions. The draft excludes a virtual machine and user-deployed executable code. Wallet interfaces, metadata hosting, prices, the explorer, and external-chain Connectors stay outside consensus.
Its four main proposals are:
- Post-quantum authentication: ML-DSA-65 for native protocol signatures from mainnet genesis.
- Deterministic finality: header-carried votes establish a finalized history.
- Native assets: canonical AssetIDs, a fixed supply for every native asset, and explicit supply accounting.
- Certified migration: independently checked manifests, permanent provenance, and lifetime issuance caps.
The draft proposes all these features from mainnet height 1, together with atomic swaps, hash time-locked transfers, non-revocable time-locked transfers for vesting, account names, and validator reward-sharing declarations. The development sequence used to build them is separate from that launch specification.
Current code and proposed mainnet
Section titled “Current code and proposed mainnet”| Area | Current implementation | Draft mainnet design |
|---|---|---|
| Core signatures | BIP340 compatibility baseline | ML-DSA-65 |
| Addresses | Base58Check with a network byte | Bech32m, ice1… on mainnet and tice1… on the public testnet |
| Portal identity | Version-90 devnet address | Separate from the eventual mainnet identity format |
| Transaction ID | Hash of serialized bytes including signatures | Domain-tagged hash excluding signature witnesses |
| Vote contents | At most 1,024 bytes | At most 1,280 bytes, naming 20 to 53 validators with at most 5% each |
| Node runtime | Crypto crate and differential harness | Separate relay, validator signing process, and indexer |
| Application data | Sample wallet and explorer ledger | Live node and indexer records |
Use the current source when integrating an application. One product detail also differs from the draft: the browser wallet has an explicitly approved website provider.
Rules and upgrades
Section titled “Rules and upgrades”ROOT voting selects validators. The draft routes protocol changes through published releases with named activation heights and preserves finalized history. Releases are announced in the announcements channel of the IceRoot Discord, and X, the status page on docs.iceroot.com, the IceRoot blog, and the IceRoot Telegram channel mirror each announcement.
It also separates fees from rewards:
- Fees: ROOT pays every transaction fee. Each fee, surcharges included, is 90% burned and 10% paid to the forging validator.
- Rewards: block rewards add issuance. Each reward pays 5% to the Development fund and 5% to the Ecosystem fund, and the remainder to the forging validator.
- Accounts: the team wallet and both funds are 2-of-3 native multisig accounts, labeled on the explorer.
ROOT’s supply grows only through block rewards; no operation creates further units of ROOT or of any other asset.
Decisions still open
Section titled “Decisions still open”The whitepaper leaves explicit TBD items:
- Genesis identifiers and allocations, and the funds’ addresses.
- The base fee rate and the fees of asset, migration, swap, and time-locked operations.
- Capacity limits and the implied-vote window.
- Penalty durations and parts of migration operation.
- Audit scopes, reviewers, and reports.
Its present-tense descriptions do not establish a deployment or completed audit. Keep unresolved values open until a release specifies them.