On the Quantum Computing Revolution

The centenary year of quantum mechanics is wrapping up; it is time to take stock of the quantum industry. It is a pivotal moment, and it is not entirely unreasonable to believe that, in the coming year, we will see an inflection in investments in the AI sphere, followed by renewed attention to quantum technologies. Before we definitively declare Quantum the “next big thing”, though, it is important to anchor our expectations to firm ground.

The quantum scene is more multifaceted than it may at first glance appear, with tides of hype not doing the best job of representing where the real opportunities are. Of course, the prospect of pioneering a new model of computation — with the hope of re-enacting success stories such as Microsoft, IBM, or Apple — sits at the back of the minds of many. There is, however, a fundamental difference with previous computing revolutions: We do not have definitive proof that quantum computers will outperform classical computers in the short term, at least not on computational tasks which we could characterise as broadly disruptive.

Mostly, the capital markets are buying into quantum computing because they are convinced either (i) that these devices will be able to solve complex problems by trying all solutions at once, perhaps even in a “multiverse”, or (ii) that the exotic structure of quantum states will unlock more efficient machine learning, or (iii) that these devices will be successful at sampling high-quality solutions to hard optimisation problems of real-world relevance. Sadly, conviction (i) stems from a misunderstanding of the quantum computational model, conviction (ii) has been mostly disavowed for many machine-learning application domains, and conviction (iii) is premature at best, with little in terms of concrete evidence of potential short-term advantage on many interesting problem classes. What quantum computers can be used for — with good confidence that they will outperform classical solutions in the short term — are highly structured and very specific problems, a far cry from the looming multi-purpose computing revolution that some quantum computing manufacturers are trying to spin.

But, wait! — you say — Quantum computers can be used to factor large numbers!

This is an important use case, one where we have strong evidence — trillions of dollars worth of evidence, to be precise — that quantum technology provides exponential advantage over classical algorithms. But it is also a problem with a very regular structure, a structure which quantum algorithms can exploit to find solutions. To better understand this, we look at the discrete logarithm problem, a broader, but closely related, instance of the same ability: Given a large integer $n$ with thousands of binary digits, as well as two integers $g, h$ modulo $n$, find a secret integer exponent $s$ such that $h = g^s \text{ mod } n$. The classical hardness of the discrete logarithm problem underpins the security of many contemporary cryptographic algorithms, because it implies that the function $s \mapsto g^s \text{ mod } n$ is effectively one-way (for $s$ sufficiently large to trigger modular reductions).

Unlike cryptographic hash functions such as SHA — which are designed on principles of entropy and mixing — the discrete logarithm problem is difficult because it is regular, not because it is chaotic. The function $s \mapsto g^s \text{ mod } n$ has a strict, exact periodicity: For adequately chosen $n$, it possesses few asymmetries which could be exploited to solve the problem any more efficiently than checking a large fraction of the possible exponents. The smoothness of the structure conceals the information from any local probe, but quantum mechanics allows us to switch perspective, probing the global structure instead: Regular information shared across the space of possibilities becomes directly accessible, in a way which is computationally unfeasible for classical machines. Indeed, many clever quantum algorithms follow this pattern, one way or another, by revealing global properties of highly structured mathematical objects which were carefully designed to look random at a local level.

In Defence of Quantum Key Distribution

It is in cryptography, rather than computation, that quantum advantage has already been demonstrated: Not in the language of computational complexity, but in the language of randomness and information. While complexity theory is mostly concerned with the internal structure of computations, it is in the interactions between computations that a truly revolutionary use of quantum resources is revealed: By controlling communications between the parties involved, near-term quantum technology can be used to design cryptographic protocols with security guarantees unachievable by classical technology.

Unlike its quantum computational counterpart, the quantum cryptographic advantage is entirely non-speculative: It is mathematically proven, it has multiple implementations, and it is demonstrably within reach of near-term quantum technology. It exploits the fundamental randomness at the very heart of quantum physics — randomness which cannot be faked nor predicted — to create a whole new class of cryptographic resources, protocols, and applications. The better known and most widely deployed of those applications is Quantum Key Distribution (QKD), which is the topic of our discussion today.

Last year, a report by the NSA discouraged the use of QKD for the post-quantum era. Analogously, recent guidance by the DoD CIO for migration to post-quantum cryptography explicitly rules out procurement and deployment of “quantum confidentiality or keying technologies”, including QKD, as a means of achieving security. We group their objections in four broad categories below, which we then address individually:

• QKD Requires Special-Purpose Infrastructure. QKD deployments rely on quantum internet infrastructure: they needs dedicated fibre or managed free-space links for communication, and specialised devices for cryptography. It’s not something you can deploy as pure software on general-purpose classical hardware — reducing upgrade and patch flexibility — or nor something you can easily drop into existing network infrastructure.

• QKD Is Hard to Secure in Practice. Real-world QKD security is limited by engineering and implementation, not just “physics”. Networks rely on trusted relays, with additional overheads and larger attack surfaces. Quantum devices are harder to validate in practice, and imperfections in design or manufacturing have lead to vulnerabilities in deployed QKD systems.

• Greater Denial-of-Service Exposure. The point-to-point nature of quantum resource distribution and the high sensitivity of quantum networking hardware makes it arguably easier to disrupt quantum communication at a distance, raising the risk of Denial-of-Service (DoS) attacks.

• QKD is only a Partial Solution. It is argued that QKD only produces shared key material for confidentiality purposes: It does not by itself guarantee that you’re talking to the desired counterparty, so you still need quantum-resistant public-key cryptography for source authentication across a network. In this scenario, the argument goes, the confidentiality goal can usually be met using the same quantum-resistant primitives used for authentication, at a lower price and with a risk profile which is better understood.

The objections above all have a core of fairness, with important warnings which be heeded as we progress from theory to implementation. But, in their categorically negative posture, they also betray a misunderstanding of both the scope and the possibilities of modern quantum cryptography. Quantum Key Distribution is not something to be distrusted as almost mystical: It is the first example in a fundamentally new cryptographic paradigm. Such vigorous objections from highly influential institutions have the potential to significantly damage the progress of one of the most exciting use cases for quantum technologies in the nearest future, and should therefore be vigorously rebutted.

On Hardware Requirements for QKD

QKD cannot be implemented purely via software, because it represents a fundamental shift in the nature of computational resources. Quantum resources are physical objects — more like an apples than like bits, to adopt a metaphor used by our very own Fabrizio Genovese at Devconnect. Unlike digital information, they cannot be copied, and hence require dedicated analog support for their storage and transmission. One might argue that, with sufficiently advanced molecular technology, an apple could almost perfectly be cloned, but for quantum resources this is a provable mathematical impossibility, not merely a limitation of engineering.

A certain degree of resistance to infrastructural changes is understandable, but when it comes to cryptography such a resistance is a historically losing position. Secret exchange has constantly evolved throughout history, and QKD — as an anti-tampering technology — bears many similarities to a forgotten art popular before the invention of the gummed envelope in the 1830s: Letterlocking, the practice of turning a letter itself into its own tamper-evident container, by carefully folding the paper. QKD achieves this “paper folding” in way which is mathematically, unequivocally verifiable, and this is precisely what makes it so exciting.

On Practical Security of QKD

In real cryptographic systems, big mathematical ideas are rarely where things routinely break: More mundane details such as timing behaviour, detector response, or small uncontrolled correlations in the hardware provide most of the attack surface instead. Far from an objection, this is precisely what makes QKD research so exciting, and where a fundamental difference exists between old-school protocol designs and modern device-independent ones.

Device-independent protocols are designed to not require trust in the underlying devices: The certification of security is done at the level of observed correlations, not at the level of a putative physical description from which classical data is supposed to emanate. This removes all trust in the physical layer from the equation, pushing it instead to the controlled boundaries of the computation.

The price we pay is shifted to sensitivity in the engineering: The degree of failure is less forgiving, and one relies more crucially on tight bounds in the parameter-verification part of the protocol. Quantum networking is subject to tighter constraints, because loss and noise grow with distance and quantum signals cannot be amplified and regenerated in a way quite as simple as classical signals would. But the literature has consistently shown that these bounds can be improved, and that tightening the security model often comes at much lower expense than what early day results might have suggested.

On Availability in QKD

The lower noise requirements imposed by quantum protocols on the engineering of quantum internet infrastructure make DoS attacks a more pressing concern, and the issues associated with the amplification and preservation of quantum resources render many of the existing mitigation strategies unworkable. As we shall see at the end of the next section, however, availability is essentially the only trade-off left in the device-independent model: confidentiality is unbreakable by design, and authenticity can be easily integrated. At the end of the day, the promise of device-independent QKD is exactly that if a key can be established, then the key is confidential: a protocol that refuses to produce a key because communication was tampered with is doing exactly what it was designed to do.

There are three plausible ways to address this issue. The first, more boring one, is to make the network itself more reliable, both in terms of hardening and in terms of redundancy. The second, more laborious one, is to push the theoretical boundary of device-independent protocols — a discipline that, we shall remind our readers, is still in its infancy — into progressively more tolerant noise regimes. The third, more fundamental one, is to realise that the issue is actually restricted to the distribution of raw quantum resources, and not to the establishment of the confidential key material itself. We elaborate further on this final point.

