The first quantum-safe Bitcoin spend used 201 opcodes against a limit of 201

At 20:48:34 UTC on Wednesday 26 August 2026, a Bitcoin transaction confirmed in block 964,199 that spent 10,000 satoshis without relying on elliptic-curve cryptography. StarkWare announced it as the first quantum-safe Bitcoin transaction. The claim holds, with a narrower scope than the phrase suggests.

We pulled the transaction from two independent explorers and disassembled the script it spends. What follows is what is actually on the chain.

One input of two

The transaction has two inputs. Only one of them is the interesting one.

Input 1 is the quantum-safe spend: a bare script sitting directly in the output, unlocked by a 1,168-byte scriptSig and carrying no witness data at all. Input 0 is an ordinary segwit spend, included to pay the fee.

The transaction’s single output is 44,000 satoshis to an ordinary P2WPKH address. So the coins finished the exercise in exactly the kind of output the exercise was demonstrating an alternative to, and that output was itself spent onward the next day in block 964,281.

The output being spent was not created for the announcement either. It was funded on 16 July 2026 in block 958,306, and sat on the chain for 41 days. Both blocks were mined by MARA Pool, whose coinbase in 964,199 carries the tag “MARA Made in USA”, which confirms the mining path without depending on anyone’s press release.

Exactly 201 opcodes

Bitcoin Script caps a script at 10,000 bytes and at 201 countable operations. The locking script is 9,923 bytes.

Disassembling it gives 880 items: 300 twenty-byte pushes and 300 nine-byte pushes, 15 OP_HASH160, 15 OP_EQUALVERIFY, 90 OP_ROLL, 4 OP_CHECKSIGVERIFY and two ten-key OP_CHECKMULTISIG operations. Data pushes do not count towards the 201. Counting the way the consensus rules count, which is 181 countable opcodes plus the 20 public keys the two CHECKMULTISIGs each add, the total is exactly 201.

Seventy-seven bytes of headroom and zero opcodes. That is the shape of the achievement, and it is not incidental. The construction was sized to the ceiling because the ceiling is what a bare legacy script has to live under.

The trick has nothing to do with STARKs

StarkWare is a zero-knowledge proof company and this is not a proof system. Its own post is explicit:

While StarkWare’s technology is based on ZK-STARKs, which are post-quantum secure, QSB does not use STARKs. It runs entirely inside Bitcoin, built from tools Bitcoin already has.

The mechanism is a one-time hash-based signature in the Lamport family, plus a puzzle. The script hashes a transaction-bound public key with OP_RIPEMD160 and then requires the resulting 20 bytes to themselves be a validly DER-encoded ECDSA signature. Avihu Mordechai Levy’s paper puts the probability of any given candidate satisfying that at roughly 2 to the power of minus 46, so the sender grinds off-chain over transaction parameters until one does.

The grinding is visible in the transaction. The quantum-safe input carries the sequence value 2,147,490,524 and the transaction carries an nLockTime of 887,230,081. Those two numbers are the output of the search.

What makes the construction interesting is what it does not assume. Finding a hash whose output is a valid signature encoding rests on no elliptic-curve hardness assumption at all. A quantum computer that can compute discrete logarithms does not get a shortcut through it.

It cannot use SegWit, and that is the point

The scheme is a modification of Binohash, a construction by Robin Linus of ZeroSync and Stanford. Levy’s paper states directly that neither Binohash nor this construction can use Taproot or SegWit, and gives three reasons: it relies on ECDSA rather than Schnorr, on the FindAndDelete mechanism that SegWit removed, and on the legacy SIGHASH_SINGLE behaviour that SegWit’s sighash algorithm does not reproduce.

That forces the script into the open. It is too large for P2SH, whose redeem script cannot exceed 520 bytes, so it has to sit as a bare script in the scriptPubKey where everyone can see it and where it counts against the 10,000-byte limit in full.

