Kaspa P2P compatibility was simplified when rusty-kaspa PR #772 removed protocol versions 5 and 6 on December 2, 2025. After the merge, the node registers version 7 flows for peers advertising version 7 and current version 8 flows for peers at or above the current protocol version, rejecting older peers with a version mismatch.

Key takeaways

• The merged patch removes P2P flow version 5 and stops registering version 6.
• Code previously shared through a version alias is organized directly under a version 7 module.
• Peer initialization now accepts version 7 or the current version path; lower values receive a protocol-version mismatch.
• The same compatibility floor applies across network types, removing the earlier testnet-only branches for versions 5 and 6.
• Old-protocol cleanup reduces maintenance surface, but operators still need coordinated upgrades and should not infer price performance from a code deletion.

What changed in Kaspa’s P2P layer?

The primary source, rusty-kaspa PR #772, is unusually concise: “Removes P2P versions 5 and 6.” Its diff makes that statement concrete. The v5 module and its registration code are deleted, shared v6 files are moved under v7, and the flow context no longer imports or selects versions 5 and 6.

Peer initialization now follows two branches. A peer reporting at least the current PROTOCOL_VERSION uses the version 8 flow registration and applies the local current version. A peer reporting exactly 7 uses the version 7 registration. Any other reported version is rejected with VersionMismatch.

GitHub records 22 additions and 355 deletions across 24 files, with many of those files being directory moves rather than new logic. Six checks passed before the pull request was merged.

What is a P2P protocol version?

Rusty-kaspa peers exchange a version during connection setup. That value lets each node choose a compatible collection of message-handling flows for block relay, headers, initial block download, pruning-point data, transactions, peer addresses and related requests.

Removing a path therefore simplifies maintenance and narrows the set of peer behaviors the node must support. It does not erase old blocks or invalidate transactions. It changes whether a node running the merged software can establish a working session with software that only speaks a retired P2P version.

Why remove versions 5 and 6?

The PR itself does not publish a long policy explanation, so motives beyond the diff should be stated cautiously. The evidence shows that versions 5 and 6 were no longer intended as supported connection paths and that carrying them required duplicated or aliased flow modules.

The code also removes a previous distinction in which non-testnet networks connected only to newer versions while testnet could still select versions 5 and 6. After #772, version selection is uniform: version 7 remains as the compatibility path and version 8 is current.

This matters for test quality. A public test environment is more useful when its nodes exercise software close to the supported production architecture. Retired branches can hide upgrade problems if operators believe an obsolete peer is representative of a current deployment.

What happens to an outdated node?

A node that advertises only version 5 or 6 cannot negotiate the supported flow set with a node running this change. The newer peer returns a version mismatch rather than attempting to interpret the old messages through removed handlers. Whether the outdated node can find other old peers is a separate network-state question and should not be relied on for continued operation.

Operators should upgrade from an official, verified release and confirm the supported version information for that release. Do not edit a protocol constant or copy removed modules back into a binary as an improvised workaround; the protocol version represents coordinated behavior, not merely a gate.

How should operators plan the upgrade?

Inventory node versions before the maintenance window. Include public nodes, private RPC nodes, miners’ upstream nodes, monitoring replicas and testnet systems. A service may appear healthy locally while losing useful peers after the rest of the network advances.

Stage the new binary with its exact checksum or reproducible build record. Stop cleanly, preserve logs, and verify startup network, peer count, synchronization state and RPC health. Watch logs specifically for version mismatches and repeated connection churn. If peers disappear, compare their software versions before changing firewall or DNS settings.

Test failover as well as a single restart. A load balancer that rotates between current and retired nodes can create intermittent client behavior. The related Kaspa IBD and pruning movement article explains why a node returning after downtime may also encounter a newer pruning boundary; protocol negotiation and state synchronization are distinct stages.

Does P2P cleanup affect consensus or KAS price?

PR #772 reorganizes and deletes network-flow compatibility code. It does not document a change to Kaspa issuance, proof-of-work, block acceptance, transaction fees or block rate. Two compatible current nodes should continue using the selected supported flows; the visible difference concerns peers below the new floor.

A smaller compatibility surface can reduce maintenance burden and help developers focus testing, which is a positive software-engineering fundamental. It can also impose upgrade work on operators of old nodes. Neither fact supports a deterministic price prediction. Price reflects adoption, liquidity, market structure and external conditions in addition to software quality.

The Kaspa VCC v2 data aggregator guide covers a later observability change. Better RPC data can help diagnose network behavior, but it does not restore compatibility with a retired wire protocol.

What are the limitations of the evidence?

The pull request gives exact code evidence but no measurement of how many live peers were using versions 5 or 6 at merge time. It does not publish a disconnection count, upgrade adoption curve or performance benchmark. Claims that the cleanup immediately removed a specific number of nodes would therefore be unsupported.

Frequently asked questions

Can a version 5 node still validate its own database?

Local database behavior and peer compatibility are different. PR #772 shows that a new node will not register a v5 session with it; the patch does not by itself establish whether every old binary can still open its own data.

Does version 7 remain supported after this pull request?

Yes. The merged flow-selection code explicitly registers the version 7 path for peers reporting protocol version 7, while current peers use the version 8 path.

Was this a hardfork?

The source describes a P2P implementation compatibility cleanup, not a consensus hardfork. Operators still need to upgrade old networking software, but the PR does not change block-validity rules.

Source and verification note

This article is based on kaspanet’s merged rusty-kaspa PR #772, merged December 2, 2025. The public diff deletes v5 registration, removes v6 selection, moves shared flows under v7 and retains current v8 handling; it records 24 changed files, 22 additions and 355 deletions. Live peer counts and later version policy are not supplied by this source, so verify them through current official releases before operating a node.