In order to run QKD, participants must share quantum resources, in the form of entangled pairs of quantum systems. In current designs, these resources are short-lived: They must be distributed on the fly across a quantum network, and immediately used to run the key generation protocol. However, this will not always remain the case: With the ongoing, tremendously accelerated development of reliable quantum memories, it will soon become possible to store quantum states, for use at a later stage.

The ability to keep quantum resources in memory decouples the two phases of QKD:

• The quantum resource distribution phase can be performed over a reliable quantum internet connetion, or it can alternatively be moved offline, e.g. by physical exchange of quantum memories. For online distribution, DoS attacks can be mitigated, for example, by discarding tainted batches and repeating the transfer until success.
• The key generation phase can be performed at any time after quantum resources have been exchanged, consuming only the required amount of resources and leaving the remaining quantum states untouched in storage. This stage only requires classical communication between the parties: It can be performed over the very same classical networks that already support our global information infrastructure, protected by the same DoS mitigation techniques.

How is this different, one might ask, from establishing a long pre-existing key and then using batches of bits as required? This is, after all, how one-time pads historically worked. The difference exists, and is monumental. Quantum resources in storage hold no confidential information: the key is generated at time of use, and any tampering of the quantum systems is covered by the device-independent security guarantees. Advance storage of quantum resources is merely a solution to the resource distribution problems, and it involves no assumptions of trust over time.

On Authentication in QKD

It is fair to acknowledge that many current QKD designs rely on a channel the authenticity of which has otherwise been established, e.g. by secured access or by public-key cryptography. This is, however, a matter of simplification, not one of necessity. It is absolutely possible to integrate authentication into QKD, in a way which exploits the unique features of quantum resources.

The key observation is that, in device-independent QKD, the only way for a round of key generation to succeed is for the two parties to operate on the two halves of a single entangled pair. At the time of key generation across a classical network, possession of the corresponding half of a batch of quantum resources is the only thing needed for authentication: No impostor — defined here as someone not in possession of the matching resources — can successfully run the key generation process with us. As long as quantum resource distribution was performed in an authenticated way — possibly much earlier on, possibly even by physical transfer of memory devices — key generation is automatically authenticated as a consequence, thanks to device independence.

We are then left with the problem of authenticating quantum resource distribution across an insecure quantum network. As long as we accept a small amount of initial shared entropy to be used for bootstrapping, this can be achieved by fairly traditional techniques.

An initial batch of quantum resources can be distributed and authenticated by running device-independent QKD combined with HMAC on a randomly selected subset of the entangled pairs. This bootstraps an initial pool of authenticated resources, which can later be consumed to perform key generation and/or to authenticate the distribution of more resources. Importantly, the security of the key generation process is independent of the confidentiality of the entropy of the original HMAC, because fresh entropy is generated by the QKD process each time. In the worst case scenario, authentication of the initial batch of quantum resources fails, and the process must be repeated with some fresh HMAC entropy: But it only needs to succeed once, and then the process is self-sustaining. (Also, physical memory distribution can be used for the initial bootstrapping.)

Conclusion

Device-independent cryptographic protocols have the potential to deliver the most exciting near-term applications of quantum technology, with a demonstrable advantage over comparable classical techniques.

Our mission at NeverLocal is to make this technology a reality: The final frontier of secure communications, guaranteed by very laws of Physics, decoupled from any trust in hardware and infrastructure. Join us.

Introduction

In a recent post, we detailed our vision for a viable implementation of Vitalik’s 2024 proposal to save users’ fund in case of a quantum emergency. This proposal notably makes use of Account Abstraction to establish a user-space migration path. As Account Abstraction is an almost exclusive prerogative of Ethereum, it makes sense to believe such a course of action to be of difficult generalisation, especially when it comes to blockchains with limited smart contract capabilities as Bitcoin.

And yet, as Ordinals and the like have demonstrated, Bitcoin’s notorious limitations still provide space for elegant solutions. This has left us wondering, what if we could find a way to make our proposal work for Bitcoin too?

Bitcoin Script

First of all, if you come from the Ethereum/Solana world, you’ll need a crash course in how an UTXO-based cryptocurrency works. The most useful thing to do here is to imagine a Bitcoin transaction as some sort of spider: A block with $m$ legs to its left (we call these inputs), and $n$ legs to its right (we call these outputs). To each leg, we attach a number of satoshis, representing monetary value. Essentially, the transaction takes satoshis on the inputs and reallocates them as prescribed by the outputs. Clearly, \(\sum_{i=0}^m \text{input}_i \leq \sum_{i=0}^n \text{output}_i\), that is, we cannot spend more than what we put in the transaction; the difference between these two values is the fee we give to the block miner.

To create a new transaction, you wire the outputs of some transactions into your new transaction’s inputs. The outputs of the new transaction, together with the outputs of previous transactions not yet spent, will be themselves up for being used as inputs for new transactions in the future. All in all, we’re just wiring spiders together, as in the following picture.

In this setting though, everyone is able to spend everyone else’s money, as we haven’t introduced any notion of ‘ownership’ yet. To prevent this, the outputs of a transaction are locked with a bunch of code written into something called Bitcoin script, the programming language of a very simple dual-stack pushdown automaton. It consists of a set of instructions that allow to manipulate items on a stack, that is, a bunch of data that can be accessed in a “last in, first out” (LIFO) order. To give a tangible example, consider the following script:

OP_DUP
OP_HASH160
<recipient>
OP_EQUALVERIFY
OP_CHECKSIG

This locking script was the standard way of locking a transaction output before Taproot. All instructions starting with OP_ are Bitcoin script instructions that manipulate the stack in some way, whereas <recipient> is just the hash of the output’s recipient’s public key. This script was just attached to a transaction output. To spend such output, you had to provide the following script on the corresponding input:

<sig> <pKey>

which is nothing more than a signature and a public key that owns it. At evaluation time, input and output script would be concatenated and executed, as follows:

As you can see, a given output here is spendable if and only if the transaction trying to spend it is signed by the right key.

A simple change

Now that we kinda know how Bitcoin (used to) work, we can figure out a way to adapt our zk-based graceful fallback solution to BTC. To make our proposal viable, it would be enough to introduce a new opcode, called OP_ZKCHECKSIG. This opcode accepts three pieces of data, <sig>, <zkProof> and <pKey>. It would behave exactly as OP_CHECKSIG, but it would also check that <zkProof> is a valid proof of seed for the corresponding signature.

The fallback mechanism would work as follows:

• Under normal circumstances, OP_ZKCHECKSIG is set to be equal to: OP_SWAP OP_DROP OP_CHECKSIG. This literally means “drop the zk proof part, and just verify the signature”. In doing so, nothing changes compared to the actual status quo. Notice that in particular users would not have to provide zk proofs at spending time (they can just provide a bunch of zeroes), making performance impact incredibly low both in terms of blockspace and computational capacity.
• In case of a catastrophe, miners would automatically soft fork to a codebase where OP_ZKCHECKSIG is implemented “for real”. Here OP_ZKCHECKSIG, does actually verify zk proofs, and user trying to spend their Bitcoin after this fork are required to provide valid proofs of seed, otherwise their transactions will be invalid. Notice that, at this point, all transactions that used OP_ZKCHECKSIG in their locking scripts would be automatically protected.

We really like this mechanism because:

• It is completely opt-in, but
• Does not require active migration by generating a new address. Updating your Bitcoin wallet, so that on creating new txs OP_ZKCHECKSIG is used in place of OP_CHECKSIG would be enough to stay protected, no further action required by the end user. This is basically a ‘transparent update’ and it is arguably better in terms of UX than what we can do with Ethereum.
• Furthermore, this solution does not require the user to switch to a new, less battle-tested cryptographic scheme. This is important: In swapping ECDSA for, say, Falcon, one may end up being exposed to a not-yet-discovered weakness of the Falcon cypher. This is not the case here: The proof authentication sits on top of the already used pkey authentication, and a security breach can happen only if both fail at the same time, exactly as for any hybrid signature scheme proposal we heard about in the Web2 world.

Notice that, as already detailed in our last post, this protects only addresses generated from a seed phrase or a master key, using e.g. BIP-32 hierarchical deterministic derivation (cf. also BIP-39 and BIP-44). Moreover, this change is designed to be less invasive as possible and opt-it, hence it does not protect transactions that use OP_CHECKSIG. Still, once deployed, and if popular, it would protect an increasingly growing share of BTC in circulation.

There is another important thing to stress: In this setting, we need to make sure that the users we are paying do in fact use keys derived from a seed phrase. If this is not the case, in the wake of a catastrophic event the corresponding transaction outputs would be locked forever. Still, there are many different ways to fix this problem, so we won’t go too much in depth about it here.

Here comes despair

So, we saved Bitcoin and are now happy, right? Alas, no. When you try to make this work, you hit a giant wall, namely the fact that data pushed in the Bitcoin script stack cannot exceed 512 bytes. This is wildly insufficient, as no zk proof goes below a few Kbs at the moment, and probably never will.

So, no joy? Yes and no. Keep reading…

Taproot

In 2021, the Taproot update brought many changes to Bitcoin:

• First, it swapped the ECDSA signature scheme with a Schnorr signature scheme. This is of minimal concern to us.
• Then, it enabled Merkelized Abstract Syntax Trees (MASTs), which allow the implementation of more complex spending conditions on transactions. This is of the utmost interest for us because, among other things, it lifts the data push limitation highlighted above, making it possible to add up to several kilobytes of data to an unlocking script. This would make our proposal viable.
• It also introduces Tapscript, a redesigned scripting language for BTC. This, again, is mainly technical and of minimal interest to us.

