Skip to content

How we count

PQ Radar reads public blockchains and reports what they already show. It never holds keys, never signs, and never calls anyone unsafe. This page is written for auditors, journalists and the people whose names appear on the board.

The threat model, in one paragraph

Every major blockchain today secures accounts with signature schemes (ECDSA on secp256k1, Ed25519) that a large enough quantum computer could break. Such a machine does not exist yet. When it does, it could derive the private key from any public key it can see. On most chains the public key becomes visible the first time an account signs a transaction. Until then the address is only a hash of the key, which quantum computers are not expected to reverse. That is the whole basis of the statuses below.

The five statuses

Quantum-safe
The address is controlled by a post-quantum key. Today only Algorand native Falcon-1024 accounts and Algorand Falcon LogicSig accounts qualify.
Not yet exposed
A classical key whose public key has never appeared on chain. Attackable only at the moment it spends.
Exposed
A classical key whose public key is on chain: any address that has signed, any Taproot output, any chain where the address is the key itself.
Contract
A smart contract or application account. Its exposure is that of its controlling keys, shown when known.
Unknown
Not enough data yet, or an address type the model does not cover. We say so rather than guess.

Every number is value-weighted: share of value, not a count of addresses.

Chain facts

Three facts per chain, each with a source. Where PQ Radar does not yet run its own scan, the exposed share is a cited estimate and is labelled as such.

  • AlgorandEd25519 and Falcon-1024

    A classical Algorand address is the 32-byte Ed25519 public key itself with a 4-byte checksum, base32 encoded, so the key is public from the moment an account is funded and never hidden. Exposure is therefore total by construction for Ed25519 accounts; only accounts whose authoriser is a Falcon key (via rekey or a native Falcon account) are not exposed.

    Live. Two paths exist. (1) Falcon LogicSig accounts: the AVM gained a falcon_verify opcode and the first post-quantum transaction on MainNet was executed on 3 November 2025 (Falcon-1024, about 1,280-byte signatures, about 1,793-byte public keys); an existing account can rekey to a Falcon-controlled LogicSig authoriser and keep its address (Algorand Post-Quantum Ledger, 14 May 2026). (2) Native Falcon-1024 accounts: delivered in the v5.0.0 protocol upgrade, which passed the approval threshold on 15 August 2026 and activated on MainNet after the mandatory 208,000-round (about 7 day) cooldown; Falcon-1024 accounts no longer need a LogicSig wrapper, derive from the usual 25-word mnemonic, and are supported by the SDKs, AlgoKit and Pera Wallet. Falcon-512 support is planned for end of 2026, multi-scheme multisig for end of 2026, and the Foundation targets broad quantum resilience by end of 2027.

  • Bitcoinsecp256k1 ECDSA and Schnorr

    P2PKH and P2WPKH outputs pay to a hash of the public key, so the key is only revealed when the output is spent; if the address is never reused the key is exposed only while the spend is unconfirmed. P2PK outputs (early mining rewards) and Taproot P2TR outputs commit to the public key itself, so the key is visible from the moment funds arrive. Address reuse re-exposes a hashed address once it has spent.

    Not live. BIP-360 (Pay-to-Merkle-Root, P2MR) is a Draft proposal, merged into the BIP repository in February 2026 (version 0.12.1 dated 2026-07-24), for a SegWit v2 output type like Taproot with the quantum-vulnerable key-path spend removed; it needs a soft fork and is not deployed. Post-quantum signature schemes themselves are deferred to a future companion BIP. Chaincode Labs (May 2025) proposed a dual-track migration; Galaxy launched a Bitcoin Quantum Readiness Initiative in 2026.

  • Ethereumsecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them. The account model encourages address reuse, so most ETH sits in accounts that have already sent at least once.

    Not live. The Ethereum Foundation's plan is signature agility through account abstraction rather than a protocol-wide key swap: EIP-8141 (Frame Transactions, native account abstraction) is being considered for the Hegota upgrade in the second half of 2026, letting an account switch to a post-quantum signature scheme individually. pq.ethereum.org tracks the full roadmap (PQ signature precompiles, PQ transactions, PQ aggregation) with a stated goal of quantum resistance across execution, consensus and data layers by December 2029. STARK-based rollups already rely on hash assumptions, but EOAs on L1 remain secp256k1 today.

  • SolanaEd25519

    A Solana account address is the 32-byte Ed25519 public key itself, base58 encoded (program derived addresses have no key). The key is therefore public from the moment an account is funded, and exposure is total by construction for keypair accounts.

    Not live at protocol level. The Solana Foundation's quantum readiness post (27 April 2026) reports that Anza and Firedancer independently converged on Falcon and have initial implementations, with a three-step plan: keep evaluating Falcon and alternatives, adopt post-quantum schemes for new wallets if the threat becomes credible, then migrate existing wallets. An application-level option exists: Blueshift's Winternitz Vault, a hash-based one-time-signature program that has been live on Solana for over two years, lets users park SOL under a quantum-resistant key, but it is not a protocol account type.

  • TRONsecp256k1 ECDSA

    A TRON address is 0x41 followed by the last 20 bytes of Keccak-256 of the secp256k1 public key, so a receive-only account has not revealed its key. The first signed transaction exposes the key (recoverable from the ECDSA signature) for the life of the account, as on Ethereum.

    Not live on mainnet. TIP-899 Post-Quantum Signature Support (opened 1 July 2026, Draft) adds Falcon-512 (FN-DSA-512) and ML-DSA-44 signature types with addresses derived as 0x41 plus Keccak-256 of the PQ public key; it is deployed on the Nile testnet and each algorithm needs its own on-chain governance vote before mainnet. Justin Sun said in April 2026 that a quantum-resistant testnet would come in Q2 and mainnet in Q3 2026; later reporting moved the mainnet target to end of 2026.

  • BNB Smart Chainsecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. BNB Chain published the BSC Post-Quantum Cryptography Migration Report on 14 May 2026, testing ML-DSA-44 transaction signatures and pqSTARK aggregation for validator consensus; transaction size grew from about 110 bytes to about 2.5 KB and native-transfer TPS fell from 4,973 to 2,997. The report is research and evaluation, with no mainnet deployment or date.

  • Basesecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. Base's protocol overview describes it as a rollup built on Ethereum; Base runs as an OP Stack chain, and Optimism's Post-Quantum Roadmap for the Superchain (14 January 2026) sets January 2036 as the date after which ECDSA-only EOAs on OP Mainnet and participating OP Stack chains stop transacting, with migration via EIP-7702 delegation to smart accounts that verify post-quantum signatures. Coinbase's own post on post-quantum preparation could not be fetched (HTTP 403), so no Base-specific plan is recorded here.

  • Arbitrum Onesecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. Arbitrum docs state the chain is designed to be as compatible with Ethereum as possible, including Keccak-256 hashes and secp256k1 signatures. No Offchain Labs or Arbitrum Foundation post-quantum roadmap was found as of 2026-09-17; the chain would inherit Ethereum's account abstraction path (EIP-8141) if adopted.

  • Polygon PoSsecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. Polygon docs describe PoS as an EVM-compatible proof-of-stake sidechain for Ethereum. No Polygon Labs post-quantum roadmap for the PoS chain was found as of 2026-09-17. Polygon Miden, a separate STARK-based network, is not the PoS chain.

  • Avalanche C-Chainsecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. Avalanche's cryptographic primitives page states the VM uses secp256k1 signatures and that the C-Chain duplicates Ethereum's cryptographic constructs; X-Chain and P-Chain addresses are sha256 then ripemd160 of the compressed key. No Ava Labs post-quantum roadmap was found as of 2026-09-17 (an Avalanche forum thread on the topic could not be fetched).

  • OP Mainnetsecp256k1 ECDSA

    An EVM address is the last 20 bytes of the Keccak-256 hash of the secp256k1 public key, so an account that has only received funds has not revealed its key. The first transaction an externally owned account sends carries an ECDSA signature from which the public key is recovered, and it stays exposed for the life of the account. Contracts and smart accounts have no key of their own; exposure sits with whichever keys are authorised to control them.

    Not live. Optimism published A Post-Quantum Roadmap for the Superchain on 14 January 2026: by January 2036 ECDSA-signed EOA transactions are to be deprecated on OP Mainnet and participating OP Stack chains, with EOAs delegating to smart contract accounts via EIP-7702 that verify post-quantum signatures, sequencer and batch submission moving off ECDSA, and a coordinated hard fork once the ecosystem converges on a scheme. The post says users need take no action today.

  • XRP Ledgersecp256k1 ECDSA and Ed25519

    An XRPL address is the RIPEMD160 of the SHA-256 of the public key (secp256k1 or 0xED-prefixed Ed25519), base58 encoded, so a receive-only account has not revealed its key. Every signed transaction carries the SigningPubKey field, so the key is public after the first send; a holder can set a regular key and disable the master key to move to a fresh, unexposed key.

    Not live. Ripple's Post-Quantum Readiness on the XRP Ledger (20 April 2026) sets a four-phase plan: a Q-Day recovery contingency (stop accepting classical signatures, migrate via post-quantum zero-knowledge ownership proofs), evaluation of NIST schemes in H1 2026, candidate PQ signatures alongside ECDSA on Devnet in H2 2026, and an amendment for native PQ signatures targeting 2028. Testing is on AlphaNet and Devnet.

  • TONEd25519

    A TON wallet is a smart contract; its address is the hash of the StateInit (contract code plus initial data, which includes the Ed25519 public key), not the key itself. An address can hold a balance in the uninit state before the contract is deployed, and most wallet apps deploy on the first outgoing transaction. Once active, the wallet's persistent data stores the public key and it is readable by anyone, so the key is public for the life of the wallet after the first send.

    Not live. No TON Foundation post-quantum roadmap, proposal or research post was found as of 2026-09-17. Because wallets are contracts, a post-quantum wallet contract could in principle be deployed without a protocol change, but no such standard wallet was located.

  • SuiEd25519, secp256k1 ECDSA, secp256r1 ECDSA and multisig

    A Sui address is BLAKE2b-256 of a 1-byte scheme flag concatenated with the public key, so a receive-only address has not revealed its key. Every serialized transaction signature is flag || sig || pk, so the public key is published with the first signed transaction and stays linked to the address.

    Not live on mainnet. Mysten Labs' post (18 August 2026) picks ML-DSA-65 (NIST Level 3) for native account authentication and SLH-DSA-SHA2-128s vaults in Move for high-value holdings; quantum-safe vaults are targeted for mainnet in 2026, native ML-DSA-65 accounts for testnet by end of 2026 and mainnet in Q1 2027, subject to audits. Address aliases are already deployed and are meant to let an existing account swap in a post-quantum key while keeping its address; adoption is opt-in.

  • CardanoEd25519

    The payment part of a Shelley address is a blake2b-224 hash of an Ed25519 verification key (CIP-19), so a receive-only address has not revealed its key. Spending requires a verification-key witness (public key plus signature) in the transaction, which publishes the key; HD wallets rotate addresses but reuse is common.

    Not live. Input Output Research's Cardano Vision 2026 (19 June 2026) targets a post-quantum VRF for slot leader election, security proofs for an updated Ouroboros, a prototype and a migration CIP, and investigates zero-knowledge migration of wallet addresses. CIP-0197 (pull request opened 7 August 2026, still open) proposes an optional zero-knowledge proof of the HD seed alongside the existing Ed25519 signature, keeping keys and addresses unchanged; it is not merged or deployed.

