How Quantum Technologies Threaten Cryptocurrencies — And is TON Ready for Them?

Over the past decades, digital security has been based on the fundamental properties of classical mathematics — tasks that are extremely difficult for modern computers to solve. This is what cryptography is based on, protecting the internet, banking transactions and, of course, blockchain networks. But with the development of quantum technologies, this balance is beginning to shift.

Quantum computers are a fundamentally different way of processing information. Their potential lies in their ability to solve problems that were considered virtually impossible for classical computers. And although large-scale quantum computing infrastructure is still a matter of the future, the technological vector has already been defined. International standardizers, major cryptographic laboratories and blockchain communities around the world are increasingly discussing how to change the foundation of digital security before the quantum moment arrives.

For blockchains, this topic is particularly sensitive. Signatures, hashes, multi-signature schemes — all could be vulnerable in an era of sustained quantum attacks. While the exact scale of the threat has yet to be determined, one thing is already clear: Preparations must begin long before the threat becomes real.

The Open Network is one of the few blockchains that already has cryptographic flexibility built into its architecture. This sets the stage for future adaptations, including the potential integration of post-quantum algorithms. In this article, we'll explore what exactly is threatening classical cryptography, how the industry is responding, and what properties of TONs allow us to look to the quantum future with confidence.

What exactly is threatening cryptography?

Digital cryptography, on which blockchains are built, has long been considered virtually invulnerable due to its mathematical rigor. But with the advent of quantum computing, key cryptographic challenges — those protecting signatures, addresses, and contracts — are losing their former robustness. Two classes of algorithms are particularly vulnerable: those that provide transaction signatures and those that form the structural integrity of the network.

Shor's algorithm: a risk to digital signatures

In 1994, American mathematician Peter Shore proposed an algorithm that could efficiently solve factorization and discrete logarithm problems, the two mathematical problems on which most digital signatures are based. This applies to algorithms such as RSA, ECDSA, EdDSA, and secp256k1, which underlie cryptocurrency wallets, validator systems, and multisignatures.

Whereas a classical computer has to pick keys by brute force, a quantum system using Shor's algorithm can recover a private key knowing only the public key. This jeopardizes any address from which a transaction has already been signed — the vast majority of such addresses in most blockchains.

Grover's algorithm: pressure on hashes and symmetry

Hash functions (like SHA-256 or SHA-3) are used everywhere in blockchains, from building Merkle trees to mining and proving data integrity. Grover's quantum algorithm does not allow to completely crack such functions, but it speeds up the brute-force process by half, reducing the level of their persistence.

Thus, the protection that previously provided 256-bit resilience is equivalent to only 128-bit in the quantum scenario. This is still a serious level of protection, but it may not be enough in the long run.

Infographic. The Quantum Threat to Cryptocurrencies: A Roadmap from Problem to Solution

Left panel shows quantum computing with exponential processing speed and Shor's algorithm capable of breaking RSA and elliptic curve cryptography (ECC). Right panel depicts the current state of cryptocurrencies: blockchain-based distributed ledgers protected by classical public-key cryptography and digital signatures that prove ownership. Center highlights the critical fork: either the threat materializes (decryption of private keys if unaddressed), or the industry successfully migrates to post-quantum cryptography (PQC) — quantum-resistant algorithms standardized by NIST. Bottom center shows the future outlook: evolution of secure protocols through transition to quantum-safe standards.

Harvest now, decrypt later

One of the least obvious but strategically dangerous scenarios is the so-called harvest now, decrypt later approach. An attacker could save all public keys, encrypted messages or metadata recorded today and simply wait for quantum computing to reach the right level.

Figure 1. Growing Consensus: When Does the Quantum Threat Become Real?

A survey of 32 leading quantum computing experts reveals how risk assessments evolve over time. The dashed line at 30% probability separates skeptics (yellow zone below) from those who consider the threat substantial (red-orange zone above). Key insight: by the 10-year mark (2034), the red zone surpasses the yellow — meaning a majority of experts consider the emergence of a cryptographically relevant quantum computer (CRQC) more likely than not.

Source: Global Risk Institute, Quantum Threat Timeline Report 2024