So, it would seem that the Taproot update has everything we need to solve our problems. The only issue remaining at this time is that Taproot uses a weird — if I may — way of committing data or scripts to a transaction. This was somehow necessary to maintain backward compatibility with the older standard (something the Bitcoin crowd cares very much about), but unfortunately ends up being incredibly quantum weak. In a nutshell, the idea relies on the group properties of elliptic curve cryptography: Say that our public key is $P$ and the corresponding private key is $sk$. We commit our unlocking script to a value $t$, and use this to obtain a new key couple $(sk’,P’)$. If you know $sk$ and $t$, you can compute $sk’$ and thus sign things as $P’$, but if you only know $P’$, you cannot easily obtain $sk$, $t$ or $sk’$. The problem is exactly that the cannot easily obtain™ part gets completely annihilated by quantum computers. Given a public key $P’$, a quantum-enabled attacker would be able to:

• Make up any unlocking script that commits to any value $t’$, possibly one different from the original unlocking script which the tx was supposed to be using;
• Compute a corresponding private key $sk$ such that $sk$ and $t’$ generate $sk’$.

In layman terms: Every time we see a transaction, we can literally rewrite its unlocking conditions. This makes our (any?) fixes completely useless as a quantum-enabled hacker can bypass our unlocking script.

Enter BIP-360

Luckily for us, there’s a group of people, guided by Hunter Beast, that is pushing very hard to implement a new update proposal called BIP-360. This is rather technical, but in a nutshell, it is a patch to the “quantum-weak part” of taproot. Notice that this proposal does not directly fix Bitcoin’s problem, as the signatures BTC uses are still not quantum safe. But, as far as our proposal is concerned, BIP-360 is enough to make our fallback solution viable, effectively protecting everyone in a simple, opt-in fashion.

For now, this concludes our bumpy ride. We can only hope BIP-360 gets the attention it deserves, and is ultimately made part of the protocol. If this happens, we’ll be more than happy to do our part, as we are already doing for Ethereum!

You can find the latest draft of our proposal on our GitHub repository.

Introduction

Ethereum’s long-term security depends on the hardness of elliptic-curve cryptography. A credible quantum breakthrough would render existing accounts vulnerable, exposing all assets secured by elliptic curve cryptography (ECC). Current mitigation plans focus on replacing the signature scheme at the protocol level, e.g. through new transaction types, precompiles, or consensus-layer upgrades. Such changes will require a hard fork and years of coordination, all the while users’ funds remain dependent on ECC. In the event of a quantum emergency, protocol-level post-quantum EIPs juts couldn’t deploy fast enough to save the ecosystem.

We propose a different approach, built on existing capabilities of the Ethereum stack. While protocol-level proposals aim to replace ECC at the consensus layer — by upgrading key material — we instead leverage Account Abstraction (cf. ERC4337 and EIP7702) to establish a user-space migration path:

• Users prove account ownership using quantum-resistant zero-knowledge proofs, implementable today in both hardware and software wallets.
• Proof verification occurs entirely on-chain at Layer 1, with no hard forks, no new transaction types, and no trusted intermediaries.
• No modification is required to existing or future dapps, thanks to account delegation mechanics already available in Ethereum today.

By operating at the account layer, our approach preserves full protocol compatibility, while providing an immediately deployable migration mechanism. Ethereum can achieve practical protection before the protocol itself completes a quantum transition, something no other proposal currently enables. This realizes the graceful emergency fallback envisioned in Buterin’s 2024 proposal, but makes it operational today.

Account Abstraction

In Ethereum, externally owned accounts (EOAs) are hard-coded to authenticate through signatures based on elliptic curve cryptography (ECC). Account Abstraction (AA) — defined by ERC4337 and related proposals — moves authentication logic into contract space instead, allowing any smart contract to act as a fully functional account. This introduces a programmable authentication substrate to Ethereum, which we can leverage to build a quantum-safe migration path without requiring an early hard fork.

In our design, users migrate from traditional EOAs to quantum-safe ERC-4337 smart accounts. Instead of relying on ECC-based signatures, the smart accounts prove ownership by demonstrating knowledge of the seed phrase from which the EOA address was derived, e.g. via BIP-32 hierarchical deterministic derivation (cf. also BIP-39 and BIP-44). The proof takes the form of a STARK (see e.g. Ben-Sasson 2018), a succinct, transparent and quantum-resistant flavour of zero-knowledge proofs. STARK proofs are generated off-chain and verified by on-chain logic. This derivation approach is inspired by Buterin’s 2024 proposal and closely related to a 2023 proposal by Or Sattath and Wyborski.

The original EOA is not modified, but rather serves as the source of verifiable ownership which seeds the authority for the quantum-safe smart account. Using mechanics such as ERC-20 and ERC-721 approvals, permit-based authorisations (cf. ERC2612 and ERC4494), or ERC-4337 delegated operations, users can delegate the quantum-safe account to perform token transfers and dapp operations on behalf of the legacy EOA, establishing continuity of control. Once EIP-7702 is approved, EOAs can run STARK-based authorisation logic on their own, as a mechanism alternative to ECC-based signatures.

The key insight of our proposal is that Account Abstraction makes it possible for Ethereum to handle a quantum emergency entirely at the consensus level, with no immediate changes needed to the core protocol. We now describe some of the specifics.

Quantum-safe accounts can be deployed by sponsoring parties on behalf of any EOAs which have not yet migrated, because authentication is tied to proof of knowledge of the original seed phrase. This allows a considerable portion of EOAs to be protected in an emergency, not just the ones with the foresight or technical know-how to perform an early migration. It is impossible to conclusively determine the approximate number of EOAs whose addresses arise by hierarchical deterministic derivation, but estimates based on popular wallets — both hardware and software — place a realistic lower bound estimate around the majority line.

While we will endeavour to support as many EOAs as possible, there is an ultimate limitation to our approach. Unless the private key was derived by means of some quantum-resistant one-way function, there is no purely cryptographic way to definitively determine the ownership of an EOA once advanced quantum capabilities have been demonstrated. In the absence of pre-emptive migration steps, such situations will likely require off-chain resolution.

A gas vault, coupled with gas sponsorship mechanics, can be used to reduce the financial burden caused by the additional complexity of on-chain STARK verification. A fraction of the vault can be dedicated to sponsoring early user adoption, with the majority unlocked by custodians in case of an emergency.

Broad integration of the proposal into wallet hardware and software will be necessary for seamless UX. At the enclave/internals level, this consists primarily of the generation of STARK proofs from seed phrase material. At the interface level, this includes deployment and operation of the quantum-safe accounts, one-click delegation for tokens and dapps, and access to gas sponsorship. Note also that the quantum-safe account address can be deterministically derived from the corresponding EOA address, making it possible to safely associate the two well in advance of an emergency.

The handling of an emergency at consensus level requires validators to stop accepting any transactions from EOAs, other than a standardised set of delegations to the associate quantum-safe accounts, including the transfer of Ether. The deployment and operation of quantum safe accounts proceeds normally, without protocol changes.

From a technical perspective, finally, this proposal greatly benefits from the introduction of a kill-switch into validator software. The economics of staking make it in the best interest of validators, as a collective, to protect the chain from malicious transactions in the event of a quantum emergency. While the decision to operate the kill-switch is ultimately left into the hands of validators, in accordance with their mandate as ultimate custodians of chain integrity, on-chain oracles integrated at the software level will likely be used to coordinate the response in an emergency.

Proof of Seed

A key step in our mitigation proposal is the implementation of signature lifting, the transformation of a quantum-weak authentication scheme — such as ECDSA, EdDSA, or Schnorr signatures — to a quantum-resistant one via zero-knowledge proof of the pre-image for some cryptographic hashing step which was performed as part of the key derivation algorithm.

Signature lifting is a broad technique, applicable to a wide variety of key generation pipelines, but for sake of concreteness we focus specifically on BIP-32 hierarchical deterministic wallets, arguably the most common key derivation technique in use today.

The BIP-32 key derivation spec presents multiple opportunities for signature lifting. Every private child key is derived from a parent private key via an application of HMAC-SHA512: if a parent/ancestor public key has not been exposed, knowledge of the parent/ancestor private key can be used as a witness for signature lifting of the child key. If the public master key has not been exposed, the master private key be used as a witness for all other keys, hardened or not.

There is, however, the possibility that the public master key has itself been exposed, and hence that the private master key is vulnerable to quantum attacks. The private master key is itself derived from a master seed via an application of HMAC-SHA512. The master seed is not exposed — unless compromised, see below — and knowledge of its value can be used as a witness for signature lifting of the master keypair itself.

Lifting opportunities for BIP-32 end at the master seed: in case of compromise, there might not be a further step available for lifting. If the master seed has been derived from a BIP-39 mnemonic, however, signature lifting becomes possible even in case of master seed compromise. Indeed, the BIP-39 spec prescribes 2048 applications of HMAC-SHA512 to derive the master seed from the UTF-8 NFKD bytes of a mnemonic sentence: as wallets typically store the master seed itself, rather than any of the intermediate hashes, the preimage to the last (or last few) HMAC-SHA512 applications is unlikely to have been compromised, and it can be used as witness for post-quantum lifting of the master seed itself. Unfortunately, nothing further can be done in case of mnemonic compromise.

