Stratum V2's Coinbase Bug Fixes: Do You Need To Act?

On September 17, 2026, the team behind the Stratum V2 Reference Implementation (SRI), the codebase most Stratum V2 pools, proxies, and job declaration clients are built on, shipped version 1.12.0. Buried in the changelog next to a breaking refactor of the codec and framing layer is a line that matters more to solo miners than almost anything else in the release: fixes for coinbase construction bugs that could produce a consensus-invalid coinbase transaction.

That phrase is dry until you translate it. A consensus-invalid coinbase means a block your hardware actually found gets rejected by the rest of the network. For a pool running thousands of workers, one bad share barely registers. For a solo miner, the coinbase transaction is the entire point: it is the single transaction that pays the block reward directly to your own address. If it is malformed, the network throws the block out and the find that might happen once in years never counts.

Whether that risk is yours to patch depends on which piece of software you actually run. If you mine through NexusPool, the short answer is at the bottom, and the reasoning takes five minutes.

What Actually Changed in SRI 1.12.0

According to the project's own v1.12.0 release notes, the update fixes several coinbase construction defects that could yield a consensus-invalid coinbase, including undersized BIP141 witness commitment parts and scriptSig size and serialization errors. Alongside that, the channels_sv2 component received a deeper hardening pass: fixes for panics and state-machine gaps around chain-tip transitions, malformed upstream coinbases feeding into on_new_group_channel_job, an extranonce prefix that could be released while live jobs still referenced its bytes, and arithmetic hardened against overflow, underflow, and division by zero.

The release also carries a breaking refactor of the codec and framing layer, adaptations for BIP323 across the protocol stack, and the removal of AES-256-GCM from noise_sv2. Every published crate that changed takes an incompatible version bump, which is the project's way of telling downstream software: do not assume you can drop this in without checking your integration.

Why the Stratum V2 Coinbase Bug Hits Solo Miners Harder

Pool operators running Stratum V2 infrastructure at scale have engineering teams watching for exactly this kind of defect, and a single rejected share out of millions barely shows up in their numbers. A solo miner does not get that averaging effect. You might find one, two, or zero blocks in your entire mining lifetime, so a coinbase-construction bug that only shows up in an edge case is not a rounding error, it is the difference between a payout and nothing.

This is also precisely the failure mode NexusPool's Payout Preflight tool exists to catch on the pool side: it reconstructs and checks a coinbase transaction byte for byte before a block is even found, rather than discovering a construction problem after the fact. The SRI fix and Payout Preflight are different pieces of software solving the same underlying category of risk, which is that the transaction paying you needs to be right the first time, because there usually is not a second try.

None of this changes the math behind whether you find a block in the first place. A miner running a single Bitaxe at roughly 1.2 TH/s against a network hashrate of about 940 EH/s has a per-block probability of about 1.2 x 10^12 divided by 9.4 x 10^20, or roughly 1 in 783 million. At Bitcoin's pace of about 52,560 blocks a year, that works out to an expected wait of around 14,900 years. Stratum V2, SRI 1.12.0, and NexusPool's own tooling do not shorten those odds for anyone; they only affect whether the payout gets through cleanly on the day the odds do come through.

Run This Self-Check On Your Own Setup

• Do you connect to your pool over Stratum V2, or only Stratum V1?
• Do you run your own SRI-based software, such as a Job Declarator Client, translator proxy, or pool role, rather than firmware that only speaks Stratum V2 outward to a pool that runs its own infrastructure?
• If you do run SRI-based software, is it pinned to a version earlier than 1.12.0?
• Does anything in your stack depend specifically on AES-256-GCM inside noise_sv2, which this release removes?
• Have you rebuilt or reviewed your integration since any published SRI crate you depend on took its version bump?

The Branch

If you mine with hardware that only speaks Stratum V2 to connect outward, and your pool operates its own Stratum V2 endpoint (this is true of NexusPool's technology, which auto-detects Stratum V1 and V2 on the same port), the update to SRI's internals is not something you personally need to patch. The pool side absorbs it.

If you run your own Job Declarator Client, translator, or any other SRI-based component, the branch is different: pull the 1.12.0 crates, read the breaking-change notes for the codec and framing refactor before you rebuild, and confirm nothing in your configuration assumed AES-256-GCM was still present in noise_sv2.

This post does not claim that upgrading improves your odds of finding a block, that NexusPool's own software is open source or publicly auditable (it is not, only the license, README, and version file are public), or that any protocol change turns solo mining into anything other than a lottery set by difficulty and your own hashrate. What it claims is narrower: a specific, dated bug class just got fixed upstream, and it is worth five minutes to check which side of that fix you are standing on. For a broader picture of how a pool's signed work and custody records work, NexusPool's Glass Ledger documentation covers the receipt side of that same "verify, don't trust" principle.

If your checklist above cleared without a single box checked, there is nothing to do today. If even one box is checked, that is your actual next step, not a hypothetical one.

Trust nothing. Verify the transaction that would actually pay you.