As the chart shows, the window for harvest-now-decrypt-later attacks may close faster than many anticipate. Even conservative estimates point to substantial risk within the next decade. This means that public keys and transactions recorded today on blockchains like TON, Bitcoin, or Ethereum could be exploited retroactively — long before users recognize the threat or manage to migrate to post-quantum algorithms.

Vulnerable elements in blockchains

Blockchains, as decentralized systems, are particularly susceptible to these kinds of threats. Among the most susceptible components:

While the quantum threat remains theoretical for now, the scale of the consequences could be serious — and requires technical preparedness now.

How the industry is responding to the quantum threat

Although a large-scale quantum computer has yet to be built, the cryptographic community has been systematically preparing for the consequences of its arrival for several years. This direction has been called* Post* -Quantum Cryptography (PQC). Its goal is to create schemes that are resistant to quantum attacks but compatible with existing digital infrastructures.

NIST Initiative: Next Generation Global Standard

The US National Institute of Standards and Technology (NIST) plays a leading role in shaping PQC standards. In 2016, it initiated an open competition to develop and test new cryptographic algorithms that are resistant to the Shor and Grover algorithms. The competition attracted scientists and engineers from around the world, including teams from Google, IBM, the University of Lausanne, the ETH Zürich Center for Quantum Information, and others.

In 2022, NIST announced the first final candidates:

For digital signatures: CRYSTALS-Dilithium, Falcon, SPHINCS+;
For key exchange: CRYSTALS-Kyber (being implemented as a NIST PQC KEM standard). The algorithms are based on mathematics different from that used in ECDSA and RSA. The algorithms are based mainly on solving vector problems in lattices, which are considered to be resistant to quantum attacks.

These algorithms have already started to be implemented in projects of large companies: Google is testing Kyber in Chrome's TLS sessions, Microsoft is integrating PQC into Azure VPN, and Signal is considering SPHINCS+ as an additional layer for long-term protection.

Crypto projects' reactions: from experiments to strategies

Reactions in the blockchain industry are unevenly distributed. Some projects are publishing research and experiments, while others are betting on architectural flexibility and migratability.

Bitcoin

Bitcoin uses the ECDSA scheme on the secp256k1 curve — one of the most vulnerable in the quantum context. Discussions about possible migration are ongoing in the dev community: hybrid signatures (classical + PQC), new address formats and changing signature algorithms are being considered. However, due to the complexity of management and lack of a formal team, implementation will be extremely slow.

Ethereum

Ethereum uses the ECDSA scheme, but also supports EdDSA and is experimenting with signature abstraction. Ethereum Foundation researchers are already analyzing how Falcon and Dilithium can be integrated into wallets and contract schemes.

Polkadot, Algorand, Cardano

These networks were originally designed with a more modular architecture. Polkadot is discussing the possibility of creating separate parachains with PQC. Algorand has published research on SPHINCS+ integration. Cardano is considering hybrid schemes with Ed25519 replacement.

What's important for a successful migration

The following conditions are needed for a blockchain to adapt to PQC:

Cryptographic flexibility — the ability to change signature and hash algorithms without completely rebuilding the network.
Upgradability of system contracts and wallets — so that users can migrate to new schemes without losing funds.
Flexible consensus architecture — so that validators can safely switch to new keys.
**Understanding UX and signature weighting **— Some PQC schemes (e.g. SPHINCS+) have signatures as small as 40 kilobytes. This may require architectural compromises.

TON, as we will see next, has several of these qualities already — due to the specifics of its structure and approach to cryptography.

TON's architecture and cryptographic flexibility

TON occupies a special place in the blockchain network landscape — not only because of its scalability or high throughput, but also because of its unique level of structural flexibility. This feature may prove particularly important in the face of the impending quantum transition.

From the outset, The Open Network has been designed as a modular and evolutionary system. Its basic principles — a multichain architecture, updatable system contracts, and abstracted cryptographic primitives - form the technical foundation upon which cryptographic migration can potentially be realized.

Signatures in TON: programmable and replaceable

Unlike most blockchains, where wallet logic is hardwired into the protocol, in TON wallets are implemented as smart contracts. This means that the user can choose a signature scheme, implement the logic in code, and update the contract if necessary. There are already wallets based on different algorithms: from simple Ed25519 to multi-signature designs with custom logic.

