Polkadot stable2606-3: transaction pool now tracks every fork, with an opt-out
Parity published polkadot-stable2606-3 on 8 October, a patch release for the current stable2606 line, also tagged as node version v1.24.3. The release notes ask operators already on stable2606 to upgrade. One change is flagged as breaking under Rust SemVer — and it is the one node operators should read first.
The transaction pool now follows all forks. The fork-aware transaction pool is now maintained on every imported block, not only on blocks imported as the new best, so it builds a view for every fork. A new flag, --pool-best-blocks-only, restores the old behaviour. The flag affects only the fork-aware pool; the single-state pool is always maintained on best blocks only. The breaking crates are sc-transaction-pool-api, sc-transaction-pool and sc-cli, which matters to teams building their own nodes on the SDK.

Fixes for stuck and phantom transactions.
- In rare cases a transaction valid at the finalized block could get stuck: banned on one fork, the ban propagated to every new view and the transaction was silently rejected for the ban period (30 minutes by default). The pool now tracks why a transaction was banned and clears validation bans on the next revalidation if it is valid at the finalized block.
- A false
InBlockevent (and a cascadingFinalized) could fire when a replaced transaction's original version was included by another node.InBlocknow fires only for hashes actually in the imported block. - On re-orgs, transactions from retracted blocks are resubmitted in execution order; cross-account order is kept only when priorities are equal.
Light clients get finality faster. GRANDPA commits used to be gossiped to only four random light clients per round, so with many light clients connected, their finality lag grew linearly. Now light clients take turns in groups ordered by peer ID, each receiving a commit at least every five rounds; nodes with up to 50 light clients send every commit to all of them.
Also: a fix to session-key deposit benchmarks that broke collator-selection benchmarks on runtimes with a non-zero KeyDeposit; litep2p connection-state fixes; and new types for migrating parachain registrations and HRMP channels from the relay chain to the Coretime chain. Looking ahead, Parity says binaries from stable2612 on will be built on Debian bookworm, as bullseye builds are decommissioned.
Source: paritytech/polkadot-sdk release "Polkadot stable2606-3", 8 October 2026 — https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2606-3