BNB Chain BNB

Claim: BNB Chain published the BSC Post-Quantum Cryptography Migration Report (May 14, 2026) inventorying ECDSA (secp256k1) for transactions, BLS12-381 for consensus, and identifying P2P and KZG as pending. The report acknowledges Shor's algorithm threat to ECC and provides a forward-looking migration evaluation.

Coverage basis: Official research report covering all critical cryptographic layers with threat assumptions

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The report is published by BNB Chain as an official research document. It is comprehensive but is self-reported without independent third-party validation.

The report explicitly states it is forward-looking research, not a response to immediate threat. Covers transactions, consensus, public key storage, and cross-region performance. P2P and KZG are identified as out of current scope.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://chainwire.org/2026/05/14/bnb-chain-publishes-research-report-exploring-post-quantum-cryptography-migration-path-for-bsc/

Claim: The PQ migration report references GitHub PR #3660, provides detailed test data (TPS, block sizes, signature sizes), and discusses specific algorithm choices with NIST standardization context.

Coverage basis: Research report with code references, performance data, and algorithm specifications

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: PR #3660 referenced in the report could not be independently located at the expected GitHub URL as of the evaluation date. Performance data is self-reported; no independent reproduction has been identified.

The evidence record is strong for a research/prototype stage but lacks independent audit, mainnet transaction proofs, or third-party reproducibility confirmation.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://github.com/bnb-chain/bsc

Claim: BSC mainnet uses ECDSA (secp256k1) for all transaction signatures. The PQ migration report tested ML-DSA-44 (NIST FIPS 204) as a replacement in a prototype environment, achieving compatibility with existing address formats, wallets, SDKs, and RPCs.

Coverage basis: Prototype/testnet — ML-DSA-44 tested in PoC but not deployed to mainnet production

Implementation score: 0.5 · Evidence confidence: High

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

Quantum blocker: Production spend authorization is entirely ECDSA (secp256k1) — all transaction signatures on BSC mainnet are quantum-vulnerable

Assurance: The production use of ECDSA is confirmed by official documentation, the PQ migration report (which contrasts 'current' with tested PQ algorithms), and the BSC codebase (go-ethereum fork). No independent audit of the PQ prototype exists.

The prototype demonstrates technical feasibility and backward compatibility, but the 40-50% TPS reduction and ~18× transaction size increase create significant deployment barriers.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://docs.bnbchain.org/
• https://github.com/bnb-chain/bsc

Claim: BSC uses standard EVM 20-byte addresses (Keccak256 hash of ECDSA public key). All transacted EOAs have permanently exposed public keys on-chain. The PQ prototype demonstrates that ML-DSA-44 can work with the same address format without changes.

Coverage basis: Design/research — prototype shows address compatibility with PQ keys; no production protection for long-exposure public keys

Implementation score: 0.25 · Evidence confidence: High

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

Quantum blocker: Long-exposure ECDSA public keys for all transacted EOAs remain permanently visible on-chain with no migration, freeze, or deprecation path

Assurance: The address-format compatibility claim in the prototype is plausible (hashing a larger ML-DSA public key to 20 bytes) but has not been independently verified in deployed code.

The PQ report's compatibility finding is forward-looking. In current production, all addresses with transaction history have exposed ECDSA public keys vulnerable to offline quantum attack.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://docs.bnbchain.org/

Claim: BSC Parlia consensus uses BLS12-381 for validator vote aggregation. The PQ migration report tested pqSTARK as a replacement, achieving ~43:1 compression ratio and manageable validator overhead.

Coverage basis: Prototype/testnet — pqSTARK tested in PoC but not deployed to mainnet

Implementation score: 0.5 · Evidence confidence: High

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

Quantum blocker: Consensus vote aggregation is entirely BLS12-381 — validator authentication can be compromised by quantum attack

Assurance: The parlia.go source file confirms the Parlia consensus engine. The BLS12-381 usage is documented in the PQ migration report and consistent with BSC's PoSA design. BLS Vote Address and BLS Proof are required for validator creation per official documentation.

