Coinbase, Which Says It Holds About 12% of All Bitcoin, Sets Out What It Needs From Bitcoin’s Post-Quantum Signatures. Its Request for Multi-Party Signing Is the Hardest to Meet.

October 13, 2026 – Coinbase, which says it holds about 12% of all bitcoin in existence as a custodian, published what it needs from the Bitcoin post-quantum signature schemes and output types that developers are designing. The company asked that Bitcoin’s post-quantum options include at least one scheme that looks promising for multi-party computation (MPC) signing, and that any stateful scheme come with a stateless signing mode.

Shashank Agrawal, who leads protocol security for Coinbase’s on-chain development, wrote the post, titled “Working Together on Bitcoin’s Post-Quantum Readiness.” He based it on Coinbase’s own work and on the needs the company hears from institutional customers.

He called it input to an open discussion, “not a set of instructions or a final Coinbase position.” He named candidate schemes and output types without choosing among them.

Bottom line: of the custody requirements Coinbase has put on record before Bitcoin’s developers choose a post-quantum scheme, multi-party signing is the hardest to meet with the research published so far.

Coinbase set out seven points:

1. Preparation before certainty. Work should start well ahead of any announcement of a cryptographically relevant quantum computer (CRQC), because Bitcoin consensus changes and migrations can take years.
2. An output type separate from the signature scheme. Developers should be able to add, replace or supplement post-quantum signature schemes without redesigning the output type. Coinbase named P2MR, defined in Bitcoin Improvement Proposal 360 (BIP-360), and P2TRv2 as designs that appear to allow this.
3. Staged protection. Active wallets should be able to use post-quantum or hybrid outputs before Bitcoin settles its policy on legacy signatures, for example through a 1-of-2 construction in which the same coins can be spent either with a classical ECDSA or Schnorr key or with a post-quantum key.
4. A stateless option. If Bitcoin supports stateful signatures, it should also offer a stateless option. If a signer mismanages state, an attacker could forge signatures.
5. Implementation quality. Evaluators should give strong weight to deterministic verification across platforms, constant-time code, clear parameter sets and resistance to failures of the random-number generator used for signing.
6. MPC compatibility. Coinbase called MPC-friendliness an important consideration for itself and for many of its customers.
7. A path for late movers. If Bitcoin restricts or ends ECDSA and Schnorr spending, the community should consider whether and how users who had not migrated could move their funds afterward, in a separate discussion alongside the signature work.

For each candidate scheme, Coinbase proposed criteria that include signature, key and total spend sizes, verification and signing time, throughput for mass migration, and feasibility on hardware security modules (HSMs), secure elements, hardware wallets and MPC or threshold signing. It asked for an evaluation specific to Bitcoin covering ML-DSA (CRYSTALS-Dilithium), SLH-DSA (SPHINCS+), FN-DSA (Falcon) once it is standardized, and compact or assumption-diverse candidates. The company said the final recommendation should include a primary choice, a fallback, the reasons for excluding alternatives and a sensitivity analysis.

Coinbase named SHRINCS, a hash-based scheme drafted by a working group of Bitcoin developers, as a good fit for that evaluation. SHRINCS combines a compact stateful signing path with a stateless fallback. Coinbase called the combination an attractive trade-off between size and verification, but wrote that anyone adopting SHRINCS would face central questions about signer state, recovery and implementation assurance.

Large exchanges such as Coinbase run several signing servers in different zones that operate independently for low latency and high availability, the company wrote. With a stateful scheme, each server would need an exclusive lock on a key and its state while signing. Coinbase said its servers could then no longer operate independently, and recovery from backups would become difficult.

The company asked that the risks of mismanaged state be made clear up front and that wallet providers get guidance on managing state. It also asked for a stateless-only signing mode.

On MPC, Coinbase wrote that some schemes, including certain lattice-based ones, may be more amenable to MPC than others. It called MPC compatibility a consideration for choosing schemes, not a request for the Bitcoin community to develop a particular MPC protocol. With MPC, several parties produce a signature without any one of them holding the whole private key.

Coinbase described P2MR as a Taproot-like commitment with the key-path spend removed. It linked to a public discussion of output types on the Delving Bitcoin forum, which also covers P2TRv2. The transition options Coinbase listed for evaluation include post-quantum-only outputs such as P2QR, 1-of-2 hybrids, commit-reveal mechanisms, a staged policy for new and legacy outputs, and sunset, freeze, rate-limiting or rescue alternatives for legacy signatures.

