WhiteBIT Coin WBT

Claim: No public cryptographic inventory or quantum threat model has been published by WhiteBIT or the Whitechain project.

Coverage basis: The project has not inventoried its use of ECDSA/secp256k1 across spend authorization, consensus, P2P, or bridge layers, nor published any quantum threat model.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No public cryptographic inventory — Readiness & Risk Cap: 10

Assurance: Absence of inventory is confirmed by exhaustive search of Whitechain documentation, whitepaper, GitHub repository, and web search for 'Whitechain quantum' / 'WhiteBIT post-quantum' yielding zero results.

The project architecture is well-documented for classical purposes but contains zero quantum-awareness. This is the binding Readiness & Risk Cap at 10.

• https://docs.whitechain.io/general/architecture
• https://github.com/whitebit-exchange/wbt
• https://cdn.whitebit.com/wbt/whitepaper-en.pdf

Claim: No quantum-specific evidence record exists; the project has published no code references, specs, audits, transaction examples, or reproducible analytics related to quantum risk.

Coverage basis: No quantum evidence record of any kind.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence confirmed by search of all project sources and web.

The project has published standard documentation (whitepaper, architecture docs, GitHub README) but none addresses quantum risk.

Claim: Whitechain spend authorization uses standard Ethereum ECDSA/secp256k1 account signatures; ERC-20 and TRC-20 WBT inherit host-chain ECC spend authorization.

Coverage basis: Whitechain is a go-ethereum fork with standard EVM accounts; Clique PoA does not modify the transaction signing model. No PQC or hybrid-PQC path exists on any chain.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All spend authorization is ECDSA/secp256k1-only across all three chains

Assurance: The geth fork architecture and EVM compatibility confirm standard secp256k1 transaction signing. This is directly verifiable from public source code and the Clique EIP-225 specification.

Standard Ethereum transactions expose the public key in the signature (v, r, s), creating long-exposure attack surfaces for all accounts that have ever sent a transaction.

• https://github.com/whitebit-exchange/wbt
• https://docs.whitechain.io/general/architecture
• https://etherscan.io/address/0x925206b8a707096ed26ae47c84747fe0bb734f59

Claim: Whitechain uses standard Ethereum account model where public keys are derivable from transaction signatures; reused addresses and transacted EOAs have long-exposure public keys.

Coverage basis: Same as Ethereum: address = last 20 bytes of Keccak256(public key); public key exposed on every spend. No PQ/hybrid key-derivation or address format exists.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Confirmed by EVM compatibility and geth fork architecture; no deviation from standard Ethereum account model is documented.

Long-exposure public keys on all transacted EOAs mean quantum attackers can target accounts offline with no time constraint.

• https://github.com/whitebit-exchange/wbt
• https://docs.whitechain.io/general/architecture

Claim: Whitechain uses Clique PoA consensus with secp256k1 validator block signatures; currently a single validator operated by WhiteBIT.

Coverage basis: Clique PoA as specified in EIP-225: block sighash is signed with secp256k1, 65-byte signature embedded in extraData. Whitechain docs confirm Clique consensus protocol.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Clique PoA consensus uses secp256k1 block signatures — quantum-vulnerable

Assurance: EIP-225 explicitly states: 'The sighash is signed using the standard secp256k1 curve, and the resulting 65 byte signature (R, S, V) is embedded into the extraData.' Whitechain architecture docs confirm Clique usage.

With a single validator, quantum compromise of the validator key would allow full chain rewrite. Even with planned multi-validator expansion, all would use secp256k1.

• https://eips.ethereum.org/EIPS/eip-225
• https://docs.whitechain.io/general/architecture
• https://github.com/ethereum/go-ethereum/blob/master/consensus/clique/clique.go

Claim: Whitechain uses standard Ethereum state trie (Merkle Patricia Trie) with Keccak256 hashing; no KZG/pairing commitments or other quantum-vulnerable state-binding mechanisms beyond standard hash assumptions.

