Block 125,000.
BTX closes the MatMul precompute loophole.

BTX does not mine with SHA-256. It mines with a 512×512 matrix multiplication over the Mersenne-prime field 2³¹−1. The loop a miner runs to find a valid block is short and identical on every backend, whether the implementation is CPU, Apple-Silicon Metal, or CUDA. Every attempt is the same seven steps.

1. Build a candidate block header.
2. Pick a nonce — a guess.
3. Derive a seed from header + nonce.
4. Use the seed to construct two matrices A and B.
5. Multiply A × B.
6. Hash the product.
7. Check whether the result is below the current difficulty target. If not, increment the nonce and start over from step 2.

The whole question of mining efficiency comes down to step 3. The seed is what determines which matrices you multiply. If you change the nonce but the seed barely moves, you are multiplying the same matrices again with a slightly different label on the output. That is the part the v1 → v2 change is about.

Under v1, the seed used to construct the matrices was largely determined by the header alone. That sounds innocuous, and at first glance the loop still reads the same. The hidden problem is in step 4: if the seed does not change much when the nonce changes, the matrices the seed produces do not change much either. A miner trying thousands of nonces against the same header was, in practice, multiplying nearly the same matrices over and over.

The natural optimisation is then obvious. Precompute the matrices once, hold them in cache, and re-use them across every nonce that fits the same header. The expensive step — the actual 512×512 matrix multiplication — gets amortised across many attempts. A clever miner can effectively try far more nonces per second than the algorithm was designed for, because most of those attempts are not actually doing the work the network thinks they are.

This is efficient in a narrow sense. It is also corrosive to the chain's headline pitch. The argument for MatMul proof-of-work is that the cycles securing the network are the same cycles AI workloads pay for — that mining is a real bid on the GPU-hour market, not a token-shaped abstraction sitting on top of it. If most nonce attempts are precomputed reuse, then the network's reported hashrate overstates the matmul cycles actually being burned. That is the gap v2 was designed to close.

A naïve implementation of v2 is to do one nonce at a time: generate the seed, build the matrices, multiply, hash, check, increment. That works correctly and produces exactly the right answer — and it would also throw away most of the throughput that modern CPUs, Apple-Silicon GPUs, and CUDA devices were designed to deliver. v2 wants to be batched.

That is what the v0.32.1 work shipped. The CPU solver now processes a batch of candidate nonces in parallel — each with its own seed, its own pair of matrices, its own multiplication — so a multi-core CPU stays usefully busy instead of crawling. The same parallelism lands on the Metal path (the Apple-Silicon GPU on a Mac mini or M-series studio) and on CUDA. v0.32.2 carries those changes forward and adds v2 awareness to both validation and mining, which is why operators already running v0.32.2 do not need to take any action before the activation height.

For Apple-Silicon operators specifically, the SOLVE_BATCH_SIZE tuning becomes more interesting. The default that worked best under v1 was tuned to a loop where matmul cost amortised across nonces; under v2, where every nonce pays the full matmul cost, batching is the whole game. It is the right knob to revisit after activation to see whether a larger batch is faster on a given Mac mini or M-series box.

The reason any of this matters outside the mining bench is that BTX's entire pitch is that its proof-of-work primitive is the same operation transformer models run. If the network's advertised work can be substantially shortcut, the headline pitch is weaker than it should be. Every honest measurement that downstream consumers — investors, regulators, agents, exchanges — eventually take off the chain depends on the difficulty being a real reflection of cycles spent. v2 restores that.

It also continues a pattern. 0.31 activated at block 123,000. 0.32 (v2 seeds) activates at block 125,000. Two consensus changes in roughly four days of block time, each landing cleanly on upgrade slack the launch wire was designed to reserve. A network that can ship and land two consequential consensus changes in a week without breaking ordinary users is a network that has the right kind of plumbing to absorb the larger changes that come later — multi-user settlement, the bridge layer, wBTX, all of the work the upgrade-slack design was always for.

The headline metric is not how often the network can fork. It is how invisibly it can. Ordinary wallet users do nothing for this activation either. The chain just gets quietly more honest about the work it does.

The MatMul loop on BTX is seven steps long. The v2 activation at block 125,000 changes one of them — the seed derivation in step 3 — so every nonce gets its own seed, its own matrices, and its own full multiplication. The precompute shortcut goes away. The network's difficulty becomes a more honest measure of real matmul cycles. The CPU, Metal, and CUDA solvers stay competitive because the v0.32.1 work taught them to batch nonces in parallel.

For wallet users this activation, like the last one, is invisible. For operators it is a version check, a hashrate-optics adjustment, and an optional re-tune of a batch-size knob. For the network it is one more piece of evidence that BTX's upgrade cadence works as advertised — slack reserved at launch, activations landing on it without breaking anyone who was not trying to break themselves.