In addition, the very structure of transactions in TON allows the use of nested signatures, opening up opportunities for hybrid schemes — for example, where a transaction is simultaneously signed with a classical and a post-quantum key.

This flexibility opens up space for advanced security models. For example, it is possible to implement a scheme similar to two-factor authentication: a transaction is confirmed not only by a classical signature, but also by an additional factor - for example, a signature from a post-quantum key, a call to an external module, or a response to a challenge-response. Such a design is already possible within the TON framework, without protocol changes and with minimal impact on the UX.

Such schemes are especially relevant in the transition period, when classical cryptography is still in widespread use, but the quantum threat is already taken seriously. This approach allows you to "grow" protection on top of the usual model — and thus protect sensitive assets without the need for mass migration or forced updates.

System Component Updatability

TON uses a centralized-decentralized protocol update model: network parameters, allowed algorithms and key contracts are regulated through masterchain configuration. This ensures a high speed of change implementation - including those related to cryptographic rules.

System contracts (including those controlling gas, addressing, underlying wallets) can be replaced with new versions without destroying backward compatibility. This model, unlike, for example, Bitcoin, does not require heavy forks or massive community coordination.

Workchains as a space for experimentation

The TON architecture allows for the existence of parallel workchains, each of which can use its — including an address scheme, signature algorithms, and even a consensus model. This means that post-quantum migration can be realized first within a new workchain, without risking the underlying network.

A possible scenario in which:

**A) **a PQC workchain is created;

B) sensitive contracts and wallets are migrated there;

C) users gradually migrate to the new schemes.

This significantly lowers the barriers to adoption: users get to try out post-quantum technologies in a sandbox without losing access to the core functions of the ecosystem.

From Telegram to the user

One cannot ignore the role of Telegram in the context of TON. Updates to wallets, keys, or signature methods can be implemented not only at the network level, but also through the user interface to which TON has unique access. This simplifies one of the most challenging aspects of crypto migration — interacting with millions of users.

Signature updates via Telegram Wallet can be implemented as a standard procedure — with prompts, confirmation and full follow-up. This level of UX power is not available to most other blockchains.

TON Virtual Machine and crypto abstraction

TON uses a proprietary virtual machine (TVM) that is different from the EVM. It focuses on compact bytecode, a strict logic model, and support for arbitrary data types. This means that developers can implement virtually any cryptographic scheme — given the tools — without limitations on the interpreter side.

In addition, the TVM Accelerator project, launched in 2024, has made it easier to work with external cryptographic libraries, increasing computational speed and opening the way to complex algorithms in contracts.

These architectural properties of TON don't mean that post-quantum security is already implemented - but they make it clear that the path to it is technically open. For a blockchain system, this is a rare and strategically important groundwork.

Vulnerability and resilience: what TON looks like from a quantum security perspective

Even with a high degree of cryptographic flexibility, TON - like other modern blockchains - uses classical algorithms at its core. This means that it inherits both the strengths of traditional cryptography and its potential weaknesses in a quantum context. To make a sober assessment of how prepared a network is for a possible quantum-scale attack, it is important to consider not only the protocol, but also the usage practices.

Algorithms in use and potential attack vectors

At the time of publication, most key wallets and system contracts in TON use Ed25519, which is a fast and efficient elliptic cryptography algorithm used in multiple blockchains and messengers (including Telegram, Signal, and Monero). It provides excellent security against classical attacks, but is not resistant to Shor's algorithm.

Consequently, if a quantum computer capable of efficiently executing this algorithm becomes available, users' public keys published on the network can be used to recover private keys — and thus steal funds.

Key reuse

As in many other networks, TON often uses the same address for many transactions. Although the protocol does not prohibit one-time addresses, reuse is prevalent in user practice - especially when dealing with centralized services, NFT wallets, and decentralized applications.

This reinforces the "harvest now, decrypt later" scenario : public keys and transactions are already in the public domain and can be mass-collected. With the advent of quantum computing of appropriate power, this data can be used to backdoor hack and re-sign old transactions.

Smart contracts and key interactions

TON contracts typically do not store keys directly, but often rely on signatures and invocations verified through standard libraries. Implementing new schemes will require, at a minimum, updates to wallets, and in some cases, changes to contract logic. However, the TON architecture allows to do this without forking, through the deployment of new contracts and the upgradeability mechanism implemented in many system templates.