Coverage basis: Standard geth state model. Keccak256 is considered quantum-safe for preimage resistance (Grover's algorithm provides only quadratic speedup). No pairing-based commitments are used.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: note-only

Assurance: State integrity relies on Keccak256 which has no known polynomial-time quantum attack for collision or preimage resistance. However, spend authorization (which gates state transitions) remains ECC-vulnerable, so state can be compromised indirectly.

State-integrity mechanisms themselves are not the primary quantum vulnerability; the spend authorization and consensus layers are the critical attack surfaces. Scored 0 because state transitions are gated by quantum-vulnerable signatures.

• https://github.com/whitebit-exchange/wbt
• https://docs.whitechain.io/general/architecture

Claim: Whitechain has no privacy layer, shielded transactions, ZK proofs, or confidential assets.

Coverage basis: Standard EVM chain with no privacy features documented.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://docs.whitechain.io/general/architecture
• https://cdn.whitebit.com/wbt/whitepaper-en.pdf

Claim: Whitechain uses standard go-ethereum devp2p networking with ECDSA node identities and ECIES handshake; no PQC or hybrid-PQC P2P protection.

Coverage basis: The geth fork includes standard devp2p with ECDSA-based node IDs (secp256k1 public key derived) and ECIES encrypted transport.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity uses ECDSA but is not directly spend-authorization-critical or consensus-critical; a quantum attacker compromising node identities could eclipse or impersonate nodes but cannot forge transactions or blocks without also compromising spend/consensus keys. Scored as applicable vulnerability.

While P2P is quantum-vulnerable, this layer alone would not enable asset theft without also compromising spend authorization or consensus keys. Still scored 0 as no PQC protection exists.

• https://github.com/whitebit-exchange/wbt
• https://github.com/ethereum/go-ethereum/tree/master/p2p

Claim: No PQC or hybrid-PQC wallet, custody, or HSM workflows exist for WBT on any supported chain.

Coverage basis: WhiteBIT exchange uses standard ECDSA-based custody; no PQ wallet infrastructure is documented for Whitechain, Ethereum, or Tron WBT.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: WhiteBIT emphasizes cold storage (96% of assets) and multi-signature wallets but these all rely on ECDSA. No PQ custody path is documented.

WhiteBIT's CCSS Level 3 certification and cold storage practices are classical security measures with no quantum relevance.

• https://whitebit.com
• https://help.whitebit.com/hc/en-gb/articles/17190215630493-All-about-WBT-Coin

Claim: Approximately 0% of WBT value-at-risk is quantum-protected; ~$10–12B market cap (~213M circulating WBT) is entirely secured by ECDSA/secp256k1 across Whitechain, Ethereum, and Tron.

Coverage basis: All WBT on all three chains relies on ECC for spend authorization. No PQ-native or migrated balances exist. Coverage is effectively 0%.

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: ~100% of ~$10–12B value-at-risk is quantum-vulnerable

Assurance: Market data from CoinGecko and WhiteBIT exchange shows ~213M circulating WBT at ~$57/WBT ≈ $12.2B market cap as of June 2026. All value is on ECC-only chains with no PQC migration.

Coverage threshold: <25% → score 1 out of 20 (Implementation Score equivalent: 0.05). Even this minimal score reflects only that some value is on Whitechain (which WhiteBIT could theoretically halt/migrate in an emergency), not that any actual protection exists.

• https://whitebit.com/assets/WBT
• https://www.coingecko.com/en/coins/whitebit
• https://etherscan.io/address/0x925206b8a707096ed26ae47c84747fe0bb734f59

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations) have been migrated to or are protected by PQC or hybrid-PQC for any WBT representation.

Coverage basis: All WBT custody — including WhiteBIT's own cold storage (~96% of exchange assets), the treasury allocation (~200M WBT), bridge operator keys, and any third-party custodians — relies on ECDSA.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: WhiteBIT reports 96% cold storage with multi-signature wallets — all ECDSA-based. The treasury of 200M WBT (50% of max supply) with staged unlocks is entirely quantum-vulnerable.

WhiteBIT's operational control over the single Whitechain validator and bridge mechanisms means they could theoretically coordinate a migration, but no such plan exists.

• https://whitebit.com
• https://cdn.whitebit.com/wbt/whitepaper-en.pdf
• https://help.whitebit.com/hc/en-gb/articles/17190215630493-All-about-WBT-Coin

Claim: No identification, measurement, deprecation, freeze, or migration of quantum-vulnerable WBT accounts or balances has been performed or published.

Coverage basis: All accounts across all three chains are quantum-vulnerable. No legacy pool identification, deprecation policy, or freeze mechanism exists.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence of any legacy-pool identification or deprecation is confirmed by exhaustive search of all project documentation and web sources.

Whitechain's centralized architecture means WhiteBIT could theoretically identify and freeze vulnerable accounts, but no such capability is documented for quantum scenarios.

Claim: No public PQC migration or protection roadmap exists for WBT or Whitechain.

Coverage basis: Zero quantum-related content in whitepaper, architecture docs, GitHub, or any public communication.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence confirmed by search of all project sources. The whitepaper (v1.2, February 2024) discusses tokenomics, PoA consensus, and ecosystem plans but contains zero quantum references.

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, warnings, education, or migration prompts exist for WBT on any supported chain.

Coverage basis: Standard EVM tooling only; no PQ-aware features in any WhiteBIT or Whitechain product.