Having laid out the plan, the challenge shifts to implementation. We have two desiderata:

• The zero-knowledge proof generation process must be suitable for execution on a variety of platforms and architectures, since it must be possible to integrate it with almost all wallets in current usage.
• The zero-knowledge proof verification process must suitable for execution on-chain, as part of the Account Abstraction framework, and in particular both proofs and verifier must be succinct.

Here, we encounter a problem: zero-knowledge technology has progressed enormously over the last few years, but a fundamental compromise remains to be made between succinctness at the verifier side and workload at the prover side. The vast majority of recent efforts have been focused in the direction of making proofs lightweight and succinct, but often at the expense of heavier prover workloads.

STARK verifiers are already used in production for on-chain verification, and recent proposals (cf. EIP-7885 and the NTT precompile) are poised to make the process more efficient. This makes STARKs very attractive for the verification side of proof of seed. Unfortunately, the STARK proof generation process is extremely computational intensive: while they might be streamlined enough to be workable on portable devices, there is no realistic prospect of compatibility with secure elements, the higher end of the wallet security ladder.

Secure elements are widely used as hardware wallets, performing critical computations in a tamper-resistant environment. However, these devices often impose a number of stringent limitations on computational resources, the terminal blocker for STARK prover implementation being available RAM in the order of a few dozen KBs.

While memory constraints rule out the vast majority of modern general-purpose, public-verifier ZK protocols, an important exception is represented by MPC-in-the-Head (MPCitH) protocols such as ZKBoo, where succinctness on the verifier side is traded for a significantly lighter workload on the prover side.

With a number of considerations, which will be discussed in a separate post, the ZKBoo protocol can be tweaked to generate proofs in a fully streamed fashion, with memory requirements independent of the trace length of the prover, the length of the individual proof responses, or the security parameter of the proof. This brings memory requirements for proof generation down to within a small factor — slightly above 3x — of the minimal memory requirements for the computation being proven, well within the capabilities of secure elements such as those used by Ledger wallets.

A critical limitation of ZKBoo — and one of the reasons why it doesn’t hold much mindshare in the modern zero-knowledge landscape — is that neither its proofs nor its verifier are succinct, in that both the size of the former and the runtime of the latter are linear in the trace length. This makes ZKBoo proofs unsuitable for direct use in the on-chain verification process, but that was not the reason why this technique was chosen: its job is to allow the practical extraction of a proof of knowledge from a computationally constrained secure environment, wrapped into a zero-knowledge container.

Once the ZKBoo proof has been produced, more powerful machines can be used to perform a second step of recursive verification, resulting in succinct lifting: where the ZKBoo proof might prove the statement “I know the seed from which this public key was derived”, the lifted proof would succinctly prove the statement “I known a valid ZKboo proof for the statement that I know the seed from which this public key was derived.”.

Importantly, the external machine performing the succinct lifting does not need to be trusted, because the ZKBoo proof itself already guarantees zero-knowledge. For the same reason, the technique used for succinct lifting does not itself need to be zero-knowledge. This latter observation opens the door to applications of succinct ZK systems — such as ones for binary fields — which may be well-suited to proving statements heavy in bitwise operations — such as those involved in the ZKBoo proof verification — but might not themselves be formulated in a zero-knowledge way.

On Friday, January 16, 2026, the University of Naples Federico II — the oldest public university in the world, and incidentally the one where the author of this post studied for his BSc — officially inaugurated Italy’s first Quantum Internet Testbed.

The launch took place during a strategic workshop titled “Towards a National Quantum Internet Infrastructure”, which brought together academic leaders, government officials, and major industrial partners.

We were honored to be among the guests, and we also got a tour of the lab. Since this took place in the campus where I attended classes during my BSc, it really felt a bit like a memory lane moment for me, which was quite nice!

Quantum Internet Testbed

The event was focused on presenting the Quantum Internet Testbed, a physical platform to test how quantum networks (using entanglement and quantum repeaters) can coexist with standard classical internet traffic. The project is led by Professors Angela Sara Cacciapuoti and Marcello Caleffi, members of the Quantum Internet Research Group at University of Naples Federico II.

A major focus of the testbed is Quantum Key Distribution (QKD) without trusted nodes and using commonly available — that is, not polarization preserving — fiber optic. This goal is very dear to us, as this kind of hardware infrastructure is exactly what we need to run our protocols.

Indeed, a way to efficiently summarize the ideas presented is “TCP/IP for the quantum internet”. Lack of a common standard is one of the biggest pain points of modern quantum internet infrastructure, so we were very pleased to see developments in this direction.

Institutional presence

The presentation was not just a technical demo but a strategic summit to align Italian stakeholders on a national quantum roadmap. The event featured interventions from the National Cybersecurity Agency, the Ministry of Foreign Affairs, and the Ministry of Enterprises (MIMIT). Undersecretary Alessio Butti sent a video message emphasizing the need for a “common language” between physicists and engineers to build a national quantum community. Indeed, a problem with the Italian quantum landscape at the moment is its fragmentation: there are many different initiatives backed up by different Italian universities and government agencies. All these initiatives are connected and talk with each other, but “from the outside” they appear disconnected, making it very difficult for foreign stakeholders to find their bearings.

Besides us, many high-profile industry representatives attended, including delegates from Airbus, Leonardo, TIM, IBM, Thales, and Huawei. This underscores the testbed’s goal of fostering a “multi-vendor” environment where different technologies can work together.

The initiative is supported by funds from the PNRR (National Recovery and Resilience Plan) and the RESTART Foundation. It represents the culmination of a long “stealth” development phase, now moving into active field testing.

To wrap up

Perhaps a bit surprisingly, Napoli is coming up as one of the most interesting cities for the development of quantum tech in Italy and Europe in general, especially when it comes to university research. Indeed, last year the university already unveiled its superconducting universal quantum computer, the first of its kind in Italy. It is very nice to see the same university following up on quantum communication hardware. We look forward to be able to test their infrastructure with our protocols, all while eating delicious pizza since we’re at it!

Quantum money is a proposed form of digital cash where authenticity and scarcity are enforced by quantum physics, not by ledgers, miners, or validators. In the NeverLocal Live session, Stefano Gogioso, Fabrizio Romano Genovese, and investor John Lilic articulated a deeper vision: quantum money as a new monetary primitive, one that anchors value to physical reality itself, enabling trustless exchange without consensus, institutions, or global shared state, and pointing toward a future where finance is enforced by Nature, not coordination.

For readers coming from crypto, it helps to start from the familiar: blockchains solve double-spending by keeping shared state and running consensus, which introduces tradeoffs in throughput, complexity, and privacy engineering. Quantum money aims at the same underlying target, value you can transfer without it being clonable, but tries to do so by leveraging physical constraints of quantum states rather than coordination through a global ledger.

The session starts with John highlighting a provocative implication: the long term quantum threat to blockchains may not be limited to breaking cryptography, but could also come from a future monetary rail that makes many ledger-based payment designs unnecessary. He described this as the bigger picture that is often missed: quantum money could make blockchains obsolete for large categories of payments because it can enable local, physics-enforced transactions without validators, miners, or shared state.

Where the idea comes from (Wiesner to modern research)

Quantum money traces back to Stephen Wiesner’s foundational proposal known as Conjugate Coding, which introduced the core idea of encoding information in quantum states so that counterfeiting becomes fundamentally difficult. Wiesner’s concept, as commonly discussed in later surveys and popular explanations, is that a mint could issue banknotes containing quantum states that can be verified but cannot be copied, because measurement disturbs unknown quantum states.

During the Live dialogue, Fabrizio emphasized that Wiesner’s early work was not originally presented as a solution to a widely recognized industry problem, which contributed to it being misunderstood for a long time. Fabrizio’s framing is that Wiesner’s real breakthrough was recognizing the applicability of quantum information as a resource rather than ordinary data, something that does not behave like a copyable file and therefore opens new cryptographic possibilities.

A key physical ingredient behind the resource framing is the no-cloning principle: unknown quantum states cannot be copied, which is why quantum states can be used to design anti-counterfeiting schemes. Modern research on quantum money goes beyond the original idea where only the issuer could check if a banknote was real. Today, people explore different ways to design quantum money and think about how it would work in real situations. Because of this, quantum money is not one single system, but a group of related approaches based on the same quantum principles.

This idea matters because money is not just a technical tool, but rather shared infrastructure. To work in the real world, it must scale across many users and situations, while balancing verification, privacy, and ease of use. During the session, the discussion often returned to a simple question: if quantum physics allows states that cannot be copied, can those states be used to create digital bearer instruments that behave like cash and still move across networks?

Why quantum money matters for crypto, stablecoins, and tradfi

Stefano grounded the motivation in a plain economic reality: whenever a society uses a medium of value that must be scarce and transferable, it must also be hard to forge or duplicate. Physical cash approaches this with sophisticated anti-counterfeiting measures, In purely digital environments, information can normally be copied at no cost. Cryptocurrencies solve this problem by adding external mechanisms such as cryptography, global ledgers, and consensus systems to prevent duplication and double spending. This comes at the cost of significant compromises, which users experience as fees, throughput limits, latency, MEV dynamics, privacy challenges, and governance or coordination risk. Quantum money would solve the same problem, without any of these downsides.

