No More Fixed Node Rewards. Now it’s Useful Work that Pays.

The rules are changing. Since genesis, node rewards on the Internet Computer have been predictable. Fixed amounts were paid out regardless of how well a node actually performed, or even if all nodes belonging to a Node Provider (NP) were in the registry at all.

Despite those shortcomings, that model helped bootstrap the network. It gave NPs confidence to invest early and focus on building the infrastructure, rather than optimizing performance.

But the Internet Computer is maturing, and developments this year mark a shift from a pure focus on stability toward reliability and accountability. Performance-Based Rewards (PBRs) are one such development, and it marks a major shift in how node rewards are calculated, bringing fairness and transparency into the equation.

The motion proposal for this change was adopted and executed on February 3, 2025, with the expectation that it would go live in March/April 2025. But, as with many complex systems, there have been adjustments, refinements, and community consultations. With the foundation performing some final simulations, it looks to be in its final phases with the rollout just around the corner.

In that light, I thought it would be useful to revisit the topic and break down how the rewards algorithm works, what makes it different from what is currently in production, and what it means for you as an NP.

The New Reward Logic

PBRs build on a foundational breakthrough by DFINITY: Trustworthy Node Metrics. As far as I understand it, this enables every node in a subnet to receive data from its peers, tracking how many blocks each node successfully produces and how many it fails to produce. Because the state of each node is replicated across all nodes in the subnet, these metrics are cross-verified, meaning all nodes in a subnet agree on how many successful and failed blocks proposed each node in said subnet had.

That consensus is what makes the data trustworthy. From there, the system computes a failure rate.

Now, a high failure rate may not be unique to just one node in that subnet. So, to account for subnet-wide issues, the algorithm subtracts a “subnet failure rate” from the (raw) failure rate. Subnet failure rate is the 75th percentile of failure rates reported by nodes in each subnet each day. This ensures the nodes are not unfairly penalized for broader network issues.

This results in your relative failure rate. Your rewards are then reduced linearly based on that rate:

Below 10%: No reduction. Full rewards.
Between 10%–60%: Reward reduction scales linearly, up to an 80% reduction.
Above 60%: Reduction is capped at 80%.

This reduction is then applied to the daily base reward (in XDR) of that node, which is the maximum it can earn for that day.

In short, every day the following calculation is done when the Trustworthy Node Metrics are available:

Total blocks = blocks proposed + blocks failed
Failure rate = blocks failed / total blocks
Relative failure rate = failure rate - subnet failure rate

Reward reduction = 1.6 x (relative failure rate - 0.1)

Rewards earned = base reward ( 1 - reward reduction)

A few other important notes:

NPs with fewer than four nodes receive full rewards automatically.
Only nodes in a subnet undergo the full algorithm described above.
Reward adjustments from nodes in subnets are extrapolated to unassigned nodes.
Rewards are calculated daily, but disbursed every 30 days.
Only nodes present in the registry on a given day are eligible for that day’s reward calculation.

What Changes for Node Providers

Here’s what will feel different to you:

Rewards will no longer be static, they’ll vary slightly month to month depending on uptime, assignment, and registry presence.
You’ll be able to see eligibility and performance per day. Small inconsistencies may gradually affect cumulative rewards, so monitoring matters.
For NPs in the onboarding process, the need for the reward configuration proposal, which updates the rewardable_nodes field, may no longer be necessary. Once a node is online and present in the registry, it will automatically begin earning rewards. This can significantly reduce the risk of errors during reward configuration.

At the time of writing, PBRs aren't live just yet. However, that makes the time between now and its rollout the most opportune time to get familiar with the new algorithm. It's also a good time to ensure you have the right tools in place to monitor your node performance. Simply monitoring the public ICP dashboard or having Prometheus set up for your hardware doesn't always surface degraded performance at the protocol level. For that, you will need to monitor the Node Rewards Canister.

“What? Another endpoint to monitor?” If that’s your first thought, the good news is you don’t need to build tooling from scratch — unless you want to, of course.

How to Monitor Performance-Based Rewards

Earlier this year, a developer dashboard was released by DFINITY to show the new metrics in action. However, it's no longer supported as it was only meant for demo purposes. At Aviate Labs, we thought such a dashboard should always be available for NPs and the community. So we built one.

As part of a grant, and in collaboration with DFINITY, we built this into Node Monitor. The public dashboard is free to use whether you have an account or not. In that dashboard you can track every NP's block statistics and see how those translate directly into rewards received.

If you have a Node Monitor Pro account (which is free until the end of the year), you can also set up daily email alerts. These alerts deliver a daily performance report of your nodes, showing exactly how much of the maximum possible rewards you earned that day. Additionally, any nodes that were or came close to being penalized are highlighted as well.

Want to investigate further? The node detail and subnet pages let you see whether a node’s behavior was persistent, and whether other nodes on the same subnet showed similar signs of trouble.

If you need to take action, Node Monitor’s proposal editor helps you remove a node from a subnet and replace it with another one quickly, allowing you to minimize reward losses while you troubleshoot. Today this happens through governance, meaning that the swap will only execute after 3—4 days (if adopted). But, DFINITY is actively working on features to make node swaps happen faster, and those enhancements will be supported in Node Monitor as well.

With these features, Node Monitor gives you the essentials to navigate PBRs. And there's still more to come, so stay tuned!

A Stronger, Fairer Network

This shift isn’t just about payouts: it’s a sign of a maturing network ready to ask more of its infrastructure.

When node rewards are tied to measurable performance, reliability improves across the board and trust grows between NPs, developers, and users.

PBRs bring transparency, fairness, and data-driven accountability to the Internet Computer. We built Node Monitor to make those qualities observable and actionable, helping NPs thrive in the new era of PBRs and giving the community a direct window into the infrastructure of ICP.