pqSTARK aggregation performed well in prototype (43:1 compression). The consensus finality remained at two slots in median cases during testing.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://github.com/bnb-chain/bsc/blob/master/consensus/parlia/parlia.go
• https://docs.bnbchain.org/bnb-smart-chain/validator/overview/

Claim: BSC uses KZG commitments (BLS12-381-based) for BEP-336 blob-carrying transactions (modeled on EIP-4844). The PQ migration report explicitly states KZG commitments have not been evaluated for PQ alternatives.

Coverage basis: No implementation — KZG commitments remain entirely classical with no PQ evaluation

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: KZG commitments (BLS12-381 pairings) used in BEP-336 blob transactions are quantum-vulnerable; could compromise L2 data availability and bridge verification

Assurance: BEP-336 is a direct adaptation of EIP-4844 and explicitly uses KZG with BLS12-381. The blob-hub repository confirms production blob infrastructure on BSC mainnet. The PQ report confirms this layer has not been evaluated.

KZG replacement is described as requiring 'broader ecosystem coordination' (i.e., Ethereum alignment). BSC's blob infrastructure supports opBNB and other L2 rollups, making this a material quantum risk for the ecosystem.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-336.md

Claim: BSC is an EVM-compatible smart-contract platform without native shielded transactions, ZK privacy proofs, encrypted notes, or stealth addresses in its core protocol.

Coverage basis: N/A — BSC does not have native privacy features

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Application-layer privacy solutions deployed on BSC (e.g., third-party ZK rollups, mixers) are not part of the core protocol scope and would require separate evaluation.

• https://docs.bnbchain.org/

Claim: BSC nodes use devp2p (go-ethereum P2P stack) with ECDH-based key exchange and ECDSA-based node identity. The PQ migration report explicitly states P2P handshakes have not been evaluated for PQ alternatives.

Coverage basis: No implementation — P2P remains entirely classical with no PQ evaluation

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: P2P transport and node identity remain classical (ECDH) — not yet evaluated for PQ alternatives

Assurance: PR #3590 (merged March 2026) addressed a P2P message decoding vulnerability but did not change cryptographic primitives. The PQ report notes ML-KEM would be needed for P2P migration.

While P2P compromise does not directly enable asset theft (transactions are independently signed), it could enable node impersonation, eclipse attacks, or validator communication interception. The PQ report identifies this as a required future work item.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://github.com/bnb-chain/bsc/pull/3590

Claim: No evidence of PQ-enabled wallet, custody, HSM, or hardware-wallet support for BSC. All production wallets (MetaMask, Trust Wallet, Binance Wallet, etc.) use ECDSA secp256k1 for BSC transactions.

Coverage basis: No implementation — no PQ wallet or custody support exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQ wallet, custody, or HSM workflows exist for BSC; all production signing uses ECDSA

Assurance: Wallet support would be a prerequisite for any mainnet PQ migration but is downstream of protocol-level PQ deployment. This is scored at 0.00 because no PQ protocol path exists for wallets to support.

The PQ migration report notes that the prototype maintains compatibility with existing wallets, SDKs, and RPCs, which would facilitate a future migration but does not represent current PQ wallet support.

• https://docs.bnbchain.org/

Claim: 0% of BNB value-at-risk on BSC mainnet is protected by PQ cryptography. All spend authorization, consensus authentication, and state-integrity mechanisms remain classically vulnerable.

Coverage basis: No production PQ protection; <25% coverage

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 0% of value-at-risk is quantum-protected; all production cryptography is classically vulnerable

Assurance: No PQ protection exists in production. The 0% figure is confirmed by the PQ migration report, official documentation, and the BSC codebase.

BNB Chain has substantial economic value (typically top-5 by market cap). All of it is secured by quantum-vulnerable ECDSA. The PQ prototype does not protect any production value. Scores 1/20 per QRI threshold for <25% coverage (experimental/negligible protection).

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) on BSC are PQ-protected. All use ECDSA-based accounts.

