An update on node rewards type1.1 and migration away from HSM-based node deployments

General
1

His is a cross-post from Matrix, in case some Node Providers did not see the message in the Matrix space.

An update on node rewards type1.1 and migration away from HSM-based node deployments

Hello everyone, particularly Gen1 node providers,

I originally planned to provide this update at the upcoming NP Working Group meeting. However, since many node providers have already raised questions and concerns, I thought it best to share the update here as well.

Rewards Feature Update

The development of the rewards feature will likely be delayed by a few months. The NNS team had other urgent priorities in recent weeks, so work on rewards was deferred. They now plan to perform additional refactoring to split the reward calculation into a separate canister on the NNS subnet before the new reward changes go live. This change will ensure that the NNS team will no longer be on the critical path for feature development and that the entire codebase will be managed by the DRE team. In the long term, this refactoring is expected to reduce inter-team dependencies, improve our development velocity, and enhance our flexibility for future enhancements. In the short term, however, this means that the project’s delivery will be postponed relative to the initial plan of going live in March.

On a positive note, we currently have 2–3 full-time members from the DRE team dedicated to this activity. We may expand the team further, and additional support from other teams is expected over the coming months. Rest assured, this project is actively progressing and our priorities remain unchanged.

From Your Standpoint

  • Node Rewards:
    The IC community recently adopted proposal 135054 which describes how node rewards will be adjusted based on the contributions of a node to the IC protocol. However, node rewards will remain unchanged in the near term - that is, in the next few months. They will continue to be paid based on the number of “rewardable_nodes” configured via an NNS proposal. The introduction of performance-based node rewards is postponed for a few months, and I will share an updated timeline as soon as more precise information is available.

  • Type1.1 Rewards:
    There is no change to the timeline for switching over from type1 to type1.1 rewards. All type1 rewards have been discontinued, so you must switch over to type1.1 rewards IMMEDIATELY to continue receiving rewards. Please follow the standard process outlined in the Node Provider Reward Configuration Guide.
    You need to include the node IDs for all relevant nodes as described in the guide. You can retrieve the list of node IDs from the public dashboard or by using the DRE tool. For example:

    dre registry --filter node_provider_principal_id=rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae

    This command provides a list of all healthy nodes owned by the specified node provider. Please replace the example node provider principal ID with your own. You may also filter by data center (e.g., dre registry --filter dc_id=an1) or by node_operator_principal_id. The output will include a list of healthy node IDs, for example:

    "Healthy": [
    "5w4eg-mb4ih-bwfmd-332ta-krtlf-y5igk-r3lzd-l3bze-34553-3opqh-mae",
    "656go-lv4fr-us6n5-uiyjx-ca6i2-pqidc-qowpr-z6npc-gihub-r6of4-tqe",
    "6inbw-5r6vc-63gh7-imy3n-ghurg-ritzv-re77i-qb2vu-wt77g-7drvt-lqe",
    "77fe5-a4oq4-o5pk6-glxt7-ejfpv-tdkrr-24mgs-yuvvz-2tqx6-mowdr-eae",
    "7ip7l-crn4t-bmbgn-yqmaa-3igqp-a444k-ozelm-dd7cp-p7rmm-3zwrx-wqe",
    "7rkml-6hpmp-t2e4r-v6rab-iqugz-surqq-vcqxh-h7fld-rnts2-osixh-yqe",
    "blo7w-oao2l-iurb2-4sauz-qeoli-b6np7-nemuq-vs6qx-y2h54-esxtu-tae",
    "[...]"
]

    In your proposal, ensure that you specify type1.1 as the reward type (e.g., using --rewardable-nodes '{"type1.1": 28}' as an argument, where 28 should be replaced with the actual number of healthy nodes). Please submit this proposal as soon as possible to continue receiving rewards. The proposal must be adopted before the 12th of March, 2025.

  • Node Health:
    Ensure that your nodes are healthy at the time of proposal voting, regardless of whether you use HSM-based or HSM-less deployments. Although transitioning to HSM-less deployment is encouraged—since it enables remote management, reduces operating expenses, and enhances system robustness—it is not an urgent requirement, and type1.1 rewards are not interdependent with the HSM-less deployments.
    Please refer to the Node Provider Maintenance Guide for detailed instructions on maintaining healthy nodes. The relevant health metrics are displayed at this dashboard and provided by the IC protocol. Additional information can be found here.

  • Upcoming Node Redeployment Enhancements:
    In the coming weeks, the DFINITY DRE team will introduce a new process that will allow you to redeploy your nodes in a way that supports remote node management operations. We will keep you informed as soon as this process is finalized. In the meantime, if your node is currently used in a subnet - please avoid redeploying the node with the new HSM-less node operator.

Thank you for your continued support and attention. I will provide further updates as more information becomes available, and I look forward to your participation at the NP Working Group meeting—where you will have the opportunity to ask any questions you might have about the above.

-s

2 Likes