Bitcoin Core v31.0rc2 represents the clearest signal yet that the next major reference implementation release is weeks away, not months, and the window for community-driven quality control is narrowing fast. The second release candidate was tagged on March 25, 2026, per the official GitHub repository, following rc1's tagging approximately one week earlier. The rc2 designation carries specific technical meaning: at least one round of community-reported issues has been addressed, a backports pull request has been merged, and the outstanding milestone items that maintainer achow101 flagged in the March 12 IRC developer meeting have been cleared. The final stable tag targets early April 2026, per the official release schedule filed under GitHub Issue #33607. Bitcoin Core sits at the apex of the Bitcoin protocol stack, and the stakes of each major release are proportional to its dominance. The software powers approximately 95% of Bitcoin's full nodes, and at the time of rc2's tagging, the network registered a hashrate of 1,036.1 exahashes per second with fees flat at 1 satoshi per virtual byte across all confirmation targets — both figures sourced from Mempool.space live data. That fee environment, the lowest possible on the priority scale, reflects a low-congestion network: an ideal testing backdrop where rc2 nodes can be exercised against real traffic without the noise of a congested mempool. The project follows an approximately six-month major release cadence that has held since 2016, placing v31.0 as the successor to v30.2 and the evolutionary step beyond the v30.x series, which itself included the contested OP_RETURN policy change. The granular mechanics of how rc2 came to exist are documented in the Bitcoin Core IRC developer meeting log from March 12, 2026. Maintainer achow101 (Andrew Chow) stated: 'we branched on tuesday night, tagged v31.0rc1 yesterday,' and explicitly flagged that 'there is a backports pr and still a couple things in the milestone, so definitely will have a rc2.' That forecast proved accurate: rc2 landed on March 25. The rc2 tag carries a Tree-SHA512 of 'bb68f5b6e569781805c741d63a6ad6f955c1964d9186defa892936160e8444900f1e4175a1ef4fff268b655d664ddf0b914795ef554ea60cb23a054b080b4805,' confirming cryptographic provenance against the official repository. GitHub Issue #34840 serves as the live umbrella testing tracker, soliciting results across a wide variety of supported platforms and software interaction scenarios. As of this writing, no public quotes specific to rc2 have surfaced from core contributors; requests for comment directed to achow101 or fanquake (Michael Ford) via Bitcoin Core IRC/Matrix were outstanding at publication time. The convergence of factors that makes this release moment structurally significant extends beyond the normal release cadence. Three forces are operating simultaneously. First, the network hashrate at 1,036.1 EH/s reflects sustained miner investment in infrastructure, which means the node software these operators run is load-bearing in an increasingly capital-intensive environment — version lag carries real operational risk. Second, the collaborative release notes editing process, which contributor sipa (Pieter Wuille) highlighted in the same March 12 meeting — 'it is probably good for everyone to have a look over that and add things that users ought to see' — signals that v31.0 contains enough surface-area changes to warrant careful documentation, even if the specific feature set has not been fully enumerated in public-facing communications as of rc2. Third, the move to devwiki-based release notes editing, rather than in-repository drafting, reflects a maturation in the project's release process that accelerates community review cycles. The precedent most directly analogous is the v0.21.0 release cycle in early 2021, when the project similarly used a two-RC process to resolve descriptor wallet defaults before the stable tag. The competitive implications of a Bitcoin Core major release play out across three distinct layers of the ecosystem. At the node operator layer, self-hosted node runners — whether on RaspiBlitz, Umbrel, Start9, or bare-metal — face a decision window: test rc2 against their setup now, or accept the stable tag passively when it drops. Operators who test actively contribute to bug resolution and reduce their own upgrade risk. At the infrastructure layer, Lightning Network node operators running LND, Core Lightning, Eclair, or LDK depend on Bitcoin Core's RPC and P2P interfaces; any policy or RPC change in v31.0 that affects interface behaviour becomes a dependency risk for those implementations. The release notes draft on the Bitcoin Core devwiki is the primary signal to monitor for interface-breaking changes. At the privacy tooling layer, projects like Electrs and Fulcrum, which index chain data for self-custody wallet backends, must validate compatibility with v31.0's block and mempool interfaces before operators upgrade. No single commercial vendor dominates this compatibility testing space; the process is distributed across open-source maintainers, which makes the umbrella issue #34840 the single most important coordination point in the ecosystem right now. Our read: the advancement to rc2 is not a formality — it is the highest-confidence signal the Bitcoin Core project emits that a stable release is imminent, and the 72-hour window following rc2's tagging is the critical triage period. Our hypothesis is that, absent a critical consensus-layer bug report filed against issue #34840 before the end of March, the April stable tag will land on schedule, making v31.0 one of the more predictably timed major releases in recent cycles. The confirming signal is simple: zero P0 or P1 severity issues filed against the testing umbrella by April 1. The disconfirming signal is the appearance of any bug that touches consensus-critical code paths — script validation, block processing, or peer-to-peer message handling — which would force an rc3 and push the stable tag into mid-April at earliest. The devwiki release notes draft is the secondary signal: if contributors begin adding warnings or migration notices for RPC or wallet interface changes in the next 72 hours, that indicates more surface-area complexity than the current public record reveals. Decision-makers in the Bitcoin infrastructure space should track four specific, measurable indicators over the next three weeks. First, GitHub milestone #74: the count of open issues assigned to the v31.0 milestone is the leading indicator of whether the April stable tag is achievable — any milestone item reopened after rc2 is a timing risk. Second, testing issue #34840: monitor for new bug reports filed within 72 hours of March 25; volume and severity here will telegraph whether rc3 is necessary. Third, the Bitcoin Core devwiki release notes draft at 'https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Notes-Draft' — the emergence of interface deprecation notices or new RPC additions will define the compatibility work queue for Lightning and wallet implementations. Fourth, post-stable-release node adoption on Bitnodes.io: the speed at which the v31 share of reachable nodes crosses 10% will signal how actively the operator community engaged with the RC testing cycle — a fast adoption curve suggests broad pre-release testing, a slow one suggests operators are treating the stable tag as the first real validation point, which is the less desirable outcome for network-wide software health.