Implementation score: 0 · Evidence confidence: High

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

Assurance: WhiteBIT offers a Web3 wallet for Whitechain but it uses standard ECDSA key generation with no PQ option.

• https://whitebit.com
• https://docs.whitechain.io

Claim: No migration enforcement mechanisms exist; no deprecated legacy signing, no restricted withdrawals, no unsafe-path blocking, and no exchange/custody coordination for quantum migration.

Coverage basis: No enforcement, deprecation, or coordination mechanisms of any kind are documented for quantum migration.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The ERC-20 WBT token contract has owner-controlled pause and blacklist functions (per Hacken audit), which could theoretically be used in an emergency, but these are not quantum-specific and do not address Whitechain native or TRC-20 WBT.

WhiteBIT's centralized control over Whitechain gives them operational ability to coordinate, but no quantum-specific coordination plan, agreement, or mechanism is publicly documented.

Claim: WhiteBIT has a general bug bounty program (HackenProof, [email protected]) and incident response capability, but no quantum-specific vulnerability disclosure or incident response process is documented.

Coverage basis: General bug bounty exists but is not quantum-specific. No quantum incident response playbook, quantum-specific disclosure policy, or quantum emergency governance process is published.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The existence of a general bug bounty and security contact is positive for operational security but does not constitute quantum-specific incident response. Scored 0 because no quantum-specific process exists; treated as note-only because the absence of a quantum playbook does not itself create a current quantum attack path (the vulnerability already exists in the cryptography).

• https://help.whitebit.com/hc/en-gb/articles/18250536815517-Bug-Bounty
• https://hackenproof.com/programs/whitebit

Claim: No PQC or hybrid-PQC algorithms are used anywhere in the WBT/Whitechain stack.

Coverage basis: All cryptography is classical ECDSA/secp256k1 and Keccak256. No NIST PQC algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON, SPHINCS+, etc.) are implemented or planned.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The geth fork codebase contains only classical cryptographic primitives (secp256k1, Keccak256). No PQC library dependencies or implementations are present.

• https://github.com/whitebit-exchange/wbt
• https://eips.ethereum.org/EIPS/eip-225

Claim: No independent cryptographic audit covering quantum security exists for Whitechain consensus, spend authorization, P2P, or bridge mechanisms.

Coverage basis: Hacken audited the WBT ERC-20 token contract (2022) and performed exchange penetration testing, but no quantum-specific audit of Whitechain protocol cryptography exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The absence of a quantum audit is treated as note-only because the quantum vulnerability (ECC-only cryptography) is directly verifiable from public code and specifications without requiring an audit. An audit would confirm what is already known.

Hacken smart contract audits (2022) are stale but confirm the ERC-20 WBT is a standard token with no PQC features.

• https://hacken.io/case-studies/whitebit-case/
• https://hacken.io/

Claim: Whitechain node software is open-source (LGPL-3.0/GPL-3.0) on GitHub as a go-ethereum fork, but contains no PQC implementation.

Coverage basis: Code is public and buildable, but the subfactor measures open-source PQC implementation, which does not exist.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The codebase is public and well-structured as a geth fork (v1.2.0, January 2025), which is positive for transparency. However, this subfactor scores the existence of open-source PQC implementation, which is absent. Scored 0 for no PQC code.

The open-source nature of the codebase would be an asset if/when PQC migration begins.

• https://github.com/whitebit-exchange/wbt

Claim: No parameter agility or PQC upgrade path is documented for Whitechain or WBT.

Coverage basis: No documentation addresses cryptographic agility, algorithm upgrade procedures, or PQC transition planning.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence confirmed by search of all project documentation.

Whitechain's centralized PoA governance could theoretically enable faster upgrades than decentralized networks, but no such capability is documented for cryptographic transitions.

Claim: No stateful signatures (XMSS/LMS) are used; this subfactor is not applicable to the current production system.

Coverage basis: Whitechain uses only stateless ECDSA signatures. No stateful PQC signatures are implemented or planned.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No performance or resource-impact analysis for PQC deployment exists for Whitechain.

Coverage basis: No analysis of how PQC signature sizes, verification times, or key sizes would affect Whitechain's 2-second block time, 100 TPS throughput, gas economics, or node hardware requirements.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Treated as note-only because the absence of a PQC performance analysis does not create a current quantum attack path; it would become relevant only if/when PQC migration begins. The existing ECC-only system is already fully vulnerable.

Whitechain's 2-second block time and 100 TPS throughput target may face challenges with larger PQC signatures (e.g., CRYSTALS-Dilithium at ~2.4KB vs ECDSA at ~65 bytes), but this is a future concern.