Three developments for public Monero node operators. Priority: upgrade monerod to v0.18.5.4, then review synchronization and pruning changes.
Published · Source status checked 2026-10-27. Platform guidance applies generally to public node operators.
1. Monero v0.18.5.4 fixes DNSSEC and RPC compatibility
Published: October 17, 2026 · Urgency: High — planned upgrade
Affected: monerod DNS checkpoints, blocklists and update checks; JSON-RPC clients
Sources: Official release notes
Released October 17, v0.18.5.4 repairs DNSSEC validation for checkpoints, blocklists and update checks. It also restores automatic conversion of numeric strings in JSON-RPC requests; that compatibility is scheduled for removal in v0.19. Operators should verify signed release hashes and test wallet and mining integrations when upgrading.
- FreeBSD nodes: Upgrade through the normal maintenance procedure. Verify the downloaded binary against the canonical GPG-signed hash list.
- Linux nodes: Canary one monerod instance before rolling out. Proxy-only hosts need no Monero binary change.
- Validation: Check DNSSEC warnings, checkpoint and blocklist resolution, independent chain-height agreement, restricted RPC, and P2Pool/ZMQ reconnection. Test clients that send numeric RPC parameters as strings.
- Rollback: Retain the previous binary and a consistent database snapshot. Release notes list no database-format change; verify rollback in testing rather than assuming compatibility. Downgrading restores the DNSSEC defect.
2. Peer-height validation advances; safe-sync work remains under review
Published: October 18–19, 2026; status updated October 27 · Urgency: Watch — especially outbound-only and Tor-connected nodes
Affected: monerod P2P synchronization and automatic database sync mode
Sources: Peer-height validation: merged · Safe database sync: proposed
PR #11581 merged on October 25, after this briefing period. It validates advertised heights against known blocks to prevent inconsistent claims from keeping the sync target above the local chain. PR #11585 remains open and addresses restoring safe database sync when public peers disconnect while Tor or I2P peers retain a higher target. A merge does not establish availability in a stable release.
- FreeBSD nodes: Continue independent height comparisons and investigate prolonged target-height divergence or stalled synchronization.
- Linux and Tor-connected nodes: Give outbound-only replicas extra scrutiny. Maintain diverse peers and check both public and hidden-network connectivity.
- Validation: Follow upstream tests for inconsistent advertised heights and public-peer disconnection. A merged patch is not proof that a released binary contains it.
- Deployment: Track tagged releases and backports. Do not deploy development branches solely on the basis of this brief.
3. Pruning commit-failure fix proposed
Published: October 21, 2026 · Urgency: Medium when creating a pruned database
Affected: monero-blockchain-prune and LMDB
Sources: Proposed pruning fix
If a final destination commit fails, the pruning tool can replace the active database with an incomplete destination, log success and exit zero. PR #11592 proposes checking these commits before the swap and correcting transaction-state handling after failures.
- FreeBSD nodes: Avoid converting the only production database without a recoverable copy. Use a consistent ZFS snapshot or separate backup and verify the resulting database before relying on it.
- Linux nodes: Retain a consistent copy of the original database. Check storage errors, resulting chain height and startup logs; a zero exit status alone is insufficient.
- Validation: The proposal checks final destination commits before replacing the active database. It remains open as of the verification date; do not treat it as a released fix.
- Rollback: Keep the original database until the pruned database has passed restart and synchronization checks. Restore the known-good copy if validation fails.