Coinbase described dormant, lost and exposed coins as a separate governance and engineering problem. Its list covers pay-to-public-key (P2PK) outputs, reused keys, Satoshi-era holdings and the possibility of covert quantum theft before the public learns that a CRQC exists. The company said the authors of any rescue proposal should show that the rescue path is itself safe against a quantum attacker who knows only an exposed public key.

The October post follows two earlier Coinbase posts on Bitcoin’s post-quantum transition. On July 23, security chief Jeff Lunglhofer wrote that Coinbase was building PQ-CoreKMS, a post-quantum version of the MPC-based key management system that protects about 99.9% of the assets Coinbase holds. He said the signing pipeline was due within a year, with two to three further years of research to follow on full MPC for lattice-based schemes.

On September 9, Coinbase reported on a closed-door workshop at Stanford University that it co-hosted with cryptographer Dan Boneh and Localhost Research.

Coinbase is researching a fallback in which keys would be encrypted and assembled only inside programmable HSMs, for use if Bitcoin adopts a scheme that does not work with MPC, Decrypt reported on September 22 after an interview that Yehuda Lindell, Coinbase’s head of cryptography, gave to MARA Foundation TV. Decrypt attributed the difficulty to hash-based signatures, which it said may lack the arithmetic structure that makes key splitting possible. It described research on solutions, including work by Boneh, as highly experimental.

Coinbase is a founding member of the Bitcoin Security Consortium, which nine institutions launched on July 23 with a pledge of 15 million USD over three years. The Block and several other outlets reported a figure of 5% for Coinbase’s share of all bitcoin; the post says about 12%.

My Analysis

Disclosure first: I advise Project Eleven, which works on post-quantum security for digital assets. I cite no Project Eleven material here. Steve Vaile, one of the authors of BIP-361, the legacy-signature sunset proposal I describe below, is Consulting Director for EMEA at Applied Quantum. I am the founder and CEO of Applied Quantum, which sells post-quantum migration advisory services.

In April I reviewed the first position paper from Coinbase’s Independent Advisory Board on Quantum Computing and Blockchain, a panel of five outside researchers and Coinbase’s head of cryptography, Yehuda Lindell. The October post comes from Coinbase itself, written from inside a custody operation. It is the most detailed statement of custody requirements for Bitcoin’s post-quantum signatures that I have seen from any custodian.

Custody Constraints in Bitcoin’s Post-Quantum Design Work

Bitcoin’s post-quantum design work happens on the developers’ mailing list and on Delving Bitcoin. In the overview discussion Pieter Wuille opened on July 27, the participants argue about fee profiles, adoption by the long tail of wallets, workflows such as sharing extended public keys, and who should decide when to disable elliptic-curve spending. Wuille, who co-wrote the BIPs that specify Bitcoin’s Schnorr signatures and Taproot, counted centralized custodians among the slowest adopters in that discussion, noting that they seem to take “a long time even for small changes like sending to new address formats.”

Coinbase’s own write-up of the Stanford workshop says several developers in the room had not previously considered the full institutional impact of a post-quantum transition. Coinbase’s July and October posts give the operating facts. The company protects about 99.9% of its holdings with MPC, according to the July post. Its signing servers run independently in several zones, and its keys must be recoverable from backups. In the October post, it also asked evaluators to measure mass-migration throughput and the time and fees needed to migrate a representative population of vulnerable outputs.

Threshold Signing for Lattice and Hash-Based Schemes

MPC is how Coinbase keeps any single machine from having a complete private key, and its CoreKMS does this today for ECDSA and Schnorr. Post-quantum schemes differ in how easily several parties can produce one signature. Hash-based signatures may lack the arithmetic structure that key splitting relies on, Decrypt reported after Lindell’s interview.

For ML-DSA, NIST’s lattice-based signature standard, two threshold designs were published at USENIX Security 2026 in August. Sofía Celi and four PQShield researchers describe their Efficient Threshold ML-DSA as the first threshold scheme fully compatible with ML-DSA. For ML-DSA-44 and up to six parties, average communication per party is at most 1 MB. Quorus, by Alexander Bienstock and four other J.P. Morgan researchers, scales to any number of parties in an honest-majority setting, and its signatures verify under a standard ML-DSA implementation.

NIST published a call for multi-party threshold schemes, including signatures, on January 20. It set no date for a standard.

