---
title: Gen-1 Node Onboarding After 48 Months
slug: gen-1-onboarding-after-48-months
description: How Gen-1 node providers continue earning rewards beyond their initial 48-month window, including reward reconfiguration, optional HSM removal, and excess machine handover.
tags:
  - node-provider
  - onboarding
  - hardware
  - rewards
  - maintenance
date: 2026-05-04
related:
  - node-provider-documentation
  - node-provider-onboarding
  - node-provider-roadmap
  - reward-configuration
---

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](https://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](/wiki/node-provider-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](/wiki/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](/wiki/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](/wiki/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:

| Date offset | Event |
| --- | --- |
| Deadline minus 30 days | Forum posts for excess-machine handover |
| Deadline minus 9 days | Earliest safe submission of step-1 proposal |
| Deadline minus 4 days | Typical NNS pass time after submission |
| Deadline | 48-month window expires; reconfigured nodes resume earning |

## Related

- [Node Provider Documentation](/wiki/node-provider-documentation/)
- [Node Provider Onboarding](/wiki/node-provider-onboarding/)
- [Node Provider Roadmap](/wiki/node-provider-roadmap/)
- [Reward Configuration Guide](/wiki/reward-configuration/)