What it is. TON is the blockchain wired into Telegram, where opening a wallet is something hundreds of millions of chat users can do inside an app they already have, and so far the project has said nothing about getting ready for quantum computers.
What we found. Of the way TON builds accounts, the secret math that locks each wallet becomes readable to anyone the moment that wallet sends its first payment, so that enormous everyday crowd is sitting on accounts a future quantum machine could empty.
Why it matters. A holder cannot count on a quiet fix here, because the people running the network have no plan, no team on it, and no stated position, and the layer that actually guards payments can only change through a disruptive network-wide switch.
TON has the architectural toolkit to migrate at the wallet layer without consensus changes (smart-contract wallets, TVM precompile system), but consensus-layer Ed25519 still requires a hard fork to replace. No PQ TEP, no working group, no foundation position. Telegram-driven retail growth puts hundreds of millions of potential users at exposed Ed25519 wallet contracts.
Summary
TON scores QRI 23 (Band 3 Planning, narratively closer to Band 2, TON has neither a PQ statement nor a working group), Migration Stage 0. Catchain consensus uses per-validator Ed25519 signatures with 2/3 quorum (not aggregated); BLS12-381 in TON is a TVM smart-contract precompile for cross-chain interop only, NOT consensus. Per v3.1 rule, 4f is N/A. The wallet-as-smart-contract model means every account's Ed25519 public key is committed to the address from creation and revealed on first send. Telegram-driven retail growth (TON Wallet in-Telegram, Tonkeeper >10M users, MyTonWallet >1M users) means a large active surface. ~383 active validators (Chainspect 2026-05-01); Nakamoto coefficient 78, one of the most decentralized PoS networks tracked. August 2024 DOGS-airdrop outages (2 in 48 hours) indicate coordination fragility under unexpected load. No PQ TEP, no working group, no foundation position. Mainnet-Traffic + Architecture-Execution Gap + Milestone-Discipline + Supply-Chain caps all fire. Both Gates 1a-Sig and 1a-KEM FAIL.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition; pure classical Ed25519 throughout
- Gate 1a, Hybrid KEM: FAIL , no documented hybrid KEM at ADNL transport / RPC TLS
- Gate 1b, Commit-to-hash: COND , TON is pure-classical; no OR-composition
- Gate 2, Evidence reconstruction: PASS , every sub-score has at least 1 public artifact; most have 2-4
- Gate 3, Primitive naming: PASS , every named primitive is specific, Ed25519, SHA-256, KECCAK-256, BLS12-381 pairing, secp256k1, secp256r1
Burn-vs-rescue policy on file
Declared option f, Undeclared. No public position on what happens to vulnerable accounts at PQ migration time. The wallet-in-contract model means the migration unit is a smart contract (deploy new wallet code, transfer funds), which architecturally favors (e) optional migration, but no policy statement exists.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 26 / 100
Consensus signatures are Ed25519 only. Cell hashing is SHA-256. TVM extended-cryptography update (2023-07) added precompiles for cross-chain interop, these are smart-contract-callable opcodes, NOT chain-level consensus primitives. The v2 baseline listed BLS12-381 as a validator-signature primitive; that is incorrect, BLS12-381 in TON is a TVM precompile, not consensus.
Ed25519 (universal signature scheme for wallets and validators) · SHA-256 (cell hashing / state commitment) · TVM precompiles (smart-contract-callable, NOT consensus): SHA256, SHA512, BLAKE2B, KECCAK256/512, secp256k1, secp256r1, Ristretto, BLS12-381 pairing operations Every primitive that protects funds, validator identity, or block finality is Shor-vulnerable. PQ-safe coverage = 0%.
Ed25519→ Shor-break-via-DL-without-pairingsSHA-256→ Grover-weaken (256→128bit)KECCAK-256→ Grover-weakenBLS12-381 pairing precompile→ Shor-break-via-pairings (called by smart-contract code only)secp256k1 / secp256r1 precompiles→ Shor-break-via-DL-without-pairings (smart-contract-only)
0 PQ families deployed. No lattice, no hash-based, no code-based, no isogeny. Diversity Cap (lowered to 60 in v3.1) is not yet structural, fires only when at least one PQ family ships at 5b/5c. Pre-deployment, no cap applies but the score is 0.
Ed25519 ≈ 128-bit classical; SHA-256 ≈ 256-bit classical → 128-bit post-Grover; KECCAK-256 ≈ 128-bit post-Grover. No NIST PQC category 1-5 mapping exists because no NIST PQC primitive is deployed.
TVM has no machine-checked cryptographic proof; ton-blockchain/ton C++ reference uses libsodium-class Ed25519 (OpenSSL-derived hash primitives). constant_time: standard libsodium implementations are constant-time. library_provenance: no third-party formal audit of the validator-signature path is published. Cryptanalytic tier: Tier 1 (mature classical) for Ed25519, SHA-256, KECCAK-256.
2 Quantum Recovery Exposure weight 10% 22 / 100
TON wallet model is 'wallet-in-contract', every TON account is a smart contract whose initial state includes the owner's Ed25519 public key. The address is the hash of init-state + code, so the public key is committed to the address from creation. On any outgoing message the wallet contract reveals the public key. Effectively, every active wallet has its Ed25519 public key publicly readable on-chain after first send. Telegram-driven retail growth means a large active surface.
TON mainnet launched 2019-08 (test) / 2020-05 (modern Ton Foundation network reset). Active wallet contracts whose owners are dormant carry the same public-key reveal property as 2a (pubkey is in the contract state). No equivalent of P2PKH-cold (pubkey hidden until spend) exists in TON because the contract-init-hash structure exposes the key in the deployed contract. Lost / dormant TON balances are similarly exposed.
Classical Ed25519 throughout history; no rotation primitive; no PQ replacement deployed. Every historical block-proof signature is forgeable post-Shor.
ADNL (TON's transport layer) and validator gossip use classical key exchange. Telegram integration (TON Wallet in Telegram) routes some metadata over Telegram's MTProto stack, which is classical. No hybrid-PQ KEM disclosed at any transport surface.
3 Metadata, Anonymity & Confidentiality weight 13% 26 / 100
Transparent ledger; addresses pseudonymous. Telegram-TON Wallet integration adds a strong off-chain linkage (Telegram user ID ↔ wallet address) for Telegram-native flows. No native shielded pool.
Top-3 public RPC providers on TON: TONcenter (toncenter.com, TON Foundation-operated), GetBlock, Orbs Network's public TON RPC. Concentration high (TONcenter handles a large share of public dApp traffic; precise percentages not published). Mempool-equivalent observability is moderate (TON has no global mempool, external messages go directly to validators via ADNL, then to Catchain). Validator metadata retention policy not formally declared.
TON Bridge (foundation), Symbiosis, Orbs TON-Teleport, Stargate (LayerZero), all classical, all observable. Cross-chain flow correlation is straightforward.
No shielded pools or ring-sig privacy. Post-Shor, the existing transparent ledger does not gain new privacy loss because the ledger is already transparent. Modest credit for 'no encrypted state to retroactively decrypt.'
No mixnet; no on-chain shuffle; no commit-reveal mixer in production at the chain layer.
4 Migration Architecture weight 10% 51 / 100
TON's 'wallet-as-smart-contract' model (Wallet v1→v5) lets users deploy new wallet code with different signature-verification logic and migrate funds via standard transfers. This is application-layer agility, not protocol-layer. TVM provides Ed25519 CHKSIGN and BLS12-381 pairing precompiles, and a smart-contract wallet could in principle verify hybrid Ed25519+BLS or import a custom verifier via TVM CALLREF, but no PQ verifier opcode (Dilithium / ML-DSA / Falcon / SLH-DSA) exists. Validator/consensus signature scheme is fixed at Ed25519 and cannot be swapped without a hard fork.
Every TON wallet is already a smart contract (effectively 'native AA' from day one, predates ERC-4337). Wallet v5 (W5) supports gasless transactions and 255 messages per signed external, the signature interface is contract-defined, so a v6 wallet shipping a hybrid Ed25519+lattice verifier would not need consensus-layer changes. No client-layer PQC path documented; no AA-PQ wallet shipped.
TVM upgrade 2023-07 (Extended Cryptography) was coordinated across validators and shipped on mainnet. Subsequent TVM releases continue. Track record exists but is not stress-tested against an adversarial cryptographic deadline. The August 2024 outages (DOGS airdrop / heavy congestion / multiple consecutive disruptions) show coordination challenges under unexpected load.
Architecturally feasible at wallet contract level (TVM has CHKSIGN for Ed25519 and could call a custom hybrid verifier from smart-contract code). Not announced. No TEP exists for hybrid PQ signatures.
N/A (no stateful hash scheme deployed). Default full credit per v3.1 rule.
Catchain consensus uses per-validator Ed25519 signatures with 2/3 quorum (validator signatures collected as a 'block proof' gossiped to full nodes, not aggregated into a single curve point). There is no BLS aggregation in TON consensus, BLS12-381 is a TVM precompile for cross-chain interop only. Per v3.1 rule, 4f is N/A for chains using non-aggregating signatures at consensus. Renormalized to /80 → 41/80 → 51/100 on rubric scale.
5 Deployment Execution weight 22% 15 / 100
Zero PQ traffic on mainnet.
Zero PQ LOC in ton-blockchain/ton (validator client). BLS12-381 pairing code exists, but it is a TVM smart-contract precompile and is not PQ-safe.
~383 active validators (Chainspect, 2026-05-01), zero with PQ keys.
VOIDED per v3.1 rule (5a = 0).
Announced PQC trailing-12mo on TON Foundation channels = 0; shipped = 0; ratio = 0/0 → no washing tag. Full credit for honest silence (no narrative).
Not disclosed; no PQ deployed → no multiplier published.
6 Supply Chain Vendor Readiness weight 22% 8 / 100
Top-3 by usage: TON Wallet in Telegram (~hundreds of millions of Telegram users with potential access), Tonkeeper (>10M users), MyTonWallet (>1M users). PQC roadmap: none published for any of the three.
Top-3: TON Bridge (TON Foundation), Orbs TON-Teleport, Symbiosis / Stargate (LayerZero). PQC roadmap: none.
Top-3 venues holding TON: Binance, OKX, Bybit. PQC roadmap published by these custodians: none disclosed for TON specifically.
Top-3 RPC: TONcenter, GetBlock, Orbs. HSM/TEE coverage in TON validator stack: not standardized. PQC roadmap: none.
7 Governance & Coordination weight 8% 42 / 100
Nakamoto coefficient 78 across ~383 validators (Chainspect, 2026-05-01). One of the most decentralized PoS networks tracked.
TVM upgrades shipped successfully. Two consecutive August 2024 outages (DOGS airdrop) are a coordination flag, the network recovered within hours but garbage-collection bottleneck took multiple validators offline simultaneously, indicating coordination fragility under unexpected load.
TON Foundation is the coordinating entity (ton.org). No named PQ-migration lead. Chain has historical complexity: Telegram founded TON, divested under SEC pressure 2020, the open-source community + TON Foundation now coordinate. Named PQ working group: none.
Telegram regulatory shock (Pavel Durov France detention, August 2024) did not force chain-level cryptographic action, chain operated independently. No adversarial cryptographic-deadline precedent.
No canary, no rate-limit-spending rule, no consensus tripwire.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y reaches 2031–2038, Crisis Zone (vs Z10 2030); Outside risk window for upper end (vs Z25 2035)
Z-compliance
Outside compliance window for upper portion of range, TON Foundation Switzerland; Telegram OÜ Estonia; EU NIS2 + ENISA PQC roadmap targets 2030-2035 for hybrid deployment
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Chainspect 2026-05-01 lists 383 active validators. Other trackers (TON Stat, Nakaflow) report similar but not identical numbers depending on snapshot timing. Methodology accepts ~383 as the published reference.
v2 baseline listed BLS12-381 as a validator-signature primitive, incorrect. BLS12-381 in TON is a TVM smart-contract precompile for cross-chain interop only, NOT consensus. Consensus is per-validator Ed25519 with 2/3 quorum, no aggregation. 4f is therefore N/A.
v2 baseline listed 'August 2025' outages, verified against The Block / Cointelegraph reporting, the actual outages were August 2024 (DOGS airdrop). v2 baseline correction applied.
If Dim 5 weighted at 18% (privacy-focused profile) instead of 22%, raw sum drops ~0.5 pts; if Dim 6 weighted at 25% (rollup-L2 profile), raw sum rises ~0.7. Neither shifts the band.
Delta-QRI under alternative weighting
Under alternative weighting profiles, QRI shifts ±0.7; band unchanged.
Announcement-to-shipped ratio
Announced: 0. Shipped: 0. Ratio: 0.
Tag: none, full credit for honest silence (no narrative)
Peers in the L1 profile
9 chains closest to TON (The Open Network) by Stage then QRI.