Algorand, measured exactly

PQ Radar scans every Algorand account above 1,000 ALGO once an hour through the public Indexer, which records the signature type an account last used. Native Falcon accounts read as Quantum-safe. LogicSig accounts are checked byte for byte against the Algorand Foundation's Falcon template; a match is Quantum-safe, anything else is Contract. Ed25519 and multisig accounts read as Exposed. An account that has never signed reads as Unknown: its address may be an Ed25519 key, which would already be visible, but a multisig or application escrow can look the same, so we do not guess. The largest never-signed accounts are probed for sent transactions; those that have any are application accounts and read as Contract. Accounts rekeyed but idle since also read Unknown. Value is weighted by ALGO balance over every account above 1,000 ALGO; asset holdings join in a later stage.

Labels and who is who

An entity's wallets are named only from a source we can cite: the entity told us (Verified), or a public source such as the entity's own published wallet list (Attributed, source shown on hover). Everything else is unlabelled. Labels are reviewed by a person before release.

Disputes

If a label or a status about you is wrong, write to the address on this page and it is hidden within one business day while we check. The dispute address is published with the first labelled release.

Known limits

  • Coverage: entity totals cover labelled addresses only, and the coverage is stated per entity.
  • Exposed does not mean funds are lost. It means the public key is visible.
  • Public data providers rate-limit us. Freshness is shown on every number.