For hash-based signatures, Dan Boneh, Benedikt Bünz and three co-authors posted PRAWNS in September. With their method, a group of signers produces a Winternitz, XMSS or FORS signature that looks like an ordinary signature to the verifier. The scalable version of PRAWNS uses a lattice assumption only among the signers, so Bitcoin’s verifier would still check a plain hash-based signature, as Localhost Research’s summary explains. The authors note that PRAWNS does not directly apply to SLH-DSA, the basis of SHRINCS’s stateless path, and lacks an efficient distributed key generation protocol.

Boneh is a member of Coinbase’s advisory board and co-hosted the Stanford workshop with Localhost Research.

In July, Lunglhofer gave PQ-CoreKMS a year, then two to three years of research on full MPC for lattice-based and potentially other schemes, to ensure “that keys are never combined.” I read that wording as meaning the interim pipeline reassembles keys inside secure enclaves when it signs, although the post does not say so directly. The HSM fallback in Decrypt’s report is a separate design under research.

Coinbase is asking Bitcoin to include at least one scheme with promising MPC compatibility. The threshold designs that could meet that request all come from recent research. The request is reasonable from a custodian of its size, but it concerns consensus code: every scheme Bitcoin enables adds verification code that every full node must keep. A lattice scheme would also add a new hardness assumption and larger public keys.

Much of the Bitcoin-specific signature work is hash-based. The SHRINCS draft lists six authors from an eight-member working group: seven from Blockstream, Brink, Cloudflare, OpenChain and OpenSats, and one independent developer. In a follow-up post to his July overview, Wuille proposes a hash-based post-quantum opcode for both output types he favors.

The one lattice-specific Bitcoin draft I found, an ML-DSA-65 output on witness version 3 posted to Delving Bitcoin in April by Echelon Labs Research, has no BIP number. The only developer who replied publicly, conduition, one of the SHRINCS authors, asked why ML-DSA should not instead be enabled in Tapscript, the script language P2MR shares with Taproot.

If Bitcoin enables only hash-based schemes, Coinbase would have two routes on current evidence: the HSM fallback, or threshold hash-based signing along the lines of PRAWNS once that work covers the scheme Bitcoin picks. A lattice scheme in consensus is the nearer route to the kind of MPC Coinbase runs today. I would put that trade-off in the evaluation Coinbase asked for, next to block space and assumption diversity. As I noted in June, a single P2MR output could contain ML-DSA, SHRINCS and SLH-DSA leaves together, once Bitcoin activates opcodes that verify each of them.

SHRINCS Already Has the Stateless Mode Coinbase Asked For

The construction behind SHRINCS was first sketched in the appendix of a December 2025 report by Blockstream researchers Mikhail Kudinov and Jonas Nick. The SHRINCS Working Group posted its first draft BIP to the Bitcoin development mailing list on August 26.

A SHRINCS key has two signing paths. The stateful path is built from one-time signatures and produces small signatures, but it is secure only if the signer never uses a one-time key twice. On the stateless fallback, the signer uses the SLH-DSA algorithms with a non-standard parameter set. I covered Blockstream’s earlier version of the design in June, before the working group’s draft existed; the figures below come from the current draft.

The draft’s rules for the stateful path are strict. Signers must not back up and restore state counters or export them to other software. Before returning a signature, a signer must record each increment in persistent storage. “Implementations must not allow concurrent signing,” the draft says. When state is lost or uncertain, as after a restore from a backup, a signer must refuse the stateful path and sign with the stateless one. An implementation that cannot manage state may use the stateless path alone.

The signing setup Coinbase described is the one the draft forbids on the stateful path: independent servers in several zones signing with the same keys, and recovery from backups. If Coinbase keeps that architecture, it may sign only on the stateless path under the draft’s rules. That matches the stateless-only mode Coinbase asked for. Coinbase and the SHRINCS authors want the same safety property.

When a custodian bumps a fee, it signs a replacement transaction, and on the stateful path it must use a new one-time key for that signature. If one server signed the original and another signs the replacement, the two servers must share one counter.

BIP-360’s authors wrote in their related-work section that with one-time signatures and no stateless scheme, common practices such as replace-by-fee (RBF) and child-pays-for-parent (CPFP) could risk revealing private keys. In the follow-up to his July overview, Wuille wrote that “stateful signature schemes are scary” and that he would be more confident of not losing security through incorrect use if they could be used only together with elliptic-curve signatures.

