BTX 0.32.3.
The v2 MatMul path goes production-fast.

0.32.3 is not a consensus change. There is no new activation height; the rules at block 125,000 from the v2 MatMul activation stand unchanged. Validation behaviour is unchanged. Wallet behaviour is unchanged. What 0.32.3 ships is a production-grade GPU implementation of the v2 path, a matching Metal architecture, a handful of operator-side quality-of-life improvements, and packaging fixes that the static-release path was missing.

That said, it is described as a mandatory upgradefor anyone running an earlier 0.32.x build, and the reason matters. The 0.32.2 GPU path was correct under the new consensus rules — it would find valid blocks and validate other miners' blocks — but it was effectively unoptimised for v2. A miner running 0.32.2 against 0.32.3 peers is leaving an enormous amount of throughput on the table, and the rest of the network gets to that throughput first.

The release fits the rhythm of the previous two weeks. 0.31 activated C-002 shielded proof and FIPS-205 enforcement at block 123,000. 0.32 activated v2 MatMul at block 125,000. 0.32.3 lands two days later, no activation required, doing exactly the kind of tightening a production network needs in the days after a consensus change.

The reason 0.32.2's CUDA path was slow on v2 is not exotic. Under the v2 rules every nonce produces its own seed and its own matrices, so a naïve implementation generates one set on the host, ships it across the PCIe boundary, runs the multiplication on the GPU, ships the digest back, and asks the host to check it. Throughput is bounded by the slowest hop in that round trip — and for a fast modern GPU that hop is the round trip itself.

0.32.3 collapses the round trip. The pre-hash scan that selects candidate nonces runs on the GPU directly, against a batch of seeds derived in place. The matrix multiplications and digests for the entire batch happen on the GPU in one wave. Only the candidates whose digests already pass the consensus check are shipped back to the host, which is a small fraction of the batch. The host stops being a serialised bottleneck and starts being what it should always have been on a GPU mining loop: a coordinator that hands off work and counts blocks.

The performance the release notes attach to that change — roughly 14.1k to 2.45M nonces per second on the v2 path — is exactly the order-of-magnitude jump a v1-to-v2 rewrite of this shape produces when the original was correct but unbatched. It is the difference between “does it work” and “does it run.” 0.32.2 answered the first. 0.32.3 answers the second.

The new CUDA path is configurable through two environment variables. The first, BTX_MATMUL_NONCE_SEED_BATCH_SIZE, controls how many candidate nonces the GPU batches together before checking digests. Larger batches amortise launch overhead and memory transfers; very large batches eventually saturate the GPU's available memory or trip warp scheduling limits. The release ships with batch sizing tuned for production hosts; the env override is the dial for operators whose hardware does not match the production-host profile.

The second, BTX_MATMUL_CUDA_NONCE_SEED_MEMORY_PERCENT, caps the share of GPU memory the nonce-seed path is allowed to consume. The default keeps the path neighbourly on a GPU also being used for inference, training, or any other workload. An operator running a dedicated mining GPU can raise the cap and trade safety margin for additional batch capacity.

On Metal, SOLVE_BATCH_SIZE continues to be the primary knob and is now meaningfully more interesting than it was under the 0.32.2 implementation. The release notes suggest treating both backends as worth a brief retune pass after upgrading, with the chain-guard RPC introduced in 0.31 as the safe place to do that work — the node will tell you whether to continue, pause, or catch_up at every point.