Upcoming Changes to Node Account IDs: What Developers Need to Know

As part of the network evolution and the rollout of the Dynamic Address Book (DAB) on Hedera, upcoming releases of the consensus node software (v0.68 in December, 2025) will enable changes to node account IDs. HIP-1299 marks an important milestone in strengthening network flexibility and governance, while also introducing some considerations for developers and integrators.

What Are Node Account IDs?

Each consensus node on the Hedera network is associated with an account ID. These IDs are used for:

• Reward and fees routing: Rewards and transaction fees that apply to a node flow through its account ID.

• Transaction signing: The account ID must be included in the transaction body when submitting to a given node.

Because they are part of the signed transaction body, node account IDs are critical identifiers for the network’s function and integrity.

Node ID vs Node Account ID

It’s important to distinguish between a Node ID and a Node Account ID:

• Node ID: A unique identifier for each consensus node in the network. Node IDs are stable and do not change over time.

• Node Account ID: The account on the Hedera ledger that is associated with the node. This account can change over time and is the target for node rewards, penalties, and fees.

Example:

• Node ID: 1 (stable identifier, never reused for another node)

• Node Account ID: 0.0.3 (current assignment, can change in the future)

If, for example, the operator of Node 1 updates its account ID, the Node ID remains “1”, but the Node Account ID might change to something new, such as 0.0.1235.

⚠️ Applications must always rely on the latest account ID from the address book rather than assuming it is fixed. ⚠️

What’s Changing?

With the DAB feature (introduced in HIP-869) and HIP-1299, node properties such as account IDs can be updated on-chain. Beginning with the upcoming v0.68 release in December, node operators will be able to change their node’s account ID.

Key points to note:

• Node account IDs are unique, but not fixed: No two nodes can share the same account ID at the same time, but IDs can be reassigned over time.

• Account ID changes are immediate: These changes take effect at consensus, are not scheduled, and are not tied to upgrades. Rewards reflect the new ID by 00:00 UTC, and any record-file path lag until the next upgrade is cosmetic only.

• Operator flexibility: Node operators can change their node account IDs at their discretion, with changes coordinated through the address book.

Example:

• Before upgrade: Node ID 1 → Account ID 0.0.1234

• After upgrade: Node ID 1 → Account ID 0.0.32498

Why It Matters?

Transactions must be signed with the correct node account ID. If an application submits a transaction to a node using an outdated account ID, the transaction will fail with an INVALID_NODE_ACCOUNT error.

While newer versions of the Hiero SDKs automatically refresh the address book, older SDKs may contain hardcoded node account IDs. Applications using those older SDKs are at risk of disruption if the node account IDs they depend on change.

A recent survey shows that some developers still manually configure the Hedera client to connect to a single node. This manual approach is not recommended. While many applications will not experience issues, those that hardcode node account IDs or use very old SDKs could be impacted.

Impact Scenarios

• Applications using Hiero Java/JS/Rust/GO/Swift/C++ SDKs with dynamic node lists (forMainnet, forTestnet, forPreviewnet)

  • By default, these automatically refresh the address book (by default, every 24 hours)

  • Minimal or no impact.

• Applications using Client.forNetwork(oneOrMoreNodes)

  • Does not dynamically update nodes in its list

  • Support to update dynamically will be added in the future

• Applications using Hiero Java/JS/Rust/GO/Swift/C++ SDKs with static node lists

  • May fail to submit transactions to nodes whose account IDs have changed.

  • If configured to talk only to one node, the risk of disruption is higher.

• Applications using custom or community SDKs

  • Behavior will depend on how node information is managed by each community-managed SDK.

Hiero SDK Versions That Refresh the Address Book

Recommendations for Developers

• Do not treat node account IDs as permanent. They can change.

• Upgrade to SDK versions equal to or greater than the ones listed above to ensure automatic address book refresh.

• Avoid hardcoding node account IDs in your applications.

• If you manage custom node lists, refresh them regularly using the Hedera Mirror Node API.

• Test your applications ahead of the v0.68 release to ensure compatibility. These changes will be available for testing in previewnet and testnet starting in early Q4, 2025.

Looking Ahead

The changes introduced in HIP-1299 are part of ongoing work to improve the flexibility, resilience, and network governance of Hedera. While most applications are not expected to be impacted, clear notice can help the developer community prepare and update where needed.

All developers are encouraged to:

• Upgrade to the latest SDKs.

• Review your use of node account IDs.

• Reach out to community contributors via Discord if you have questions.

Call to Action

If your application uses older client applications that may be affected please upgrade before the scheduled v0.68 release in December to avoid transaction submission issues.