Coverage basis: No migration — zero critical wallets protected

Implementation score: 0 · Evidence confidence: High

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

Assurance: No public attestations of PQ wallet migration from any BSC exchange, custodian, or protocol. This is expected given the absence of a production PQ protocol path.

This subfactor cannot be satisfied until a production PQ transaction path exists on BSC mainnet.

Claim: The PQ migration report identifies the current classical cryptographic mechanisms as vulnerable but does not provide a mechanism to identify, deprecate, freeze, or migrate specific vulnerable accounts or pools.

Coverage basis: Identified but no mechanism — report acknowledges vulnerability; no deprecation, freeze, or migration path exists

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The report identifies vulnerable cryptographic layers conceptually but does not enumerate specific accounts, UTXOs, contracts, or value pools that would require migration.

All transacted EOAs on BSC have permanently exposed ECDSA public keys. There is no mechanism to force migration, freeze vulnerable accounts, or burn unmigratable value.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: The PQ migration report provides a research evaluation of migration feasibility, identifies components (transactions, consensus), and notes pending areas (P2P, KZG). It does not provide a formal roadmap with activation criteria, timelines, or governance milestones.

Coverage basis: Research design/document — report evaluates feasibility; no formal roadmap with activation criteria

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The report states the work is 'research and evaluation, rather than a response to any immediate security threat,' indicating no committed timeline for production deployment.

The report is rich in technical detail (algorithm selection, performance data, compatibility analysis) but lacks governance sequencing: no BEP number, no hard fork schedule, no activation criteria, no testnet-to-mainnet transition plan.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, migration prompts, or educational materials exist for BSC mainnet users.

Coverage basis: No implementation — zero migration accessibility

Implementation score: 0 · Evidence confidence: High

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

Assurance: This is expected at Stage 2. The prototype demonstrates technical compatibility but no user-facing migration infrastructure exists.

The PQ report notes compatibility with existing wallets and SDKs, which would reduce migration friction if deployed, but no migration defaults, warnings, or educational content exist today.

Claim: No enforcement mechanisms exist. There is no legacy signing deprecation, no freeze mechanism for vulnerable accounts, no restricted withdrawals from vulnerable paths, and no exchange/custody/bridge coordination for PQ migration.

Coverage basis: No implementation — zero enforcement or coordination mechanisms

Implementation score: 0 · Evidence confidence: High

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

Assurance: No evidence of exchange, custody, bridge, wallet, or infrastructure coordination for a BSC PQ migration path.

BSC has a relatively centralized validator set (21-45 validators elected through PoSA), which could facilitate coordinated upgrades, but no such coordination has been evidenced for PQ migration.

Claim: No evidence of a quantum-specific incident-response playbook, emergency governance process, or disclosure procedure for quantum-related vulnerabilities.

Coverage basis: No implementation — no quantum-specific incident response

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: BNB Chain may have general security incident-response processes (bug bounty, security contacts), but no quantum-specific process has been publicly documented. Per the QRI v3.1 Note-Only Caveat Rule, this is assurance-only unless it leaves a current quantum-vulnerable path unresolved.

The absence of a quantum-specific IR playbook is noted but does not independently create a quantum-critical vulnerability in the current production system.

Claim: The PQ prototype uses ML-DSA-44 (NIST FIPS 204 standardized, also known as Dilithium) for transaction signatures and pqSTARK for consensus aggregation. ML-DSA-44 is NIST-standardized; pqSTARK is based on broadly reviewed STARK proof systems but is not itself a NIST standard.

Coverage basis: Prototype — NIST-standardized ML-DSA-44 for signatures; pqSTARK is well-reviewed but not NIST-standardized

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA-44 is NIST FIPS 204 standardized (August 2024). pqSTARK is not a NIST standard but builds on STARK proof systems with broad academic review. No independent audit of the prototype implementation exists.

