Cardano Node 11.1.3 Fixes IPv4 Decoding

Cardano Node 11.1.3 was released on September 29, correcting how the software reads IPv4 addresses stored in the ledger. The update follows Intersect’s earlier priority upgrade notice for stake pool operators and other organizations running Cardano infrastructure.

How the IPv4 Fix Works

Version 11.1.2 inadvertently changed the byte order used to decode IPv4 addresses. The latest release restores the standard network byte order used before the 11.1.x series. The correction is included through version 1.9.0.1 of the cardano-ledger-binary library.

An IPv4 address consists of four bytes whose order determines how the address is interpreted. On Cardano, these addresses appear in stake pool relay records. Relays exchange blocks and transactions with other nodes, making accurate interpretation of their address data relevant to network infrastructure.

The release changelog places the correction in the ledger component and lists no changes to the Network or Consensus components.

Which Cardano Operators Are Affected

Intersect’s recommendation covers stake pool operators and other node operators. Its earlier upgrade guidance included infrastructure running on Mainnet, Preprod and Preview.

Cardano Node processes and validates transactions, including ADA transfers, and supports block production by stake pools. Operators maintain and upgrade that infrastructure. Users who delegate ADA to a pool rely on its operator to manage the pool’s nodes.

The IPv4 correction specifically addresses behavior introduced in 11.1.2. The broader recommendation to run at least that version follows an earlier issue identified on the Preprod testnet.

Intersect’s Upgrade Recommendation

Operators running versions older than 11.1.2 are advised to move directly to 11.1.3. Those already on 11.1.2 meet Intersect’s stated minimum, while 11.1.3 adds the IPv4 correction. The announcement specifies no deadline for moving between those two releases.

Intersect confirms that no ledger replay is required, meaning operators do not need to recalculate ledger state from historical blocks as part of the update.

For operators upgrading from older releases, the migration requirements introduced in the 11.1 series remain relevant. These include the removal of the LMDB storage backend and the legacy tracing system. Operators still using LMDB must switch storage backends, while those relying on legacy tracing must migrate their monitoring setup.