Security
Clear boundaries. Visible evidence.
Understand account authentication, native accounting and the external dependencies of each migration route.
Trust boundaries
Where IceRoot’s protection stops.
A migrated asset also relies on its source chain and the route that carried it, and units held by a custody gateway rely on its operator.
Inside IceRootProtocol scope
Account and asset security
- ML-DSA-65 for every signature in consensus, from block 1
- Validator signatures and consensus rules
- Supply of every asset checked after every block
Per routeDisclosed separately
What each migration route depends on
- Source-chain security and finality
- Certification by 36 of the 53 validators
- Custody gateway operators, where used
- For a recovery, the declared recovery point and policy
- The destination network
For an asset created in Seedbed, only the first box applies. For a migrated asset, both do, and its trust label is recorded when it is registered.
Security model
Six boundaries that matter.
- 01
Bounded execution
Native transaction types keep user-supplied code outside the protocol. Core accounting and consensus still require verification.
- 02
Memory safety and correctness
Rust provides memory-safety tools. Consensus, accounting and migration logic require their own tests and review.
- 03
Signing scope
Every signature verified in IceRoot consensus is ML-DSA-65. Source-chain dependencies, and any custody gateway, are evaluated separately.
- 04
Connector authority
Connectors run outside the node. One compromised Connector cannot authorize a credit alone: every credit needs 36 of the 53 validators. A compromised quorum can credit up to the asset’s lifetime cap, with no rate limit or delay.
- 05
Explicit state transitions
Key management, consensus and migration failure handling are defined as state transitions with explicit validation rules.
- 06
Scoped review
Review evidence applies to a named version and scope. Release and audit status is tracked on the Roadmap.
- Source chain
- Which network, which asset, and what counts as final there?
- Verification
- Who or what checks the source event, and what authorises issuance on IceRoot?
- Custody
- Is a custody gateway involved, and who operates it?
- Destination
- Are outbound transfers enabled, and how is duplicate issuance prevented if a step fails?
- Updates
- Who can change the route, and what can a change affect?
Reporting an issue
Security contact
Report vulnerabilities privately through GitHub private vulnerability reporting. The form covers every iceroot-network repository. Keep details out of public issues: a private report first is a condition for any bounty.
The team acknowledges a report within 3 working days, rates it within 14 days and sends an update at least every 14 days. Each fixed report gets a GitHub advisory once the fix is live, at the latest 90 days after the report. A consensus fix is published only after its activation height; if that takes longer, one extension of up to 30 days is allowed, with the reason stated publicly, so 120 days at most.
Include a working reproduction. Test on your own local network or private devnet. Once the relaunched public testnet runs, its participating validators may also test and attack that network under the security policy. Do not attack any other public network or service, access other people’s data, keys or funds, use social engineering, or publish details before the advisory. Stop once you have a reproduction and report it privately. Good-faith research within these rules is authorized, and the team will not take legal action over it. Credit is by GitHub name or anonymous, as you choose.
Earn ROOT for useful work.
Security reports and confirmed bugs are paid from the Security and bug bounty pool; accepted code, documentation and tests from the Developer ecosystem pool. Both cover the iceroot-network repositories. Anyone with a GitHub account can earn except the team. Validators and related parties earn at the same rates, and related-party payouts are marked.
Amounts are provisional. The final table is set once ROOT has a value on chain, and the table is reviewed every quarter.
| Severity | ROOT |
|---|---|
| Critical | 50,000 |
| High | 12,500 |
| Medium | 2,500 |
| Low | 500 |
| Confirmed bug with no security effect | 250 |
Yearly cap: 750,000 ROOT from the Security and bug bounty pool.
| Tier | ROOT |
|---|---|
| Tier 1 | 2,500 |
| Tier 2 | 1,000 |
| Tier 3 | 250 |
| Posted bounty | Up to 12,500 |
Yearly cap: 375,000 ROOT from the Developer ecosystem pool.
Maintainers rate each report and contribution on GitHub. A bot keeps the public record; it never rates or pays. Rewards earned before mainnet are credited at genesis to the mainnet address you bind, liquid from block 1. After mainnet, the team pays approved rewards by hand once a month from each pool’s 2-of-3 multisig. A security reward is listed only after its advisory is published.
Every payout carries a memo naming its entry on the public program list, which also holds the bounty record and the monthly statements.