John’s argument goes further: if bearer value can be transferred peer to peer with cash-like privacy and without shared state, the economic rationale for many ledger-based stablecoin rails becomes less compelling. He connected this to how stablecoins function today as major trading counterparts and settlement instruments in crypto markets, suggesting that a quantum native bearer dollar could change what assets trade against and how liquidity routes form.

He also highlighted a security and governance angle that resonates with experienced crypto builders: blockchain finality can be protocol-defined and, in some historical circumstances, socially or politically reversible, whereas physics enforced transfer is anchored to physical law rather than to governance processes. Even if many users will continue to value blockchains for programmability and composability, the session’s thesis is that the money layer itself could migrate if physics offers a superior bearer primitive.

The discussion also stressed that quantum money is not merely a crypto issue, because the target is the broader financial system: settlement, cash-like transfer, and bearer instruments are fundamental primitives across markets. John framed the direction as physics-enforced finance, with quantum money as a flagship use case that could eventually reshape how institutions think about trust, transfer, and settlement guarantees.

At the same time, Fabrizio and Stefano were candid that many banks and large institutions are not seriously focused on quantum money today, often treating quantum initiatives as opportunities for signaling rather than near-term transformation. In their view, a meaningful shift will happen when the enabling stack, especially quantum networking and practical early forms of quantum memory, moves from prototypes to deployable demonstrators, at which point issuers and market structure players will have stronger incentives to engage.

The core concepts: qubits, photons, quantum internet, and memory

A recurring challenge in public discussions is vocabulary, so the session paused to clarify what a qubit is in practice. Fabrizio explained that a qubit is not a single physical object but an abstract unit of quantum information that can be implemented across different physical systems (with different trade offs), including photons, neutral atoms, trapped ions, and superconducting systems.

This matters because the implementation choice shapes what kind of money is feasible. For fast transfer across distance, photons are especially relevant because they can move through optical infrastructure and therefore act as flying carriers of quantum states suitable for networking.

However, photons are difficult to store for long periods, which is why quantum memory becomes central once the goal is not just transfer, but holding value in a usable way. Fabrizio identified quantum memories as a major bottleneck for implementing quantum money in practice, because money must be storable, not only transmissible.

He also highlighted a second engineering constraint: interoperability between transmission friendly and storage friendly substrates, meaning the ability to convert or interface quantum states between mediums (for example, receive a photonic state and store it in a memory based on neutral atoms). That requirement links quantum money directly to the broader quantum internet roadmap, because quantum networking also depends on distributing quantum states and often requires storage and interfacing to scale beyond short distances.

This is why the NeverLocal conversation treated quantum money and quantum internet as parts of the same trajectory. John described quantum internet infrastructure as being built quickly and argued that the world is approaching a modem moment, where once the missing enabling pieces click into place, utility expands rapidly.

Broader discussions of quantum networking similarly emphasize that quantum memories play a critical role in networking and distributed quantum protocols, reinforcing the session’s focus on memory as a gating factor. From an applied perspective, the NeverLocal view is that money is a uniquely powerful demand driver: once a credible path to quantum bearer value emerges, investment and engineering focus can accelerate the infrastructure flywheel.

A practical takeaway from the session is that quantum money should not be imagined as a single monolithic device, but as a stack. That stack includes (1) a method for encoding and verifying quantum states as bearer instruments, (2) networking to transfer them, and (3) memory and interfaces to store and handle them reliably.

Roadmap, early use cases, and common misconceptions

One misconception the speakers emphasized is timeline perception: quantum money sounds like far future science fiction, but the conversation argued it is closer than people assume because multiple parts of the enabling ecosystem are advancing in parallel. Stefano argued that fabrication and hardware progress are materially different today than in earlier decades, and that parts of photonic hardware are increasingly accessible, narrowing the gap between theory and deployable components.

Another misconception is underestimating how disruptive cash-like digital bearer could be once it exists. Stefano framed the value proposition for a broad audience as Bitcoin without miners and without consensus, meaning peer to peer transfer without global throughput bottlenecks and without needing a shared ledger for every payment.

John extended that narrative with a crypto native lens: privacy in blockchains often demands heavy engineering (for example, sophisticated cryptographic systems), while cash like local transfer has privacy as a default property because it is not broadcast to a global network. In his framing, quantum money can bring back that locality for digital value transfer, potentially delivering private transactions at scale without the same global coordination constraints.

A third misconception concerns who is building toward this future. Fabrizio and Stefano argued that some organizations discuss quantum tokens as a way to justify hardware roadmaps or attract investment, while NeverLocal’s posture is that quantum money is the end goal and the roadmap should be organized around making it real rather than around marketing demonstrations.

On early use cases, the session floated high frequency trading and fast settlement as plausible first wedges, precisely because short lived quantum states could still be economically useful when holding times are brief. Gaudenzio explicitly raised the idea that early quantum memories may be short lived but still valuable in ultra fast trading contexts, where consumption of states happens quickly and storage duration is less demanding.

Another near to mid term path discussed is that institutions that already issue money (banks and central banks) are natural candidates for minting or issuing quantum bearer instruments once the stack is viable, because they already sit at the origin point of value issuance. In that scenario, quantum money adoption could look less like a grassroots movement at first and more like an infrastructure transition led by issuers and market operators, with consumer UX arriving later as devices and networks mature.

The final misconception is that progress will be linear. The speakers argued that technology transitions often look slow until a threshold is crossed, after which applications and infrastructure reinforce each other in a flywheel. Their point was that quantum money benefits from a broader ecosystem building quantum networking and hardware for many reasons, so once early applications demonstrate real economic pull, acceleration can be rapid.

Full Video of the Live

1. The scheme allows to define quantum bills, that is, cryptographical objects representing some monetary value;
2. These bills can be remotely exchanged as you do for other forms of e-currency such as BTC;
3. These bills can be publicly verified. This means that everyone can verify that a given bill is authentic. This is in stark contrast with many quantum money schemes where the user can verify the bill authenticity only if the bill comes directly from the original issuer (such as the mint), which effectively makes the bills useless as they are not spendable with a third party. This was also a limitation of our previous efforts on the topic, which we now successfully overcome.
4. The scheme relies on very little quantum resources. Indeed, we only need quantum internet infrastructure and quantum memories to make it work. This is in stark contrast with many other works on the topic, which instead require significant quantum computational resources.

Dramatis Personae

The main technial innovation we propose is called a verifiable one-time program. If you are an habituée of this blog, you know we like one-time things, so this should not particularly surprise you. We won’t go over verifiable OTPs in detail here as we do not directly need them to talk about what we really wanna talk about, that is, quantum money. For now, all prerequisites we need can be summarized in the following cryptographic primitives:

• A cryptographic hashing scheme, that is, a function that allows you to map any kind of data into a fixed length string — nowadays usually 256 or 512 bits — in such a way that inverting the hash (finding some data that hashes to a pre-determined string) or finding collisions (two or more pieces of data that have the same hash) is computationally very hard.
• A public key signature scheme, that is, a cryptographic scheme where everyone has a private key — allowing them to sign something — and a public key — which is publicly known and allows other people to check that the signatures are authentic. Again, it should be computationally very hard to reconstruct the private key from the public key, otherwise everyone would be able to sign things on behalf of someone else.
• A one-time memory, that is, a cryptographic device that works like so: it has two bitstrings in memory; a user can specify a binary value, say 0 or 1; depending on the value specified, one of the two bitstrings is revealed, and the other is permanently destroyed.

With these primitives, we can build a quantum bill. We use the term “quantum bill”, originally introduced by Wiesner in his famous quantum money paper, as just a fancy way to describe a trivial verifiable one-time memory with memorized bitstrings of lenght zero. But please feel free to ignore the technical jargon if it sounds complicated!

Building quantum bills

Building a bill with the conceptual blocks highlighted above works like so: suppose you are the mint, or the issuance protocol, or whatever mechanism you want to use to issue money. You:

• Select $n$ pairs of random numbers. If you like math, we can denote these pairs as $(x_1,y_1), \dots, (x_n,y_n)$;
• Hash them and sign the hashes. Denoting our hash function with $H$, this gives us $\left(H(x_1),H(y_1)\right),$ $\dots,$ $\left(H(x_n),H(y_n)\right)$ and $\left(\sigma_{H(x_1)},\sigma_{H(y_1)}\right),$ $\dots,$ $\left(\sigma_{H(x_n)},\sigma_{H(y_n)}\right)$, where $\sigma_d$ denotes the signature on some piece of thata $d$ (in our case the hashes);
• Put each of your original pairs $(\sigma_{H(x_1)},\sigma_{H(y_1)})$ into an OTM, obtaining $\texttt{OTM}_1, \dots, \texttt{OTM}_n$.

That’s it! You don’t need anything more than that. Now you can take this bunch of data and give it to some happy spender.

Now suppose instead that you are said happy spender, and that you want to use this bill to pay some merchant. Said merchant wants indeed to be a happy merchant as well, and so he wants to verify that you are not scamming him with a fake bill. How does he do that?

