Gen-1 Node Onboarding After 48 Months

When a Gen-1 node provider's initial 48-month reward window ends, a specific sequence of governance steps is required to keep their remaining machines earning. This entry summarises that sequence and the associated handover paths for excess machines.

Providers operating fewer than 42 nodes only need to complete steps 1 and 1a below.

[!NOTE] Proposals usually pass within four days. Submit at least nine days before the 48-month deadline so there is room for corrections if a proposal needs to be re-submitted.

Step 1 — Update reward configuration for retained machines

For nodes the provider intends to continue operating past the 48-month mark, the reward configuration must be updated through:

1. A forum post on forum.dfinity.org↗ describing the planned reconfiguration.
2. An NNS proposal that updates the rewardable-nodes record for the relevant node-operator principal, using type1.1 for retained Gen-1 machines.

The forum post should include:

• a link to the provider's self-declaration,
• the count of machines being retained,
• the data centers they sit in,
• confirmation of IPv4 deployment where required,
• the intended reward start date,
• Element/Matrix contact details for follow-up.

Step 1a — File the NNS proposal

Use ic-admin to submit the reward-configuration update proposal, specifying NODE_PROVIDER_PRINCIPAL, NODE_OPERATOR_PRINCIPAL, and the rewardable-nodes JSON. The exact structure follows the template used during initial onboarding — see Node Provider Onboarding.

Step 1b — Optional: redeploy without HSM

This step is optional but recommended. It replaces the HSM-keyed deployment with a Gen-2-style key flow on the same physical hardware:

1. Generate new node-operator keys, following the non-HSM procedure in Node Provider Onboarding.
2. Redeploy the retained Gen-1 machines using the new keys.
3. File the corresponding NNS proposal to record the new operator principal against the data center.

Removing the HSM dependency simplifies subsequent maintenance and brings the deployment into line with current operational practice.

Step 2 — Hand over excess machines

For machines the provider does not intend to keep operating, a handover to a new provider can be arranged. This requires:

• a signed wiki statement from both the outgoing and incoming provider,
• a forum post documenting the transfer with the same details listed in step 1.

[!IMPORTANT] Submit the forum post 30 days before the step 1.A.5 deadline. The DRE team needs that lead time to process subnet membership changes for any excess nodes that are still active in subnets.

The receiving provider must continue to satisfy the network's decentralization rules — handovers that would concentrate ownership in a single jurisdiction are not approved.

Step 3 — Acquiring provider onboarding

The provider receiving excess Gen-1 machines goes through the standard onboarding flow:

1. Submit a node-provider proposal if not already accepted by the NNS.
2. Submit a data-center proposal if the receiving location is new.
3. Submit a node-operator proposal for each data center, with rewardable-nodes set to type1.1 for the inherited Gen-1 machines.

See Node Provider Onboarding for the underlying commands and key handling.

Sample timeline

The upstream guide includes a worked example with a 48-month window ending 31 January 2025. The pattern generalises:

Related

• Node Provider Documentation
• Node Provider Onboarding
• Node Provider Roadmap
• Reward Configuration Guide