PoS smart-contract platform
Toncoin TON
Toncoin (TON) is a PoS smart-contract platform that relies entirely on Ed25519 elliptic-curve cryptography for all wallet transaction signatures, validator consensus signatures, and P2P node identity. Public keys are exposed on-chain for every wallet that has ever sent a transaction, creating a massive long-exposure attack surface vulnerable to 'harvest now, decrypt later' quantum attacks via Shor's algorithm. The TON Foundation has not published a quantum risk assessment, PQC migration roadmap, prototype, testnet, or mainnet path. TON's state-integrity layer uses hash-based Merkle proofs (SHA-256) which provides adequate quantum-resistant collision resistance, but this does not protect against the primary quantum attack vector: private key recovery from exposed Ed25519 public keys. TON's architecture (wallet-as-smart-contract, upgradeable system contracts, workchain model) provides genuine structural flexibility for future PQC adoption, but these are architectural properties, not deployed protection. The QRI Score of 13/100 reflects Stage 1 (Quantum Risk Assessed) status: the cryptographic inventory is publicly documented and the quantum risk can be assessed from available evidence, but there is zero production quantum protection across all critical layers.
ECC-Only Active SecurityLong-Exposure Public KeysNo Quantum RoadmapEd25519 Spend AuthorizationEd25519 Consensus Signatures
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
3.89 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
6.56 / 35
Security Assessment & Evidence Preparedness
1.25 / 5
Critical Quantum Blockers
- All wallet and transaction spend authorization is Ed25519-only (quantum-vulnerable via Shor's algorithm) with no PQC or hybrid path.
- All validator/consensus signatures are Ed25519-only, making consensus finality quantum-vulnerable.
- Public keys are exposed on-chain for every wallet that has ever sent a transaction, creating a massive long-exposure 'harvest now, decrypt later' attack surface.
- No public PQC migration roadmap, prototype, testnet, or mainnet path exists.
- No public quantum risk assessment has been published by the TON Foundation.
Key Risks
- All TON wallets (v1–v5, highload wallets) use Ed25519 signatures exclusively. A CRQC capable of running Shor's algorithm can recover private keys from any on-chain public key, enabling theft of all funds in wallets that have ever broadcast a transaction.
- Public keys are permanently exposed on-chain from the moment a wallet sends its first transaction. This is a structural long-exposure vulnerability — keys published today can be collected and decrypted later ('harvest now, decrypt later').
- Consensus (Catchain BFT) relies on Ed25519 validator signatures. A quantum attacker could forge validator signatures to compromise block finality, enabling double-spend attacks or chain reorganization.
- The TON Foundation has published no quantum migration roadmap through 2026. The official roadmap at ton.org/roadmap makes no mention of post-quantum cryptography.
- No freeze, burn, deprecation, or salvage policy exists for quantum-vulnerable balances in wallets with exposed public keys. Dormant and lost wallets with exposed keys represent irretrievable quantum-vulnerable value.
Assurance Notes
- TON has undergone multiple smart-contract and ecosystem security audits (CertiK, HashEx, etc.), but none address post-quantum properties, quantum migration, or quantum-critical cryptographic review.
- The TON source code is open source (ton-blockchain/ton on GitHub), enabling independent review of classical cryptographic implementations.
- No formal quantum-specific incident-response playbook, security contact for quantum vulnerabilities, or emergency governance process for quantum-related threats has been identified.
- No performance or resource-impact analysis for PQC signature/key sizes has been published, which will be important given that PQC signatures can be 4–40 KB versus Ed25519's 64 bytes.
- The official TON roadmap through 2026 contains no mention of post-quantum cryptography or quantum readiness.
Non-Scoring Caveats
- TON's architecture (wallet-as-smart-contract, upgradeable system contracts, workchain model, TVM cryptographic flexibility) provides genuine structural advantages for future PQC migration, but these are architectural properties, not deployed protection.
- TON's state-integrity layer uses Merkle proofs with SHA-256, which provides ~128-bit quantum security via Grover's algorithm for collision resistance. This does not protect against the primary quantum attack vector (private key recovery from exposed public keys).
- Existing security audits (CertiK, HashEx) cover smart-contract and ecosystem security but are scope-mismatched for quantum readiness.
- The TVM supports BLS12-381, secp256k1, and secp256r1 primitives in addition to Ed25519 — none of which are quantum-safe. BLS12-381 pairings are themselves quantum-vulnerable.
- LayerQu independently scored TON at Migration Stage 0 (Unaware), QRI 23/100 under a different methodology. This evaluation is referenced for context only.
Evidence record
Claims and Caveats
Production Cryptographic Protection
Spend authorization / transaction signatures
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.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
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.
Production Cryptographic Protection
Consensus-critical authentication (validator signatures, block certificates)
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.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
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.
Production Cryptographic Protection
Privacy and proof layers
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.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
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.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
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.
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
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.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
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.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
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.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
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.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified and measurable
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.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap
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.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
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.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination
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.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum vulnerabilities
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.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
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.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit for quantum-critical scope
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.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
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.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
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.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
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.
Algorithm & Implementation Assurance
Performance and resource-impact analysis for PQ signature/verification costs
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.
Report metadata