The report provides a rationale for choosing ML-DSA-44 (NIST Level 2, equivalent to AES-128) over higher-security variants (ML-DSA-65, ML-DSA-87), citing the 10-20 year quantum threat timeline and performance trade-offs.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: No independent cryptographic or implementation audit of the PQ prototype (ML-DSA-44, pqSTARK) has been identified. The classical production system has general security reports (Hacken 2024) but none are quantum-specific.

Coverage basis: No audit — no independent review of PQ implementation exists

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No independent audit of the PQ prototype — quantum-critical properties of ML-DSA-44 and pqSTARK implementation cannot be independently verified

Assurance: The Hacken BNB Chain Security Report 2024 covers general DeFi security (access control, bridge hacks, rug pulls) but does not address quantum-cryptographic threats or audit the PQ prototype. The USENIX Security '25 paper audits consensus correctness (Fast Finality) but not cryptographic implementation.

Per QRI v3.1, the absence of an independent audit for a prototype-stage implementation reduces the Implementation Score to 0.00 for this subfactor. An audit would be required before any production deployment claim.

• https://hacken.io/insights/bnb-security-report/

Claim: BSC is open source (Golang, go-ethereum fork). The PQ migration report references GitHub PR #3660 for the prototype implementation. The main BSC repository is publicly accessible.

Coverage basis: Prototype — open-source codebase with referenced PQ PR; prototype code not confirmed in main branch

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: PR #3660 could not be independently located at the expected GitHub URL. The BSC repository is actively maintained (3K+ stars, frequent commits). The prototype code is referenced but its current branch location is unclear.

The report states the prototype 'remains compatible with existing addresses, RPCs, SDKs, wallets, and transaction flows,' suggesting the implementation is a fork/modification of the standard BSC client.

• https://github.com/bnb-chain/bsc
• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: The PQ migration report discusses algorithm selection rationale and acknowledges that higher-security variants (ML-DSA-65, ML-DSA-87) could be needed in the future. However, no formal parameter agility documentation or upgrade path specification exists.

Coverage basis: Design/research — algorithm selection discussed; no formal agility specification

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The report acknowledges that ML-DSA-44 provides 'sufficient protection within a 10–20 year horizon' and that higher-security variants would increase signature sizes by up to 90%. This is a qualitative discussion, not a formal agility specification.

Parameter agility would be important for a production deployment given the evolving NIST PQC standards and the performance constraints documented in the prototype.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: ML-DSA-44 (Dilithium) is a stateless signature scheme and does not have stateful-signature concerns (no state management, anti-reuse controls, or signing-state discipline required).

Coverage basis: Satisfied by design — ML-DSA is stateless; no stateful-signature risks apply

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA's stateless property is inherent to the algorithm design and NIST standardization. However, implementation-level side-channel and fault-injection risks remain unaddressed in the absence of an independent audit.

While ML-DSA is stateless, side-channel resistance and fault-injection considerations for lattice-based schemes are implementation-dependent and have not been independently reviewed for the BSC prototype.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report

Claim: The PQ migration report provides detailed performance benchmarks: transaction size increase (110 B → ~2.5 KB), block size increase (~110 KB → ~2 MB), TPS drop (4,973 → 2,997), cross-region latency measurements, and pqSTARK compression ratio (~43:1).

Coverage basis: Comprehensive — detailed performance analysis with multiple metrics and cross-region testing

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Performance data is self-reported by BNB Chain. Independent reproduction has not been identified. The measurements are from a prototype/test environment, not production mainnet conditions.

The report identifies the primary bottleneck as network propagation of larger blocks rather than signature verification CPU cost. This is a valuable finding for prioritizing optimization work. The ~18× block size increase is the most significant deployment barrier identified.

• https://www.bnbchain.org/en/blog/bsc-post-quantum-cryptography-migration-report
• https://blockonomi.com/bnb-chain-maps-out-post-quantum-cryptography-migration-path-for-bnb-smart-chain/
• https://crypto-economy.com/bnb-chain-explores-post-quantum-cryptography-for-future-smart-chain-security/