A quantum-safe spend in 2026 therefore has to be built out of the parts of Bitcoin that a decade of upgrades was designed to retire.

StarkWare’s own caveats are the strongest ones

The company published the limits itself, and they are not small. On what the scheme protects:

It would not help an address whose public key was published before the transaction was sent, because an adversary would have time to derive the private key before the transaction was broadcast.

That excludes reused addresses and every coin whose public key is already on the chain, which the Google Quantum AI whitepaper of 30 March 2026 puts at roughly 6.9 million bitcoin. The same paper is what makes the demonstration legible: it estimates that an attacker with a working machine, given around nine minutes per key derivation, would succeed against a normal transaction sitting in the mempool slightly less than 41% of the time. That mempool window is the specific thing this construction closes.

On distribution, StarkWare notes that QSB transactions “use nonstandard formats, so they will not travel through the ordinary mempool and currently need a direct path to a miner”. That is why MARA Slipstream was involved. MARA itself has published nothing: its investor-relations page carries no August 2026 release on this, and its Slipstream site renders as an empty JavaScript shell.

Levy’s paper is blunter than the announcement. It says the scheme “should be treated as a last-resort measure”, citing cost, user experience and the fact that it does not cover Lightning channels.

And the repository’s own README still lists on-chain broadcast as not yet attempted, four days after the broadcast.

The soft fork this is supposed to make unnecessary

The obvious reading is that Bitcoin no longer needs a consensus change to survive quantum computers. StarkWare does not make that argument. Its chief executive, Eli Ben-Sasson, says the opposite:

Avihu took this on after hours, as a passion project, and has now shown that Bitcoin has no expiration date. I still want Bitcoin to choose to do a soft fork and I expect we will get one. What today’s successful transaction offers Bitcoin is a reassurance that holdings can be protected before that happens.

There is a reason for that position beyond modesty. One of the three co-authors of BIP-360, Isabel Foxen Duke, leads Bitcoin Growth at StarkWare, which the company itself said in February. The firm that shipped the no-soft-fork demonstration also employs an author of the soft fork.

The state of that fork explains the hedging. BIP-360 is still Draft, is now titled Pay-to-Merkle-Root after two renames since September 2025, and contains no deployment or activation section. The post-quantum signature algorithms were removed from it into a separate BIP in July 2025, and that BIP still has no number: BIP-361’s header requires a “TBD Post Quantum Signature BIP”. BIP-361 itself, the migration timeline, phases in at 160,000 blocks after its own activation and then two years after that, which is roughly five years from a start date nobody has scheduled.

What is circulating that we could not stand up

Two quotes are being repeated widely and we could not find either on any StarkWare page: a second Ben-Sasson line about dev culture and critics, and a line attributed to Levy about adding “a second lock”. StarkWare’s blog carries a different Ben-Sasson quote and no Levy quote at all. We have not used them.

The mechanism is also being described wrongly. Several accounts say the sender brute-forces signatures until one has a shape that avoids exposing public key material. That is not what happens. The public key is still in the transaction and still visible; the search is over transaction parameters, looking for one whose recovered public key hashes to something that parses as a signature. Nothing is hidden from anybody.

Levy’s own title has drifted in the retelling. StarkWare calls him “researcher and General Manager of Applications at StarkWare”; the version now in circulation promotes him to chief product officer, and no StarkWare page says that. We have used the company’s own wording.

The honest summary

A 10,000-satoshi output was moved on Bitcoin mainnet using a signature scheme a quantum computer cannot shortcut, inside a script that fits the consensus limits with 77 bytes and no opcodes spare, through a private path to one mining pool, after 41 days sitting on chain, ending in an ordinary vulnerable address that was spent again the following morning.

StarkWare’s own post says the network is unchanged. That is the accurate version, and it is still a real result: the thing works on the live chain, the code is public under MIT, and anyone can now check the claim rather than argue about it.