• First, he verifies that the signatures over the hashes are authentic, that is, that the bill has been issued by a reputable source (the mint or whatnot).
• Then, the merchant selects $M < N$ OTMs at random and opens them on some random input. He will now verify that each input so obtained hashes to the corresponding signed hash provided with the bill.
• Finally, the merchant adds the opened inputs to data representing the bill.

Let’s see this again slowly, supposing that the merchant picks just one OTM — call it $i$ — among the bunch:

• Merchant verifies the signatures $\left(\sigma_{H(x_1)},\sigma_{H(y_1)}\right),$ $\dots,$ $\left(\sigma_{H(x_n)},\sigma_{H(y_n)}\right)$ against the hashes $\left(H(x_1),H(y_1)\right),$ $\dots,$ $\left(H(x_n),H(y_n)\right)$. If the signatures are correct, he goes on to the next step. Otherwise, he rejects the bill;
• Merchant opens $\texttt{OTM}_i$ on some random input: he flips a coin, and will read either $x_i$ or $y_i$ depending if he lands heads or tails;
• Suppose the merchant reads $x_i$; He now computes $H(x_i)$ and verifies that it coincides with the corresponding value among $\left(H(x_1),H(y_1)\right),$ $\dots,$ $\left(H(x_n),H(y_n)\right)$. If this holds, he goes on to the next step. Otherwise, he rejects the bill;
• The merchant accepts the bill. He removes $\texttt{OTM}_i$ from the data making up the bill — after all $\texttt{OTM}_i$ has been already opened, and by definition $y_i$ has been erased and will never be recoverable — and replaces it with $x_i$, the value he read.

Why this is secure

Now, let’s briefly cover why this protocol works. Suppose I am a malicious attacker. I own a bill, and I want to spend it twice. To do so, I need to copy it. The hashes $\left(H(x_1),H(y_1)\right),$ $\dots,$ $\left(H(x_n),H(y_n)\right)$ and their signatures $\left(\sigma_{H(x_1)},\sigma_{H(y_1)}\right),$ $\dots,$ $\left(\sigma_{H(x_n)},\sigma_{H(y_n)}\right)$ are copiable without problems, but the $\texttt{OTM}_i$ are not. Note that this is by definition: if an OTM was copiable, we could trivially extract both bitstrings from its memory by first making a copy, and then measuring each copy on a different bit.

Since I cannot copy any of the $\texttt{OTM}_i$s, I am forced to resort to tricks. I have no way to know both the bitstrings $x_i, y_i$ stored in $\texttt{OTM}_i$, but I can measure one of them, say $x_i$, and make the other one up, call it $y’_i$. I can now prepare $\texttt{OTM’}_i$, storing $x_i, y’_i$ within it. Since I know both $x_i$ and $y’_i$, I can make as many copies of $\texttt{OTM’}_i$ as I want by just preparing it multiple times.

Going back to our merchant, by following the protocol we realize that if some of the OTMs have already been opened and replaced with “fake” OTMs, this will be detected with overwhelming probability: if for instance $\texttt{OTM}_i$ was already opened, it could have returned $x_i$ if and only if the merchant chose to measure on the first bit. Otherwise, it would have returned $y’_i$, and $H(y’_i) \neq H(y_i)$ with overwhelming probability. So the merchant would have accepted the bill with only 50% probability. Iterate it over $k$ trials, and you see that the probability of passing the test when all OTMs have been opened is $\frac{1}{2^k}$. More generally — and I admit without shame that the last time I did combinatorics was probably in my 2nd year of uni — if $U$ OTMs are unopened, $O$ have already been opened and tampered with, and we choose $C$ OTMs at random, the probability of passing the verification should™ be:

where $\binom{n}{k}$ denotes the binomial coefficient.

Combinatorial estimates apart, as you may have already become aware, bills produced in this way can only be verified a finite number of times. At some point too many OTMs will have been opened, so that the amount of unopened OTMs remaining for verification will be too small for anyone to deem the bill secure. This means that after a while these bills need to be returned to the issuer to be renewed. This is akin to real currency, which degrades over time and at some point needs to be replaced, but as much as we like the nostalgic comparison, it is a problem we’re working hard to overcome.

Why quantum?

You may have noticed that the word “quantum” doesn’t really show up in the construction of our quantum bills. This is by design, as the only primitives we need are the ones reported above — hashes, signatures, OTMs. The point is that there is no classical way of producing one-time memories. We could obtain something similar using TEEs, with all the trust assumptions that this entails. On the other hand, we could use a mixture of conjugate-coding and TEEs to build OTMs — as we already did here, for instance. The reason why using quantum resources here is particularly appealing is that it allows to package OTMs that come endowed with a bunch of qubits that are absolutely needed to open them. As qubits cannot be copied, this entails that, pretty much because of physics™, you cannot duplicate OTMs. At best, you can choose between sending them to merchant or maliciously giving him opened/fake OTMs, but as we said this can be detected with overwhelming probability.

Can I play with this?

But of course!™ We implemented a proof-of-concept Rust library here. We abstracted the primitives used as Rust traits, so you are free to instantiate it with whatever crypto scheme you prefer. Clearly, if you want to use conjugate coding, you’ll need some quantum internet equipment to do so, but if you limit yourself to using TEEs (without any sort of quantum aid) then you should be fine with a much cheaper setup. We can’t wait to receive your feedback on this, so please open issues and PRs if you wanna contribute! We finally repeat once more that the paper can be found here, on the arXiv.

Yesterday we were invited to take part to the Stati Generali del Quantum – Italian for General States of Quantum – an initiative promoted by the Italian Government to present, promote and discuss the national strategy around quantum technologies. The event was a follow up to the Government roadmap already presented at Comolake in October and was highly institutional; in particular, the event was attended by some of the highest Government representatives. Among others:

• Alessio Butti, Undersecretary of State at the Presidency of the Council of Ministers with responsibility for Technological Innovation and Digital Transition, and main promoter of the Initiative;
• Guido Crosetto, Minister of Defense;
• Anna Maria Bernini, Minister of University and Research;
• Adolfo Urso, Minister of Enterprise and Made in Italy;
• Gilberto Pichetto Fratin, Minister of Environment and Energetic Security;

Representatives from all the main quantum computing players were also present, among others IonQ, Quantinuum, QuEra, IBM, together with a plethora of University researchers and VCs. The event was hosted at the Corsie Sistine in Santo Spirito, an incredible monumental complex once part of the Papal state.

The Italian Government strategy around quantum technologies is part of the broader EU strategy around quantum tech and rather comprehensive. Yesterday’s roadmap was articulated around four main axes: Quantum Computing, Quantum Simulation, Quantum Sensing and Quantum Communication. As NeverLocal, we were clearly interested in this last topic in particular, but we appreciated the comprehensive approach being adopted.

We were also very happy to see how the Italian Government is now going for a bottom-top, nimble approach here. The Italian Strategy revolves around trying to foster open collaboration between different ecosystem representatives, making also small and medium enterprises like our startup part of the conversation.

Lots has happened, but all in all the main take away point is that the Italian Government is looking at quantum technologies with great attention, and is eager to talk with people working in the ecosystem to understand how to best move.

Many more institutional appointments will follow, and we’ll make sure to keep you updated about it. In the meantime, if you want you can find the recordings of yesterday’s talks here (in Italian):

As the team is finally back from Argentina and has had a little time to recover, we’re ready to tell you how it was. First of all, I’d like to personally thank the EF and the Argentinian Eth community for the effort they put into this. I organize events in my spare time and I know very well how hard it is. For an event of this magnitude, the organizational effort is herculean, to say the least. So kudos!

Next, I want to spend just a few words about Argentina: It’s a great place, and I loved every aspect of it. One of the best perks is meat (if you are a meat lover of course), and the fact (at least for us) that it is conveniently located in the Southern Hemisphere, so if you want a bit of extra summer during the winter, it’s a great place to consider. Besides this, the city architecture is great, the people are great, and the crypto community is incredible. Indeed, we had the pleasure of meeting a lot of Argentina-based crews and companies and their technical expertise was absolutely world-class (yes, I’m looking at you Lambda Class!).

For what concerns us more closely, let me begin by saying that

A lot of pants are now getting pooped.

You heard me well. Many, many people, technical and not, are now legitimately scared of the quantum threat to Web3 and to Ethereum in particular. While I don’t generally like to see people scared or discombobulated by sad emotions, this is actually a good thing. It means the quantum risk to blockchain infra has finally been taken seriously, and it was about time!

We listened to various talks, especially from Ethereum Foundation folks, about this topic. Pretty much everyone kept saying that “Ethereum will be quantum safe in no time and there’s no real risk”, Vitalik included, on multiple occasions. Yet, when it came to discussing technical details, opinions were way more fragmented, and our general impression is that the EF internal roadmap to quantum resistance is not yet completely settled. Furthermore, several EF cryptographers kept downplaying the quantum risks to currently used cryptography. This is probably not optimal, but understandable: The EF, like everyone else, has only recently realize that this menace is real. The important thing is that the wind has changed, and I expect to see the Eth crowd aligned behind a tangible quantum plan within the next months.

Yet, this made us realize that

We need a failsafe.

I am quite confident that the Ethereum Foundation will manage to upgrade to quantum safety in time. Yet, the biggest blocker here is that they want to do it, comprehensibly, without sacrificing performance. This, primarily, is the reason why it will take them several years to implement all the needed upgrades. Estimates being circulated talked about ~2030 for the completion of the upgrade. And yet several people, Vitalik included, quoted the (by this point well known) warning by Scott Aaronson about quantum being possibly able to run Shor by 2028.

