Toncoin TON

Claim: TON uses Ed25519 as the standard signature scheme for all wallets (v1–v5) and highload wallets. No PQC or hybrid signature support exists on mainnet.

Coverage basis: Ed25519-only spend authorization; no PQ/hybrid path

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization is Ed25519-only. Shor's algorithm can recover private keys from any on-chain public key.

Assurance: Official TON documentation confirms Ed25519 as the exclusive signature scheme. Source code corroborates. No PQC or hybrid alternatives documented.

Ed25519 is a Schnorr-style signature over the Edwards curve. It provides ~128-bit classical security but is fully broken by a CRQC running Shor's algorithm.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://docs.ton.org/develop/smart-contracts/guidelines/ed25519
• https://github.com/ton-blockchain/ton

Claim: TON public keys become available on-chain after a wallet is initialized (sends at least one transaction). Wallet deployment requires passing the 256-bit Ed25519 public key as an initial contract parameter.

Coverage basis: Long-exposure quantum-vulnerable ownership paths for all transacting wallets

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Public keys are permanently exposed on-chain for all wallets that have sent transactions, enabling offline quantum key-recovery attacks.

Assurance: Multiple independent sources confirm public-key exposure pattern. Official docs confirm wallet deployment embeds public key.

Uninitialized wallets (never sent a transaction) do not have exposed public keys and are temporarily safer, but any future transaction will expose the key.

• https://docs.ton.org/develop/smart-contracts/guidelines/ed25519
• https://www.binance.com/en/square/post/12184000000000
• https://bmic.ai/research/toncoin-quantum-vulnerability

Claim: TON's Catchain BFT consensus relies on Ed25519 validator signatures for block finality. Validators produce CommitSign and PreCommit signatures verified during consensus.

Coverage basis: Ed25519-only validator authentication

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Validator signatures are Ed25519-only. Quantum signature forgery could compromise consensus finality and enable double-spend attacks.

Assurance: The Catchain whitepaper describes the consensus protocol. The Medium article explicitly confirms Ed25519 for validator signatures.

The TON Trustless Bridge document discusses that Ed25519 signatures cannot be non-interactively aggregated (unlike BLS), and notes that validators use Ed25519 private keys for block signing.

• https://docs.ton.org/blockchain-basics/whitepapers/catchain
• https://medium.com/@ducphamle212/verifying-tons-masterchain-blocks-part-2-ton-hack-series-38a88a845918

Claim: TON uses Merkle proofs (SHA-256) for state integrity, block hashing, and data availability. No KZG/pairing-based commitments are used for base-layer state integrity.

Coverage basis: Hash-based state integrity satisfied by design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Official TON documentation extensively describes Merkle proof structures for state verification.

While SHA-256 is quantum-safe for collision resistance, Grover's algorithm provides a quadratic speedup (256→128 bit security). This is adequate for state-integrity commitments in practical terms.

• https://docs.ton.org/blockchain-basics/primitives/proofs/overview
• https://docs.ton.org/blockchain-basics/whitepapers/tblkch

Claim: TON does not have built-in privacy features (no shielded transactions, no ZK proof layer for base-chain privacy).

Coverage basis: No privacy layer exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

TVM supports BLS12-381 pairings which could enable ZK constructions at the application layer, but these are not part of the base protocol's privacy architecture.

• https://docs.ton.org
• https://github.com/ton-blockchain/ton

Claim: TON uses ADNL (Abstract Datagram Network Layer) for P2P communication. Node identity is tied to Ed25519 keys.

Coverage basis: Ed25519-based P2P node identity

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2P node identity is linked to validator identity in TON's architecture. While P2P compromise alone does not directly enable asset theft, it could facilitate eclipse attacks or consensus disruption.

ADNL uses Ed25519 for node identity. The P2P layer is less directly asset-critical than spend authorization or consensus, but its quantum vulnerability compounds other risks.

• https://docs.ton.org/blockchain-basics/whitepapers/catchain
• https://github.com/ton-blockchain/ton

