Bounty program
IceRoot rewards security and bug reports from the Security and bug bounty pool, and accepted code, documentation, and tests from the Developer ecosystem pool. Maintainers review work on GitHub. The program list records approved rewards, monthly statements, and account bindings.
ROOT and mainnet are not live. Rewards earned before mainnet are recorded for payment at genesis through the binding process below. The reward table is provisional; the final table will be set once ROOT has an on-chain value. Amounts are in ROOT, with no promised cash value.
Who may earn
Section titled “Who may earn”Anyone with a GitHub account may earn except the IceRoot team. Validators and related parties may earn under the same rules and rates. Related-party payments are marked and the relationship is stated in the public record. A validator’s contribution that was paid a bounty is to carry a bounty paid tag on the validator portal, with a link to its record.
Scope and reporting
Section titled “Scope and reporting”The program covers the public repositories in iceroot-network that provide IceRoot software: the node, SDKs, wallets, explorer, indexer, and Connector, and the websites and validator portal, which you test only on your own local copies. A repository is covered from the day it becomes public. Heartwood Core is public; check each other repository’s availability before reporting. Reports may concern the default branch or the latest release. Contributions are merged code, documentation, or tests in public repositories in the organization.
Report anything that may have a security effect privately first, under the security policy: a private first report is a condition for any security reward. Report a bug with no security effect in a public issue on the affected repository, with steps to reproduce. If you are unsure whether a bug has a security effect, report it privately. Every report needs a working reproduction.
The following do not qualify for security rewards:
- A flaw confined to the
solar-core-refreference implementation that does not affect Heartwood. - A third-party library flaw that cannot be exploited through IceRoot’s use of that library. Report library flaws upstream first.
- Attacks that require stolen keys, a compromised computer, or a malicious browser extension.
- Behavior within the whitepaper’s stated limits, such as exceeding its validator fault bounds or splitting balances to bypass account-based voting limits.
- Scanner output or best-practice suggestions without a demonstrated effect, and flaws in other operators’ forks.
- Social engineering, physical attacks, or volumetric denial of service.
Test on your own local network or private devnet. The one exception is the relaunched public testnet, once it runs: its validators are encouraged to attack it and try to break it. Outside that testnet, do not attack mainnet, public websites, or other people’s nodes, keys, or funds.
Provisional reward table
Section titled “Provisional reward table”| Report | ROOT | Typical impact |
|---|---|---|
| Critical | 50,000 | Theft, creation or permanent freezing of assets; signature bypass; conflicting finality within the stated fault bounds; remote code execution or key theft |
| High | 12,500 | Network-wide loss of production or finality within the fault bounds; temporary chain split; disagreement on block validity; signing something other than the approved action |
| Medium | 2,500 | Remote crash of one node or indexer, disproportionate resource exhaustion, or disclosure of private data other than keys |
| Low | 500 | Limited but demonstrated impact |
| Confirmed bug with no security effect | 250 | Reproducible incorrect behavior confirmed by a maintainer |
These rewards draw on the 30,000,000 ROOT Security and bug bounty pool. The provisional yearly cap for rewards from this pool is 750,000 ROOT.
| Contribution | ROOT | Work covered |
|---|---|---|
| Tier 1 | 2,500 | Major feature, subsystem, tool, test suite, or substantial refactor |
| Tier 2 | 1,000 | Bug fix with a test, measured performance improvement, or a new guide or reference page |
| Tier 3 | 250 | Small tested fix, added tests, or substantive documentation correction |
| Posted bounty | Up to 12,500 | A task whose reward is posted before work starts |
Contribution rewards draw on the 15,000,000 ROOT Developer ecosystem pool. The provisional yearly cap is 375,000 ROOT. Typos, link fixes, formatting, dependency bumps, and generated files receive credit only.
The fixed ROOT table is reviewed quarterly. The table in effect when a report or pull request arrives determines its reward. Reviews do not reduce rewards already earned.
The pre-mainnet period counts as the first year for the caps; subsequent years run from mainnet genesis. Rewards above a year’s remaining cap are queued for the following year without reducing the amount. Pre-mainnet rewards above that first cap move to the first monthly run after mainnet. These caps cover bounty rewards; audits, reviews, research, and grants have separate budgets within their pools.
Review rules
Section titled “Review rules”- The first complete, reproducible report qualifies. Duplicate findings and findings already recorded by the team do not earn another reward.
- One underlying cause earns one reward, even if it produces several symptoms. A security reporter who also supplies the fix receives the security reward without an additional contribution reward. Split pull requests are assessed together as one contribution.
- Maintainers assign severity or tier and explain the rating. A reporter may request a second review.
- Reports without a working reproduction receive no reward. Repeated low-quality submissions can lead to exclusion.
- Breaking the research rules or disclosing before the agreed publication date forfeits a report reward.
The tracking bot records labels, account links, duplicates, and status and prepares payment batches. It does not decide ratings or send funds.
Before mainnet
Section titled “Before mainnet”- Record earnings. Rewards are attached to the permanent numeric id of your GitHub account, so a username change does not change the recipient.
- Link a testnet account. When testnet accounts are available, publish a post from that GitHub account signed with the testnet account’s key. A new or changed link takes effect after 7 days.
- Bind a mainnet address. From the linked testnet account, send the participation pool’s binding transaction, whose memo is
iceroot:bind:v1 <mainnet address>. - Receive at genesis. Earned, bound rewards are explicit mainnet genesis allocations from the relevant pool and are liquid from block 1. Testnet balances themselves do not carry over.
Security rewards are listed only after their advisory is published. If the advisory is still unpublished at the genesis cut-off, payment follows publication in a monthly run after mainnet.
Binding instructions and deadlines are not published yet. What happens to bounty rewards still unbound at the binding deadline is not decided yet. Do not assume that the participation pool’s treatment of unbound shares also applies to bounties.
After mainnet
Section titled “After mainnet”The team pays approved rewards by hand once a month from the paying pool’s 2-of-3 multisig. Each payout is a transaction with its own program memo, and the monthly statement records the payments. Related-party rewards are marked.
An entry must be on the program list and its payment must match it. There is no waiting period after listing; the monthly schedule and security disclosure conditions still apply. The seven-day delay for a new or changed account link is a separate check.