This, by itself, should be considered a big existential risk. If your roadmap takes longer to implement than the most optimistic estimates about quantum — which in this particular case come from probably the most esteemeed and corporate-neutral expert in the field — then we may have a problem.

Given our expertise in the field, we’ve been mulling for quite some time as of now about what we can do about this, and how we can help the Ecosystem. We set a two or three requirements for ourselves:

• We do not want to get into the EF way. The guys there are doing God’s work and we want to be able to offer complementary, and not overlapping, support.
• We want solutions which are applicable in a matter of months. If the EF is building an “endgame update” which doesn’t sacrifice performance but takes more time, we want to build a “failsafe switch upgrade” which sacrifices some performance but can be completely deployed by end of 2026.
• We want to be able to act independently to minimize “political discussions” and long-winded talks. So, our solution should not strictly depend on hard-forks.

Luckily enough, we have already a well-specced solution. I cannot say much more about it at this stage, but we’ve been thinking about it for months now and have already started core R&D. We used Devconnect to talk with key players — wallet providers, client developers, EF people — to explore the feasibility of our proposal, and the reception has been overwhelmingly positiive.

In a nutshell, you will hear much more about Ethereum safety from us in the future, and as usual, since we’re here to bring optimism and not despair, we can tell you that in a matter of months you’ll have a way to sleep safe.

Quantum money stays strong!

This said, we’ve also kept representing the most adventurous, wondrous side of Quantum. In our public talk — which you can find embedded at the end of the post — we gave once again our general vision of what quantum can do for cryptography, besides being an attack vector. As you can see, we got to speak to a full, engaged audience, and reactions were overwhelmingly positive.

All in all, Devconnect has been a fantastic experience, and I miss Buenos Aires (and its asado) already!

Here is the second part of our dialogues, inspired by transcripts of meetings held at NeverLocal by me and our communications specialist, Ionut Gaucan. The aim here is to introduce the main ideas behind the first quantum key distribution protocol that uses entanglement to establish secrecy: E91, introduced by Arthur Ekert in 1991. You can probably guess the pattern. You may think that too much attention is devoted to principles and too little to delving into the technicalities of the protocol. That is, until you realise that the cryptographic protocols under scrutiny are closely aligned with the foundational concepts we have been uncovering in this series of blog posts. It is therefore of paramount importance to introduce them and digest them first.

Nicola: Last time we spoke about the standard, fairly simple protocol called BB84, a key-distribution scheme that lets Alice and Bob share random binary strings.

Let us briefly reiterate. Alice takes a quantum system, a qubit, and encodes a locally generated random bit into one of four states: (0), (1), (+), or (−). The states (0) and (1) are the computational-basis states; (+) and (−) form a different basis that is maximally incompatible with the computational one. In our previous discussion I described these as different “perspectives”, “contexts”. Choosing a basis is like choosing a viewpoint from which to interrogate the same system.

So, Alice generates a random bit and encodes it by choosing one of the two bases and then the state representing 0 or 1 within that basis. There are, in effect, two ways to prepare and measure; many more exist in general, but with qubits two complementary bases already show the key idea.

Alice sends the physical system to Bob. Bob does not know which basis Alice used, so he chooses his measurement basis at random: either the computational basis or the (+/−) basis (orthogonal to the computational basis). At this stage, Alice has a random string (from her local randomness), and Bob has a random string (from the intrinsic randomness of quantum measurement). There is not yet the correlation they want, because sometimes Alice and Bob used incompatible bases.

After many rounds, they publicly announce which bases they used (not the outcomes). They then sift the data: they keep only the rounds where their bases matched and discard the rest. Those kept outcomes can be strongly correlated. One often says (0) and (1) are orthogonal (perfectly distinguishable) states, while (+) and (−) are orthogonal superpositions of (0) and (1) (phases matter in the maths, but that detail is not essential here).

The essential point is complementarity: you can choose two ways of observing the same system such that measuring in one way gives you no information about what you would have learned in the other. This guarantees that a malicious interceptor would break the maximal correlations that should be observed when both agents make the same choice of measurement.

Is that clear?

Ionut: So the basis mismatch is exactly what reveals an eavesdropper?

Nicola: Yes. Disturbance shows up as a reduction of the correlations in the matched-basis subset.

Ionut: Yes, in broad terms I think I get it.

Nicola: As I was explaining last time, this can be detected by making part of the key public.

Classical properties vs Contextual access

Nicola: This already shows a basic difference between classical and quantum systems. In classical physics, a system is described by definite properties: colour, size, shape, or, in mechanics, position and momentum. In quantum theory, objects do not have predefined properties; they gain definite values only upon measurement, or, more precisely, in virtue of our choice to measure them.
And when you measure one observable precisely, you forfeit information about a complementary one. That is the content of the Heisenberg uncertainty principle.

Our discussion is a discrete version of that story: with qubits, measurement outcomes are 0 or 1 rather than continuous values.

Ionut: So “property” in the classical sense means stability under interrogation?

Nicola: This is a very good question, one that is impossible to answer in a fully satisfactory way. It is, however, possible to make intuitive sense of it. Classicality, in some sense, is what remains stable under our interaction with nature. Imagine observing the world by laying down a net, a loose-threaded tapestry. The reality that filters through the loose threads, the mesh, is, of course, mesh-shaped itself: we lose the ability to perceive all the details that would form a seamless reality.

Using a different net, a different mesh, reveals facts compatible with this new perspective. We can try to fill in the invisible spots, to reconstruct continuity by introducing “hidden patterns”, “hidden variables”, and for any single net this works fine. It is when we use a different net that the structure we postulated for one becomes incompatible with what is shown through the mesh of the other.

So what, then, is classicality? It is impossible to answer definitively, though many physicists almost obsessively try, rather hopelessly in my opinion. Providing a description of the various pieces of the natural world that can be juxtaposed in ways compatible with the net’s “negative space” seems difficult. Not many people have taken the discussion about “classicality” seriously in the study of quantum foundations.

The nets themselves, however, the logical structures that at any time form the context of all the possible coexisting, commensurable properties, have a very specific structure. But it is a logical structure, a formal structure, one that is difficult to anchor to specific elements of what we call the real.

Ionut: Why are we talking about the foundational aspect of the theory? Cryptography is about a very concrete task; are we not muddying the waters?

Nicola: You are absolutely right to be sceptical; however, the strangeness of quantum mechanics has important empirical consequences. There are two options at this point. We can mystify everything in the quantum formalism, embrace it, and shut everything down by quoting Feynman: “Nobody understands quantum mechanics.”

I am more interested in the alternative of understanding quantum phenomena by explaining and discovering patterns using only the empirical, probabilistic part of the theory, by trying to make use of stable, verifiable aspects of the correlations obtained by the theory to give meaning to many of its counterintuitive aspects.

Cryptography is, in this regard, one of the most important places where we can put this idea about foundations into practice. Explaining quantum mysteries from this theory-independent perspective becomes exactly what is needed to understand how correlations and data can guarantee the type of security that quantum cryptography promises.

Ionut: I think I have an intuition about the difference between quantum and classical information at this stage. We still need to talk about entanglement, though.

Correlation and Entanglement

Nicola: Exactly. Let’s move to today’s topic: entanglement, which empowers most current cryptographic protocols. It is sometimes misunderstood as either “just correlation” or as “magical faster-than-light communication”. It is neither. It is a kind of non-classical correlation. It does not enable superluminal signalling, but it goes beyond classical explanations.
Often described as spooky action at a distance, it is not more spooky than the phenomenon that underlies all of quantum mysteries, the very subject of our previous discussion on BB84.

A classical analogy helps. Imagine I tear a playing card in half, seal each half in an envelope, and give one to Alice and one to Bob. The card could be red or black. If Alice opens her envelope and sees “red”, she immediately knows Bob’s half is “red” as well. That is a classical correlated preparation.

Last time I spoke about the fact that quantum systems are not defined by properties in the classical sense; rather, it is better to think in terms of the different ways we can access them, how we encode and decode classical information. We also saw that this process is not as innocent as it seems: it entails making choices that sometimes completely erase what could have been learned about a complementary observable.

Ionut: If properties are not predetermined, I suspect there will be problems in defining them as “being correlated”.

Nicola: Right, so how does this reflect on the correlation side? If quantum systems are not defined by definite properties and must be described operationally, what is the counterpart of being “correlated” in the quantum world? Suddenly this operational characterisation gives us more room: a larger set of potentially compatible behaviours. Let us single out two perspectives, two observables, for each subsystem, called $a_0$ and $a_1$ for subsystem $A$, and $b_0$ and $b_1$ for subsystem $B$. Then, keeping the operational view in mind, the possible outcomes, including the correlations, form a table of probabilities:

Ionut: So we have classical and quantum behaviours that can be described using these conditional-probability tables?

Nicola: Yes, here is an entirely classical behaviour, not very dissimilar from the previous example:

So what unites these two behaviours? Evidently, many things. A subtle and important aspect is witnessed by the no-signalling property. In both cases, if we consider the marginal probabilities, (the single-party distributions obtained by summing the joint table over the other party’s outcomes) describing the individual local behaviours and ignore the correlations, they are independent of the choice of measurement performed on the other subsystem.