The stateless path costs block space and signing time. Sizes in bytes for one public key and one signature:

Sources: the SHRINCS draft specification as of October 17, 2026; FIPS 204 for ML-DSA; FIPS 205 for SLH-DSA; the specification for Falcon-512, which NIST is standardizing as FN-DSA. SHRINCS targets NIST category 1, so the rows do not compare equal security levels. The figures exclude script and control-block overhead, which differ by output type.

A custodian on SHRINCS’s stateless path would put about 5.8 KB on chain for each key and signature, about 1.6 times ML-DSA-44 and about 11% more than ML-DSA-65. Kudinov has argued that lattice schemes on Bitcoin need a larger security margin than Cloudflare’s ML-DSA-44. In his view, Bitcoin cannot switch parameters as easily as Cloudflare can reissue certificates.

By the draft’s operation counts, the average signing cost is about 1.7 million SHA-256 compressions per signature on the stateless path and about 133,000 on the stateful path at the maximum tree depth of 255. A stateless-only custodian would pay the stateless cost on every spend from a SHRINCS output, such as a withdrawal or a consolidation. Transactions that move coins out of today’s outputs would still be signed with the existing ECDSA or Schnorr keys.

SHRINCS’s compact path suits a personal hardware wallet, with one device and one counter, better than it suits an exchange. One scheme with two paths can serve both kinds of signer, with the custodian paying more per signature. A second scheme in the same output type would give custodians another option, which is the flexibility Coinbase asked for in its second point.

P2MR, P2TRv2 and the 1-of-2 Hybrid

BIP-360 defines Pay-to-Merkle-Root (P2MR), an output that commits to the Merkle root of a tree of scripts. Unlike Taproot, P2MR has no key-path spend, so a public key appears on chain only when a script is used. BIP-360 was merged into the BIPs repository as a draft on February 11 and has no activation date. Its authors, Hunter Beast, Ethan Heilman and Isabel Foxen Duke, left post-quantum signatures to separate opcodes or leaf versions.

P2TRv2 has no BIP. Wuille describes it in his overview as an output with Taproot’s semantics plus post-quantum opcodes, on the expectation that a later consensus change will disable its elliptic-curve paths within that output type. He notes that each P2TRv2 output includes an elliptic-curve point, visible on chain. He would use P2TRv2 to make emergency post-quantum signing available to as many users as possible, and a P2MR-based output for the longer-term migration, with tripwire and miner-lockdown mechanisms for disabling elliptic-curve spending in both.

The first property on Coinbase’s list for an ideal post-quantum path is a commitment structure that hides public keys until needed and avoids a quantum-vulnerable key path. P2MR meets both conditions as specified. In a P2TRv2 output, the elliptic-curve key is on chain from the moment the output is created, and it stays there after a consensus change disables elliptic-curve spending. Until that change, anyone who can produce a valid elliptic-curve signature for that key can spend the coins. Coinbase named P2TRv2 as an example of algorithm flexibility; on key exposure, only P2MR has the property Coinbase listed first.

The 1-of-2 construction Coinbase gave as one possible transition design differs from the hybrids security teams know from TLS. In a hybrid key exchange such as X25519MLKEM768, an attacker has to break both algorithms. In a 1-of-2 output, the owner can spend the coins through either path, so an attacker needs to break only the classical one. The coins are safe from a quantum attacker only once the classical path is disabled, or while the classical key stays unknown to that attacker.

How long the classical key stays unknown depends on the output type and on the holder. In P2MR, with the classical and post-quantum paths in separate script leaves, the classical key stays off the chain until someone spends through that leaf, provided the holder does not reuse it or share it, for example through an extended public key. In P2TRv2, the elliptic-curve key is already on chain, so the coins are safe only if that spending path is disabled before a CRQC exists.

In July, the SHRINCS co-author conduition asked P2TRv2’s proponents to “solve the EC-disabling timing problem” first. Wuille replied that the problem is easy to overstate, since many if not most users of other output types will equally depend on a consensus change, a tripwire or the hashrate majority to disable elliptic-curve spending.

Wuille argues for P2TRv2 mainly to reach the long tail of slow adopters, among whom he counts centralized custodians. Coinbase, a centralized custodian, has asked for the key-hiding property that P2TRv2 lacks. The participants in Wuille’s discussion can now weigh a stated requirement from one member of the group he wants to reach.

Legacy Coins as a Separate Problem