Claim: No production PQ/hybrid wallet path exists. All wallet software, custody solutions, and signing tools use Ed25519 exclusively.

Coverage basis: No PQ/hybrid wallet support

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: All official TON wallet documentation references Ed25519 exclusively. No hardware wallet or HSM vendor has announced PQC support for TON.

The absence of PQ wallet paths is a direct consequence of TON having no PQ signature support at the protocol level.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://docs.ton.org/develop/smart-contracts/guidelines/ed25519

Claim: TON's official documentation inventories Ed25519 as the standard signature scheme for wallets and implicitly for validators. No quantum threat model has been published by the TON Foundation.

Coverage basis: Partial inventory exists; no quantum threat model

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The cryptographic inventory (Ed25519 for wallets, Ed25519 for validators, SHA-256 for hashing) is well-documented in official sources. However, no quantum threat model covering attack assumptions, affected assets, and affected layers has been published by the TON Foundation.

Score of 0.25 reflects that the cryptographic inventory exists (partial credit) but no quantum threat model or Foundation-published risk assessment exists.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://docs.ton.org/develop/smart-contracts/guidelines/ed25519
• https://ton.app/journal/guide/how-quantum-technologies-threaten-cryptocurrencies-and-is-ton-ready-for-them

Claim: TON's open-source code, official documentation, and ecosystem audits provide a verifiable evidence base for the cryptographic inventory, but no quantum-specific evidence record has been published by the project.

Coverage basis: General evidence exists; no quantum-specific evidence record

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Open-source code and official docs provide good evidence for classical cryptography. Existing audits (CertiK, HashEx) do not cover quantum-critical scope.

Score of 0.25 reflects that general evidence exists (code, docs, audits) but no quantum-focused evidence record has been compiled by the project.

• https://github.com/ton-blockchain/ton
• https://docs.ton.org/v3/concepts/security-measures
• https://docs.ton.org

Claim: Approximately 0% of TON's circulating supply is protected from quantum key-recovery attacks. All active wallets use Ed25519 with exposed public keys.

Coverage basis: <25% coverage — experimental/negligible protection

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path. Readiness & Risk Cap of 55 applies.

Assurance: Exact percentage of supply in uninitialized (safe) vs initialized (vulnerable) wallets is not publicly measured. BMIC research estimates a significant percentage of total supply has exposed public keys.

Uninitialized wallets (never sent a transaction) do not have exposed public keys and represent the only quantum-safe TON holdings. However, these wallets cannot be used without exposing their keys.

• https://bmic.ai/research/toncoin-quantum-vulnerability
• https://docs.ton.org/develop/smart-contracts/guidelines/ed25519

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to or protected by PQC or hybrid signatures.

Coverage basis: No critical wallet migration

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No evidence of any critical wallet migration exists. The TON roadmap makes no mention of PQC migration.

Foundation treasuries, exchange wallets, bridge contracts, and major DeFi protocols on TON all rely on Ed25519 signatures.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://ton.org/roadmap

Claim: No public identification, measurement, deprecation, migration, freeze, or burn of quantum-vulnerable legacy pools exists.

Coverage basis: No legacy pool identification or management

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No quantum-vulnerable pool identification, measurement methodology, or management policy has been published.

TON does not have UTXOs in the Bitcoin sense, but the concept applies to wallet contracts with exposed public keys.

• https://ton.org/roadmap
• https://docs.ton.org

Claim: The official TON roadmap (ton.org/roadmap) through 2026 contains no mention of post-quantum cryptography, quantum migration, or cryptographic upgrades.

Coverage basis: No quantum migration roadmap

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The official TON roadmap for 2024–2026 details Wallet 5.0, L2 payment networks, and a new TON consensus mechanism, but contains zero references to post-quantum cryptography.

The ton.app community article discusses TON's architectural flexibility for future PQC adoption but this is not an official roadmap or commitment.

• https://ton.org/roadmap

Claim: No PQ/hybrid account creation, wallet tooling, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: No migration accessibility

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: All wallet creation flows, SDKs, and documentation reference Ed25519 exclusively.