What they do not have in common is this: one of the two tables can be obtained as a statistical mixture of deterministic behaviours, while the other cannot. Only one can be explained by an underlying deterministic mechanism obscured by randomness. In the classical case this counterfactual mechanism always arises from properties that exist prior to and independent of measurement, merely revealed at the moment of measurement.

In quantum mechanics, by contrast, we can prepare systems where certain properties do not have predetermined values before measurement, and yet measurement results are correlated. That is entanglement in a nutshell: correlations without pre-existing local values.

Ionut: So where does this leave cryptography? How do these correlations become a key?

Nicola: Well, the entangled, non-classical behaviour we showed earlier necessitates certain patterns of correlation between the measurement outcomes. These establish the shared key.

To sharpen the classical comparison, take cards with two attributes: colour (red/black) and suit (hearts, diamonds, clubs, spades). Pretend Alice and Bob can choose to “measure” either colour or suit. To keep it binary, group the suits into two classes (say, diamonds+spades vs hearts+clubs). If Alice and Bob always check the same attribute (both colour or both suit), their outcomes are perfectly correlated because they hold halves of the same card. If they check different attributes, the results need not be correlated in any systematic way. This is a classical system that already yields a family of conditional probabilities depending on the chosen “measurement”, but it cannot reproduce certain quantum correlations. That gap, what quantum correlations can do that classical ones cannot, is what entanglement reveals and what Bell’s theorem formalises.

Entanglement to certify security: Eckert 1991

Ionut: How is entanglement used for cryptographic protocols?

Nicola:Imagine Eve prepares a long sequence of cards at random, each independently red or black with probability one-half, tears each card in two, and distributes matching halves to Alice and Bob. If they later compare notes in order, they find perfect correlations on the pairs where they “measured” the same property, colour in this case. Over many trials, the joint outcomes concentrate on the perfectly correlated pairs (red-red and black-black), each with probability one-half. Eve will also share the same information.

So in these classical cases the correlations possessed by the two agents can be effectively shared with Eve as well. The correaltions made possible by entanglement prevent the observed correlations from having a similar totally classical source, a source that can be copied and broadcast by an eavesdropper.

Arthur Ekert in 1991 proposed a protocol now known as E91. Instead of single systems sent from Alice to Bob, there is a source of entangled pairs. One particle from each pair goes to Alice and the other to Bob. The source need not be trusted. On every round, each party chooses a measurement setting at random. When the settings are effectively aligned, the outcomes are strongly correlated; those data are sifted to form the raw key. When the settings are deliberately misaligned, the data are used as a test sample. From that sample, Alice and Bob estimate whether the observed pattern of correlations exceeds a classical bound. If it does not, the data admit a classical explanation and the run is discarded. If it does, the experiment itself serves as a verification that the correlations arise from entanglement rather than from pre-existing local values.

Ionut: So the test is the part that rules out hidden variables?

Nicola: After verification, they reconcile small discrepancies due to noise and then apply privacy amplification to reduce any information potentially available to an eavesdropper. The amount of compression is chosen according to the strength of the test. In this way, verification precedes trust. The protocol does not rely on secrecy of the devices or on assumptions about the source; it relies on the observed structure of correlations. This is the practical link between E91 and entanglement verification: the same experiment that generates correlated bits also checks that those bits could not have been produced by a classical hidden-variable model.

Ionut: To conclude, can we synthesise by saying that Ekert’s protocol, by certifying non-locality, also certifies the secrecy of some of the correlated outcomes; is that correct?

Nicola: This is an interesting point. Ekert’s protocol is not dissimilar to modern device-independent quantum key distribution (DIQKD, for short). What prevents it from being DIQKD is the nature of its security proof. Security is not guaranteed by the correlations themselves but by the knowledge that certain correlations must be produced by particular kinds of quantum resources. It therefore depends on the assumption that the devices behave in a certain way, at the very least, that they probe a quantum system of a particular “dimensionality,” of a certain size. As such, it cannot be said to be fully device-independent. To prove device-independent security, the relationship between an eavesdropper’s maximal knowledge and contextual/non-local correlations has to be established in a fully device-independent framework. We have already hinted at the reason, but many of the pieces still need to find their correct place in the narrative.

The problem here is similar to saying that no-cloning guarantees security. That is certainly true in principle, but it relies on the belief that the protocol probes a certain type of quantum system. It is a very different matter to prove, from correlations, that something contextual is happening and therefore that a non-classical description is a logical necessity which, as a consequence, would satisfy a form of no-cloning. We can even bypass no-cloning altogether and describe its embodiment in the purest empirical way, through the principle of the monogamy of non-locality. But this is a great deal of material, enough for our next discussion.

At Lugano Plan B 2025, amid the polished optimism of Bitcoin evangelism, one panel cut through the noise with a dose of existential realism. Moderated by Preston Pysh, “Bitcoin and the Quantum Threat” gathered Jameson Lopp, Brad Mills, Mohamed Allam, and Hunter Beast to confront a question few want to dwell on: What happens when quantum computing becomes real enough to break Bitcoin?

How Soon Is Quantum “Soon”?

Timelines dominated the conversation, and consensus was elusive. Hunter Beast warned that Bitcoin might have two to three years to act before hardware progress and Shor’s algorithm optimisations make today’s Elliptic Curve Cryptography (ECC) vulnerable to attack. Mohamed Allam’s lens was economic — he predicted that venture capital would pivot from the AI boom to quantum startups within the same time frame, accelerating development once the current hype cycle bursts.

Jameson Lopp offered a more tempered view: a decade or more before cryptographically relevant machines exist. Yet his caution carried a sting — if the timeline proves shorter than five years, Bitcoin’s governance machinery likely won’t react in time. Brad Mills, speaking as the market’s conscience, drew a parallel to the block-size wars: the debate may seem academic, but delay invites chaos. “The time to start is now” became the unspoken refrain.

The Math Behind the Fear

For most of Bitcoin’s history, “quantum risk” lived in the same drawer as “asteroid impact.” But the panel unpacked it in concrete terms. The real measure isn’t the number of physical qubits, but logical qubits — error-corrected units that can actually execute Shor’s algorithm to derive private keys from public ones. Optimisations are shrinking those requirements faster than most assume, though some of the most hyped technologies, such as “topological qubits”, remain mostly speculative.

The immediate danger lies not in future blocks, but in old coins. Bitcoin’s UTXOs reveal their public keys only when spent. Addresses using pay-to-public-key (P2PK) or reusing addresses are exposed; pay-to-public-key-hash (P2PKH) addresses are safe until their first spend. Around six million BTC are already public-key–revealed, much of it held by exchanges. Roughly 1.7 million BTC appear abandoned — tens of thousands of addresses holding about 50 BTC each, inert but visible targets for the first quantum adversary. Some joked about a “Satoshi bounty,” where lost coins might serve as a sacrificial buffer for the rest.

Choosing a Quantum-Resistant Future

Even if Bitcoin agreed on a fix tomorrow, migrating would be a logistical feat. Larger post-quantum (PQ) signatures bloat transactions, straining Bitcoin’s already tight block space. A full-scale key rotation could take months or years, depending on network throughput and user participation. And as several panelists noted, most users are reactive — they won’t move until after an exploit hits the headlines.

The cryptographic menu isn’t simple. Hash-based schemes like SPHINCS+ are battle-tested but produce signatures measured in kilobytes and lack convenient key derivation. Lattice-based alternatives such as Dilithium are smaller and faster but add verification overhead and untested complexity. Either way, every extra byte of data matters on Bitcoin’s fee market.

Hunter Beast outlined BIP-360, a proposal to embed PQ signature options within Taproot’s script paths, allowing users to choose a quantum-resistant spend route. But code is only half the battle — hardware wallets, libraries, and custodians all need to upgrade in sync. Lopp complemented this with a focus on policy and incentives, arguing that without coordinated economics, even the best BIP could languish unused.

Money, Incentives, and Apathy

Among the most controversial suggestions was a cut-off date — a point after which quantum-vulnerable coins could no longer be spent. Lopp argued that such a rule might be the only way to force migration before catastrophe. Yet it would clash with Bitcoin’s cardinal ethos: “Don’t touch other people’s coins”. The moral calculus is brutal — either break that taboo or risk mass theft once a quantum adversary arrives.

The asymmetry is glaring. Billions flow into quantum hardware research; Bitcoin’s quantum defence efforts are almost unfunded. Institutional custodians and ETFs may eventually act to protect balance sheets — perhaps even supporting the invalidation of vulnerable UTXOs — but that approach may alienate Bitcoin’s cypherpunk roots. Meanwhile, markets won’t wait for clarity: even rumours of a working quantum attack could trigger panic selling long before any mitigation is live.

The panel closed on a sober truth: Bitcoin’s strength — its resistance to change — is also its greatest vulnerability. Every meaningful upgrade takes years of consensus-building, wallet updates, and communication. Success demands not just a BIP, but a campaign: standardisation, testing, user education, and perhaps uncomfortable compromise.

No one on stage believed the sky was falling tomorrow. But the message was unmistakable: the time to prepare is before the sirens sound. Bitcoin’s next great test may not be ideological or regulatory — it may be quantum. And when that day comes, the network will need more than math. It will need coordination, courage, and time — three things the panel agreed are in dangerously short supply.