Coinbase wants legacy coins treated as a separate governance and engineering problem, debated alongside the signature work. The main written proposal on that problem is BIP-361, by Jameson Lopp and five co-authors, an Informational BIP in Draft status that requires a post-quantum signature BIP not yet written. Under Phase A, about three years after activation, nodes would reject transactions that send coins to quantum-vulnerable addresses. Under Phase B, two years later, nodes would accept ECDSA and Schnorr spends only through a quantum-safe rescue protocol. The BIP gives one example: a proof that the spender knows the BIP-32 parent key behind a hardened derivation path.

Coinbase’s test for any rescue path is that an attacker who knows only an exposed public key cannot use it. The owner of a wallet built with hardened BIP-32 derivation knows a parent key that such an attacker cannot compute from the exposed key. Developers could build a rescue protocol on that difference, though the protocol would have its own security and deployment requirements.

BIP-361’s authors write that no such knowledge asymmetry is known for coins in P2PK outputs, including an estimated 1.7 million BTC from Bitcoin’s first years. For those coins they support Hourglass, a proposed limit of one P2PK spend per block, which is one form of the rate-limiting Coinbase listed.

Coinbase also lists covert quantum theft before the public learns a CRQC exists. Wuille described a version of that scenario in February: coins held under many known public keys move to post-quantum addresses, and someone then posts a claim to have a CRQC, signed with the keys that held those coins. He wrote that the movements alone might not affect Bitcoin’s value much, but that someone publishing the signed statement “would likely send the market tumbling down.” In 2025 I argued that Q-Day would arrive as a confidence crisis. On that day, Coinbase would be among the first custodians to field clients’ questions.

Developers can work on signatures while the legacy debate continues. As Wuille argued in the same discussion, though, the value of migrated coins depends on how safe the unmigrated ones are believed to be. Coinbase can move its customers’ coins to new outputs; it cannot move the P2PK outputs from Bitcoin’s first years. I take no side here on freezing coins.

Saylor and Coinbase on October 13

On October 13, the day Coinbase published, Michael Saylor, executive chairman of Strategy, spoke at a World Bank fireside chat during DC Fintech Week. In his chapter list for the session, he titled the quantum segment “why Bitcoin can upgrade when consensus forms.” In a July post, he called for protocol changes to be “rare, conservative, and driven by necessity, not ambition.” Coinbase, a fellow founding member of the Bitcoin Security Consortium, argues for preparing before any announcement of a CRQC. I checked Saylor’s quantum claims one by one on October 15.

What Changes for Custodians and Developers

Coinbase’s post contains no new resource estimate, so it gives no reason to revise when a CRQC could attack Bitcoin’s signatures. A common reference point is Google Quantum AI’s March estimate: 1,200 or 1,450 logical qubits, depending on the variant, on fewer than 500,000 physical superconducting qubits. Once a specific public key is revealed, the remaining computation would take about nine minutes on a machine nobody has built.

Coinbase’s contribution is a public record of one large custodian’s needs, made while the design is still open. BIP-360 has been a draft since February, with no activation date. Taproot took almost four years from Gregory Maxwell’s proposal to activation in November 2021. By Coinbase’s stated targets, PQ-CoreKMS would be ready around mid-2027, and full lattice MPC two to three years after that.

At least one of Coinbase’s institutional clients already discloses the risk to investors. In its quarterly report for the period ended June 30, 2026, BlackRock’s iShares Bitcoin Trust ETF, which names Coinbase Custody as its bitcoin custodian, warns that a post-quantum transition could require broad consensus within the Bitcoin community “and a fork (or multiple forks).”

My recommendation is for the other custodians, exchanges and funds that hold bitcoin at scale: publish your signing constraints now, in the form Coinbase used, while Bitcoin’s developers are still choosing schemes. Custody architectures differ, from multisignature setups to HSM-only signing. Bitcoin’s developers can weigh only the constraints they can see. Coinbase asked evaluators to report how their result changes when custody feasibility is weighted differently. Whoever runs that analysis will need inputs from more than one custodian.

Three of Coinbase’s requests depend on choices in Bitcoin’s design. The stateless signing path is already in the SHRINCS draft. The output type that hides keys, P2MR, is defined in BIP-360, a merged draft without an activation date. Multi-party signing is the furthest away: published research for ML-DSA, a September preprint for hash-based schemes, and two to three years out in Coinbase’s own schedule.

From the author