TON's wallet-as-smart-contract architecture theoretically allows users to deploy wallets with custom signature schemes, but this capability is not supported by any standard tooling or documentation for PQC.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://ton.org/roadmap

Claim: No enforcement mechanisms exist for quantum migration. There are no deprecation timelines, legacy signing disablement, withdrawal restrictions, or mandatory migration deadlines.

Coverage basis: No enforcement mechanisms

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No exchange, custody, bridge, wallet, or infrastructure coordination for quantum migration has been identified.

TON's governance model (masterchain configuration parameters updated via validator consensus) could theoretically enable rapid cryptographic upgrades, but no quantum-specific governance process has been established.

• https://ton.org/roadmap

Claim: No quantum-specific emergency disclosure process, incident-response playbook, or governance mechanism has been published.

Coverage basis: No quantum-specific emergency process

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: TON has a general security measures page listing audits and bug bounty programs, but no quantum-specific vulnerability disclosure or emergency response process is documented.

General security processes exist but are not adapted for quantum-specific threats which have fundamentally different characteristics.

• https://docs.ton.org/v3/concepts/security-measures

Claim: TON does not use any PQC or hybrid-PQC algorithms in production. All critical cryptography is classical Ed25519.

Coverage basis: No PQC algorithms deployed

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Official documentation and source code confirm exclusive use of Ed25519. No NIST PQC algorithms (ML-DSA/Dilithium, SLH-DSA/SPHINCS+, FN-DSA/Falcon) are referenced.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing
• https://github.com/ton-blockchain/ton

Claim: Multiple security audits exist for TON smart contracts and ecosystem components (CertiK, HashEx), but none address post-quantum properties, quantum migration, or quantum-critical cryptographic review.

Coverage basis: Audits exist but are scope-mismatched for quantum readiness

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Existing audits provide general smart-contract security assurance but are scope-mismatched for quantum readiness.

This subfactor is scored at 0.00 because no quantum-critical audit exists.

• https://docs.ton.org/v3/concepts/security-measures
• https://www.certik.com/ecosystems/ton
• https://hashex.org/chains/ton/

Claim: TON's core protocol implementation is open source under the ton-blockchain/ton repository on GitHub, with reproducible builds.

Coverage basis: Fully open-source implementation

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The TON monorepo is publicly accessible with build instructions, CI/CD, and release artifacts.

Full credit for open-source availability. This subfactor scores the transparency of the current implementation, not whether that implementation is quantum-safe.

• https://github.com/ton-blockchain/ton

Claim: TON's architecture (wallet-as-smart-contract, upgradeable system contracts, workchain model, TVM cryptographic flexibility) provides structural advantages for future cryptographic upgrades, but no quantum-specific parameter agility or upgrade path is documented.

Coverage basis: General architectural flexibility exists; no quantum-specific plan

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The ton.app community article documents TON's architectural flexibility for PQC adoption: wallet-as-smart-contract design allows custom signature schemes, workchain model enables sandbox testing, system contracts are upgradeable via masterchain configuration.

Score of 0.25 reflects that general upgrade mechanisms exist (public design/draft level for quantum context) but no quantum-specific parameter agility plan has been published.

• https://ton.app/journal/guide/how-quantum-technologies-threaten-cryptocurrencies-and-is-ton-ready-for-them
• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing

Claim: No stateful PQC signatures (XMSS/LMS/SPHINCS+) are used in TON. Subfactor is not applicable to the current production scope.

Coverage basis: No stateful signatures deployed

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Marked N/A because no stateful signatures exist in the current production scope.

• https://docs.ton.org/blockchain-basics/contract-dev/techniques/signing

Claim: No performance or resource-impact analysis for PQC deployment on TON has been published.

Coverage basis: No PQ performance analysis

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No public analysis exists for how PQC signature sizes (ML-DSA: ~2.5KB, SLH-DSA: ~8-40KB, FN-DSA: ~0.7-1.3KB) would affect TON's block size limits, gas costs, fee markets, mempool dynamics, archival storage, or validator hardware requirements.

This subfactor is scored at 0.00 because no analysis has been published.