The Sixty-Six Dollar Signature
Hook
The dashboard renders a single number: $66. A footnote, typeset in the visual register of a compiler warning, clarifies that this figure excludes Bitcoin network fees.
Consider what that footnote concedes. StarkWare's Quantum-Safe Bitcoin project โ QSB โ has, across roughly one week spanning mid-to-late September 2025, driven the off-chain cost of preparing a single post-quantum Bitcoin transaction from approximately $320 down to approximately $66. A 79% reduction, announced with the cadence of a benchmark already reproduced by parties other than its author. It has not been reproduced. Every figure originates from one source: StarkWare itself.
Here is the arithmetic that frames everything below. One transaction required approximately 3,100 GPU hours. At a spot rate near $0.10 per GPU hour, that is roughly $310 before the optimization sprint and $66 after. The internal consistency is real. The problem is that the number deciding whether QSB is usable at all is precisely the number the footnote removes from view. The code does not lie, it only reveals. We should read the parts of the disclosure that were not bolded.
Context
Lay out the mechanics before dissecting them. Post-quantum cryptography for Bitcoin rests on a single asymmetry.
Bitcoin's current signature scheme โ ECDSA, and its Schnorr variant specified in BIP-340 โ depends on the hardness of the elliptic curve discrete logarithm problem. Shor's algorithm, given a sufficiently large fault-tolerant quantum computer, solves that problem in polynomial time. The consequence is not subtle. Every UTXO whose spend condition exposes a public key becomes, under that assumption, spendable by anyone who can run the algorithm.
Grover's algorithm is the weaker threat. It accelerates brute-force preimage search quadratically, which is manageable by extending output length. A 256-bit hash retains ample margin against any plausible Grover adversary.
Hash-based signature schemes โ Lamport, Winternitz, XMSS, SPHINCS+ โ sidestep Shor entirely because they construct signatures from hash preimages rather than algebraic group operations. This is the theoretical foundation QSB stands on. It is also old cryptography, not new cryptography. The math predates Bitcoin by decades.
QSB's architectural claim is narrower and more interesting than "post-quantum Bitcoin." The project does not touch the consensus layer. No soft fork. No new address type activated network-wide. Instead, it is a transaction-construction toolkit that produces, under existing script rules, a spend path secured by hash-based signatures rather than ECDSA. StarkWare researcher Avihu Levy published the approach; engineer Tomer Giladi handled the implementation; the first mainnet transaction was broadcast on August 26, 2025, submitted through MARA's Slipstream service. Eigen Labs and Yukon Research appear as collaborators in the optimization challenge that followed.
That challenge โ open to external developers, researchers, and, per the disclosure, AI agents โ ran from September 16. It produced 62 accepted improvements, and the announcement landed on September 23. Seven days from launch to press cadence. Keep that tempo in mind; it becomes a signal later.
Core
The metric that was measured versus the metric that matters
A Bitcoin transaction's cost to its sender has three components. The first is the off-chain compute required to construct the signature โ key generation, commitment construction, signature assembly. The second is the on-chain blockspace the resulting witness or scriptSig consumes, priced in satoshis per virtual byte. The third is any service premium attached to submission.
QSB's 79% reduction touches only the first component. The third is buried inside MARA's Slipstream arrangement and is not disclosed. The second โ the one that historically dominates โ is explicitly excluded.
This is the central analytical fact of the entire announcement: StarkWare optimized the variable that was not the bottleneck.
Why does blockspace dominate? Because hash-based signatures are enormous. A Lamport one-time signature over a 256-bit digest requires 256 preimage pairs; naively serialized, the public key alone occupies thousands of bytes. Winternitz reductions compress this by signing multiple bits per hash chain, but the Winternitz parameter trades signature size against computation, and the frontier does not collapse to numbers comparable with ECDSA. SPHINCS+ โ the NIST-standardized hash-based scheme โ produces signatures on the order of 7 to 50 kilobytes depending on parameter set. XMSS lands in the 2.5 kilobyte range, but carries statefulness constraints that make it awkward for wallets.
An ECDSA signature is 71 to 72 bytes. A Schnorr signature is 64 bytes. The ratio is not a factor of two. It is two orders of magnitude.
Run the arithmetic. At a modest fee environment of 5 sat/vB, a 10 kilobyte witness costs 50,000 satoshis of virtual resource. At $60,000 per bitcoin, that is $30. At 20 sat/vB โ a routine congestion level during the altcoin seasons I have spent years auditing โ it becomes $120. At the peaks of 2023 and 2024, when blocks cleared well above 100 sat/vB, the same payload approaches $600.
So the honest comparison is not "$66 versus $320." It is "$66 plus an unknown and highly variable network fee versus $320 plus an identical network fee." Because the network fee is a function of the witness footprint, and the witness footprint did not change during the optimization sprint โ unless the 62 improvements also shrank the payload, which StarkWare did not claim.
The 79% figure is real and the $"total cost" implication drawn from it is unsupported.
The GPU-hour ledger
Working backward from the disclosed numbers isolates the cost model. $320 divided by 3,100 GPU hours yields $0.103 per GPU hour. $66 divided by the same 3,100 hours yields $0.021 โ which is implausible as a spot rate. The alternative reading: the optimization reduced the GPU hours required, not the per-hour price. If the period cost fell to $66 at $0.103/hour, the new workload runs near 640 GPU hours.
Either way, the order of magnitude is instructive. A single transaction โ one signature โ consumed thousands of GPU hours. That is not a rounding error in a wallet's nightly batch. It is a distinct computational event.
The two computational tasks referenced in the disclosure map cleanly onto the structure of hash-based signature schemes. Task one: one-time key material and the Merkle commitments that bind a forest of one-time keys to a single public root. Task two: the per-message signature itself, the chain traversals and authentication path assembly. This split explains the GPU intensity. It also explains why the scheme is structurally hostile to light clients.
I have written before about the assembly-level realities of cryptographic construction. When I spent six weeks in 2017 tracing MakerDAO's early MCD contracts through Yul, the lesson was not that the high-level specification lied. The lesson was that the specification described the average case and the assembly described the tail. The tail is where systems fail.
QSB's tail is the second task's memory profile. Merkle authentication paths scale logarithmically, but the per-leaf one-time key material scales linearly with the number of signatures a leaf can produce before exhaustion. A stateless scheme avoids exhaustion by regenerating the tree โ which reintroduces the first task's cost. A stateful scheme avoids regeneration but must track which leaves are spent, and that tracking is a wallet-level obligation that no current Bitcoin wallet implements.
If you want a one-line summary of QSB's operational reality: it is a signing ceremony that requires a GPU, not a wallet.
The 62 improvements as an audit of the baseline
Here is the detail I find more revealing than the cost curve. Sixty-two improvements were adopted in seven days.
Consider what that says about the starting point. A mature, well-tuned implementation does not yield 62 discrete improvements to an open challenge in a week. A prototype does. The baseline StarkWare optimized against was almost certainly not production-quality code; it was a working proof-of-concept whose inefficiencies were unexamined because the project had not yet needed to examine them.
This is not a criticism of StarkWare specifically. It is a structural observation about how research code becomes benchmark code becomes marketing code. The compression from prototype to publishable figure happens before independent parties have seen the intermediate states. By the time outside researchers engage, the low-hanging optimizations have been harvested, and the remaining improvements require the kind of engineering that does not happen in a seven-day sprint.
The AI-agent angle compounds this. The disclosure notes that AI agents were among the contributors. That is a legitimate technical signal โ automated search over parameter choices and code paths is now competitive with human effort in narrow optimization domains. It is also a narrative signal, and I will return to it. For now, file it under: the challenge mechanics were as much about harvesting cheap wins as about uncovering deep insight.
The competitive map nobody drew
QSB does not exist in isolation. The post-quantum Bitcoin design space has at least three recognizable paths, and QSB occupies the least durable one.
The first path is consensus change. BIP-360 and its relatives propose native post-quantum address types that the protocol recognizes directly. This requires a soft fork, which requires rough consensus across a development community that has spent years arguing about far smaller changes. The advantage is that a native address type can be sized efficiently, fee-discounted if the community chooses, and integrated into every wallet. The disadvantage is that activation timelines for Bitcoin soft forks are measured in years and sometimes fail entirely.
The second path is script extension. OP_CAT and similar proposals would allow post-quantum verification logic to be written in Bitcoin Script rather than layered on top through witness construction. This is also a soft fork. It is also slow.
The third path is QSB's: do nothing to consensus, construct the transaction so that its spend condition is a hash-based script that today's nodes already validate. No fork. No activation debate. The cost is that the construction must live inside existing script and witness size limits โ which is exactly where the kilobyte-scale signature problem becomes brutal.
The bypass strategy trades governance friction for blockspace friction. StarkWare chose the friction that has a price tag and hid the price tag behind a footnote.
Auditing the space between the blocks reveals the asymmetry. A native BIP-360 address could, in principle, receive a witness discount analogous to the one SegWit gave to signature data โ because the data is verifiable and does not consume as much UTXO-set state as it appears. A bypass construction validated under legacy rules receives no such discount. Every byte costs full freight. The 79% compute saving is real; the structural fee disadvantage is permanent until consensus changes, and if consensus changes, QSB's entire reason to exist evaporates.
Where logical entropy meets financial velocity
Step back to the game theory.
QSB is a hedge against a low-probability, high-impact event. The event is the emergence of a cryptographically relevant quantum computer capable of running Shor's algorithm at Bitcoin's key size. Most credible estimates place that event five to fifteen years out, with wide error bars and a nontrivial possibility that it never arrives in the relevant form โ error-corrected, fast enough, and cheap enough to matter.
A hedge against a distant tail event has a peculiar economic signature. Its value is real but not exercisable. Its development cost is sunk today and recovered, if ever, only in a world where the tail materializes. And in that world, the hedge competes against the alternative that arrives by then: a native Bitcoin upgrade, which in a quantum-emergency scenario would activate with far more urgency than a routine soft fork.
Model it as two branches.
If the quantum threat stays distant: QSB has no user demand. Its utility is reputational โ it positions StarkWare as the entity that thought about the problem and did something. The $66 number enters marketing decks and does not enter wallets.
If the quantum threat becomes imminent: Bitcoin activates a native solution through emergency consensus, because the alternative is the collapse of the largest store of value on the network. That solution inherits full wallet support, fee discounts, and canonical status. QSB becomes a footnote in the history of the transition โ useful during the gap, if a gap exists, but not the destination.
The only scenario where QSB is the durable answer is the scenario where Bitcoin fails to coordinate. Betting on Bitcoin's coordination failure is a defensible technical position and an unusual business position.
Levy himself called the approach a contingency measure. That is the inventor's own framing, and it should be weighted accordingly. Contingency tools are validated, not marketed. The announcement cadence suggests the opposite priority.
The signature-size blind spot, quantified
Return to the numbers I set aside. Let me make the blockspace case concrete, because the disclosure's silence makes abstraction feel tolerable.
Take a Winternitz signature with a message digest of 256 bits, Winternitz parameter w=16. Each byte of digest requires one hash chain of 15 evaluations. Signing a 32-byte digest means 64 chains, each revealing a 32-byte preimage. The signature alone is roughly 2 kilobytes before authentication path. Add the Merkle authentication path for a tree of 2^20 leaves โ 20 hashes at 32 bytes each โ and the signature is 2.6 kilobytes. Add the public root and the script wrapper that consumes these values under existing opcode limits, and a conservative witness lands near 3 to 4 kilobytes.
That is the optimistic estimate. SPHINCS+ with robust parameters runs larger โ a design consequence of statelessness requiring a multi-layer hypertree. XMSS is smaller but stateful.
At 4 kilobytes of witness at 10 sat/vB, the network fee is 40,000 satoshis. At $60,000 per bitcoin, $24. At 30 sat/vB โ unremarkable โ $72. The compute cost is $66. The network fee is comparable to or larger than the compute cost that was the subject of a 79% reduction announcement.
StarkWare reduced a $320 component to $66 and left a $24-to-$400 component untouched and unmentioned. The headline addresses the smaller half of the bill.
There is a second-order effect. Blockspace is a shared resource. If QSB were ever adopted at scale, the aggregate demand for blockspace would rise, and fees would rise with it, and the scheme's own success would degrade its own economics. This is a classic congestion externality. It does not invalidate QSB; it constrains it to a niche of very high-value, very infrequent transfers โ which is precisely the institutional self-custody use case, and precisely the use case least served by a GPU-based signing ceremony.
MARA, Slipstream, and the submission layer
The first QSB transaction was submitted through MARA's Slipstream service. Slipstream is a direct-submission channel that routes transactions to MARA's pool without traversing the public mempool's broadcast race. Its function is latency and inclusion reliability, not fee reduction.
Why does a post-quantum proof-of-concept need priority inclusion? It does not, strictly. A test transaction can wait. The use of Slipstream is a capabilities demonstration in both directions: MARA shows it can handle unusual, large, computationally-expensive payloads; StarkWare shows its construction is compatible with professional submission infrastructure.
For MARA, a Nasdaq-listed miner, the disclosure value is asymmetrically positive. "We processed the first quantum-safe Bitcoin transaction" is a technical-differentiation datapoint that does not require a token, a fork, or a revenue claim. It fits neatly into a public-company narrative about infrastructure sophistication. The disclosure rules that govern a listed entity's technical claims are, however, a wrinkle worth monitoring โ "first" and "quantum-safe" are terms with legal texture.
The two computational tasks and the light-client problem
The disclosure's mention of two computational tasks deserves one more pass, because it determines who can use QSB at all.
If task one is tree and commitment generation and task two is message signing, then both are computationally heavy by construction. A hardware wallet โ the security gold standard for large BTC holdings โ has a secure element optimized for elliptic-curve operations, not for thousands of hash-chain evaluations and Merkle path construction. Running QSB signing on a Ledger or a Trezor would require either an externally computed signature that the hardware device merely displays (defeating the point of a secure element) or a hardware redesign.
This is not a fatal flaw. It is a scoping fact. A signing scheme that requires a GPU cannot live on the device that holds the keys. It lives on a server that holds the seeds โ and that relocates the trust assumption, not removes it.
For institutional custody, which already accepts HSMs and key-shard services, the relocation is tolerable. For the individual holder the quantum narrative most often invokes, it is a regression. The narrative promises to protect the little guy from a future quantum adversary; the architecture requires the little guy to trust a cloud to do it.
Parsing intent from immutable storage
Consider what is immutable here and what is not.
The Bitcoin consensus rules are immutable in the relevant window. QSB leaves them untouched. Good.
The QSB construction is not immutable. It is software โ a transaction builder. Every one of the 62 accepted improvements changed it. Version drift in a signing toolchain is a security surface of its own: a construction that produces valid-but-suboptimal witnesses is not dangerous, but a construction that produces malformed witnesses under adversarial inputs is. No third-party audit of the builder appears in the disclosure.
The absence is the finding. A project that spent real resources on an open optimization challenge has the budget and the motive to commission an independent security review of the resulting construction. It did not, at least not publicly. That is a gap in the record, not proof of a vulnerability โ but the asymmetry tells you where the project's priorities sat.
I have spent months inside proxy contracts that looked clean until a flash loan route was modeled. The lesson, repeated, is that clean-looking code and clean-under-composition code are different objects. QSB is a signing toolchain that will interact with wallets, custodians, hardware devices, and MARA's submission path. The composition space is large and unexplored.
Contrarian
The consensus reading of this announcement is that StarkWare made post-quantum Bitcoin 79% cheaper. The contrarian reading is that StarkWare made a hedge instrument slightly less expensive to strike, and the interesting question is not the price but the intent.
Look at the cast. StarkWare builds STARK provers โ its core business is proving computation. Eigen Labs builds restaking and verifiable-compute infrastructure. Yukon Research is a research shop. None of these are Bitcoin-native organizations. Their participation in a Bitcoin post-quantum problem is better explained by the search for a new narrative surface than by an intrinsic Bitcoin security mission. That is not a criticism. It is a map. The parties optimizing the compute cost of a signature scheme are the parties whose business is compute, and the announcement's shape reflects that gravitational pull.
The blind spot in every optimistic reading, mine included, is the assumption that the $66 number is comparable across time. Benchmark drift is real. When a challenge invites contributors to improve a metric, the metric can improve through genuine optimization or through redefinition of the measured task. A seven-day sprint that yields 62 improvements and a 79% headline is exactly the shape that both phenomena produce. Without the challenge's baseline specification and the accepted diffs, the number is an assertion.
The failure mode this predicts is vivid. A post-quantum migration happens under time pressure, if at all. Time pressure is when benchmark numbers get quoted without their footnotes. If QSB or something like it is deployed during a crisis, the crisis-time cost will not be $66 โ it will be $66 plus whatever blockspace costs when everyone is simultaneously trying to move their coins. The compute optimization will have prepared the wrong quantity.
Takeaway
The right question is not whether QSB works. It evidently produces valid transactions, and hash-based signatures are sound cryptography. The right question is whether the threat model justifies the tool. A contingency measure optimized for a cost component that is not the dominant one is not ready for its contingency. Track one number before you track any other: the total cost of a QSB transaction including the network fee, measured on mainnet, at a normal fee environment, by a third party. Until that number exists, the 79% is a press release wearing a benchmark's clothing.
