Glass Ledger

The Bitcoin Transaction No Full Node Would Forward

A quantum-safe Bitcoin transaction went straight to a mining pool in August 2026, skipping the public mempool. Here is what that reveals about pool trust.

NexusPool blog thumbnail

On the morning of August 26, 2026, a researcher at StarkWare named Avihu Levy finished building a Bitcoin transaction that most of the network would refuse to even look at. The transaction combined two small inputs, 39,179 and 10,000 satoshis, into a single 44,000-satoshi output, paying a 5,179-satoshi fee. Nothing about those numbers is unusual. What made the transaction different was the method behind it: a hash-based signature scheme Levy calls Quantum Safe Bitcoin, or QSB, designed to hold up even against an attacker running a working quantum computer, all without asking Bitcoin's consensus rules to change at all.

There was one problem. A transaction built this way is nonstandard by the rules ordinary Bitcoin nodes use to decide what to relay across the peer-to-peer network. Broadcast it the normal way, into the public mempool, and it would likely sit there ignored, or get dropped, since most nodes simply will not forward something that does not match their relay policy. So Levy did not broadcast it. He sent it directly to a mining pool, MARA, using a service called MARA Slipstream that accepts transactions straight from a submitter and places them in a block without the transaction ever touching the public mempool. On August 26, the transaction confirmed in block 964,199. It worked. It also worked because a mining pool, not the peer-to-peer network, made the decision to include it.

What "the pool decided" actually means

This is the detail worth sitting with, more than the cryptography itself. Every block a miner finds is built from a template, a specific list of transactions in a specific order, and someone or something has to choose that list. Most of the time, that someone is the mining pool's own software, pulling from the standard mempool according to fee priority, the same policy every other node follows. QSB's mainnet debut is a reminder that a pool is not obligated to only pull from that public pool. If an operator wants to hand-place a specific transaction into a block, for research, for a customer, for any reason, the software allows it, and the base Bitcoin protocol does not stop a miner from including a transaction just because it looks unusual, as long as the block itself remains valid.

None of this touches the actual security of your bitcoin or the odds of finding a block. It is a statement about discretion: who decides what goes into the block you are helping to build, and how visible that decision is to you as a contributing miner. StarkWare has said publicly it still considers a soft fork the right long-term path for quantum resistance in Bitcoin generally; QSB is presented as a costly, deliberately narrow proof that an opt-in defense is possible today, not a finished answer for the network. The Block's reporting on the transaction lays out both the mechanics and StarkWare's own framing of it as an experiment, not a product.

Why a quantum-safe Bitcoin transaction matters if you'll never build one

Almost nobody reading this will ever build a quantum-safe transaction by hand. What is worth taking from the story is more mundane: the block template your hashrate is spent trying to find is assembled by software you are trusting, one way or another, to build it honestly and hand you what you actually earned if you find it. Stratum V2's job declaration feature exists specifically to let a miner build their own template instead of accepting the pool's without inspection, for exactly this kind of reason, though as prior coverage on this blog has noted, job declaration for solo mining specifically is newer and less battle-tested than the base V1 workflow most rigs still run. NexusPool's technology page describes how its own Stratum V1 and Stratum V2 implementation handles connections, including the same-port protocol auto-detection that lets older and newer firmware both connect without manual reconfiguration.

The part that does not change, regardless of what transactions end up in a block: what happens to the reward if your hashrate actually finds one. A non-custodial payout structure means the coinbase transaction pays your address directly, the same mechanism at work whether the rest of the block is built from an ordinary fee-sorted mempool or includes one hand-placed transaction from a research team on the other side of the world. How NexusPool's coinbase payout works is laid out on its about page, and it does not depend on trusting a pool's judgment about which transactions belong in the block, only on the arithmetic of the payout itself.

This is not a claim that any particular pool's transaction-selection practices are better or worse than another's, and nothing here changes the underlying odds of solo mining: those are set entirely by your hashrate divided by the network's current hashrate, identical for every miner on a chain no matter which pool relays their shares, and none of this is investment advice or a promise of any return.

Levy's transaction sits confirmed in block 964,199 now, permanent, unremarkable to look at, and built by a process that quietly demonstrated something most miners never think about: a pool's block template is a decision, made by someone, every single time. What actually changes for you, having read this, is not your odds or your setup. It is knowing to ask, the next time a pool talks about its own technology, not just what it pays but what discretion it holds over what goes into the block in the first place.

Trust nothing. Verify what actually goes into the block you're mining.