Beldex BDX

Claim: Beldex roadmap acknowledges quantum risk (PQC research begins Q2 2026, lattice POC Q3 2026, quantum‑safe hardfork Q1 2027) and blog posts discuss 'harvest now, decrypt later' threat. No formal cryptographic inventory or quantum threat model published.

Coverage basis: Partial: roadmap entries and blog posts acknowledge quantum risk; whitepaper inventories classical crypto but lacks quantum threat model

Implementation score: 0.25 · Evidence confidence: Medium

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

Quantum blocker: No formal public cryptographic inventory with quantum threat model covering all critical layers exists

Assurance: Roadmap items are planned/marketing only. No standalone threat‑model document published. Blog posts and roadmap entries constitute the only quantum‑risk acknowledgement.

Whitepaper v3.1.2 (2024) describes EdDSA, ring signatures, stealth addresses, RingCT, and Bulletproofs but makes zero mention of quantum threats or PQC. Quantum‑risk acknowledgment appears only in 2026 marketing and roadmap content.

• https://www.beldex.io/roadmap
• https://coinpedia.org/information/privacy-infrastructure-is-becoming-inevitable-and-this-project-is-building-it/
• https://www.mexc.com/news/privacy-infrastructure-is-becoming-inevitable-and-this-project-is-building-it

Claim: Evidence exists in the form of open‑source code (GitHub, Monero fork), whitepaper, explorer data, roadmap page, and secondary coverage confirming classical crypto usage.

Coverage basis: Partial: code and whitepaper verify classical crypto; no PQC evidence artifacts exist

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Code is open source (C++, Monero fork). CertiK audit from 2022 exists but is stale and audit scope was masternode rules, not core crypto. No current independent review of cryptographic implementation.

GitHub repo confirms libsodium dependency and Monero heritage. Last release v7.0.1 (Feb 2026). No PQC libraries, references, or branches found.

• https://github.com/Beldex-Coin/beldex
• https://beldex.io/whitepaper.pdf
• https://explorer.beldex.io/
• https://skynet.certik.com/projects/beldex

Claim: Beldex uses Ed25519/EdDSA (via libsodium) with CLSAG ring signatures for spend authorization. No PQC or hybrid‑PQC signatures exist on mainnet.

Coverage basis: None: entirely classical ECC

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All spend authorization uses Ed25519/EdDSA — fully breakable by Shor's algorithm

Assurance: High confidence: both whitepaper and developer AMA explicitly confirm ED25519 signature system. GitHub code confirms libsodium‑based EdDSA implementation.

CLSAG (Concise Linkable Spontaneous Anonymous Group) ring signatures used since Bucephalus hardfork (Dec 2021). Ring size fixed at 11. Entirely ECC‑dependent.

• https://beldex.io/whitepaper.pdf
• https://github.com/Beldex-Coin/beldex
• https://medium.com/@beldexcoin/combining-defi-and-privacy-ama-interview-with-the-devs-of-beldex-bdx-pt-1
• https://beldex.io/blog/a-deep-dive-into-beldex-cores-confidentiality-framework/

Claim: Beldex uses CryptoNote‑style stealth addresses with Diffie‑Hellman key exchange (ECC‑based). One‑time public keys are recorded permanently on‑chain, creating long‑exposure quantum‑vulnerable targets. All key derivation is Ed25519‑based.

Coverage basis: None: entirely classical ECC with long‑exposure public keys

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All on‑chain one‑time public keys are permanently exposed ECC keys vulnerable to offline quantum attack

Assurance: High confidence: stealth address mechanism is standard CryptoNote (Monero‑style) using Ed25519 curve. Every transaction output exposes a one‑time public key permanently on‑chain.

Long‑exposure at‑rest risk: unlike Bitcoin P2PKH where the public key is only revealed on spend, Beldex one‑time public keys are part of every transaction output and are immediately visible on‑chain. This means all historical outputs are targets for 'harvest now, decrypt later' attacks.

• https://beldex.io/whitepaper.pdf
• https://beldex.io/blog/a-deep-dive-into-beldex-cores-confidentiality-framework/
• https://explorer.beldex.io/

Claim: Beldex uses a masternode‑based PoS consensus with classical signatures for block proposal, validation, and quorum coordination. The planned VRF hardfork (Q1 2026 roadmap) introduces VRF‑based randomness but does not change the underlying classical signature scheme.

Coverage basis: None: entirely classical signature‑based consensus

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Masternode validator signatures are classical ECC; quantum compromise of validator keys could enable consensus attacks

Assurance: High confidence: PoS consensus with 11+1 quorum uses deterministic validator selection with classical signatures. VRF upgrade plans do not include PQ signature migration.

VRF hardfork was planned for Q1 2026 but roadmap shows it as 'Planned' — deployment status unclear as of evaluation date. In any case, VRF addresses randomness/unpredictability, not quantum‑safe signatures. Masternode count: ~2551 active (explorer data).

• https://beldex.io/blog/why-is-beldex-adopting-vrf-based-consensus-in-2026/
• https://beldex.io/blog/a-deep-dive-into-beldex-cores-confidentiality-framework/
• https://github.com/Beldex-Coin/beldex

Claim: Beldex uses RingCT with Pedersen commitments (ECC‑based) and Bulletproofs++ for range proofs. Both rely on the hardness of the elliptic curve discrete logarithm problem. No quantum‑safe commitment scheme or proof system exists.

Coverage basis: None: entirely classical ECC‑based state‑integrity mechanisms

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: RingCT Pedersen commitments and Bulletproofs++ are ECC‑based; quantum attacks could forge proofs, enable inflation, or retroactively reveal amounts

Assurance: High confidence: Bulletproofs++ deployed via Obscura hardfork (Dec 2025). All range proofs and commitments are built on ECC hardness assumptions.

Bulletproofs++ improved proof efficiency (~38% smaller than standard Bulletproofs) but do not change the underlying cryptographic hardness assumptions — still ECC‑dependent. No hash‑based or lattice‑based state‑integrity mechanism exists.

• https://beldex.io/whitepaper.pdf
• https://hackernoon.com/obscura-brings-bulletproofs-to-the-beldex-mainnet-for-sustainable-scaling
• https://beldex.io/blog/beldex-research-labs-update-2025/

Claim: Beldex's privacy model uses ring signatures (CLSAG) for sender anonymity, stealth addresses for receiver anonymity, and RingCT/Bulletproofs++ for amount confidentiality. All mechanisms are ECC‑based with no quantum‑safe alternatives.

Coverage basis: None: all privacy layers are ECC‑dependent

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Quantum attacks on ECC could retroactively deanonymize all historical transactions by breaking ring signatures and stealth addresses

Assurance: High confidence: ring signatures (CLSAG), stealth addresses (ECDH), and RingCT are all ECC‑based primitives well‑documented in the whitepaper and code.

Privacy is particularly vulnerable to 'harvest now, decrypt later' — an adversary storing all encrypted/obfuscated blockchain data today could retroactively deanonymize all transactions once a CRQC becomes available. Beldex acknowledges this threat model for BChat messaging but has not yet addressed it for on‑chain transaction privacy.

• https://beldex.io/whitepaper.pdf
• https://beldex.io/blog/a-deep-dive-into-beldex-cores-confidentiality-framework/
• https://cryptopotato.com/beldex-explained-a-guide-to-its-privacy-focused-blockchain-ecosystem/

Claim: Beldex uses libsodium for P2P networking. Node identity and peer authentication rely on classical cryptography (Ed25519 keys). Dandelion++ network‑layer privacy upgrade is planned but does not introduce quantum‑safe authentication.

Coverage basis: None: classical P2P authentication

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity is not spend‑critical or consensus‑critical in the same way as transaction signatures. However, node impersonation via quantum attacks could enable eclipse attacks, transaction censorship, or network‑level deanonymization.

Dandelion++ (announced March 2026 for integration) addresses network‑layer transaction origin privacy but does not introduce quantum‑safe node authentication. P2P authentication remains classical.

• https://github.com/Beldex-Coin/beldex
• https://beldexcoin.medium.com/dandelion-advanced-network-obfuscation-for-beldex-7768564a6e20

Claim: No Beldex wallet supports PQ or hybrid‑PQC signing. All wallet software (Beldex Wallet, CLI wallet) uses Ed25519 key generation and signing exclusively.

Coverage basis: None: no PQ wallet or HSM support

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No hardware wallet (Ledger, Trezor, etc.) integration for BDX with PQ signing paths exists. Mobile/desktop wallets are Ed25519‑only.

This is a derivative vulnerability: wallets cannot support PQ signing because the protocol itself has no PQ signing mechanism.

• https://github.com/Beldex-Coin/beldex
• https://beldex.io/

Claim: 0% of BDX value‑at‑risk is protected from quantum key‑recovery attacks. All ~$620M market cap (~10.65M BDX circulating supply) is secured exclusively by classical ECC. Masternode stakes (10,000 BDX each, ~2551 active masternodes = ~25.5M BDX staked) are also entirely ECC‑vulnerable.

Coverage basis: <25%: entire circulating supply and all staked value remains ECC‑only

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 100% of native BDX value‑at‑risk (~$620M) is quantum‑vulnerable with no migration path

Assurance: Market cap derived from CertiK Skynet data ($619.76M) and explorer circulating supply (~10.65M BDX). Staked masternode value estimated at ~$200M+ based on 2551 active nodes × 10,000 BDX each. All value is classical ECC‑protected only.

Privacy‑preserving design means individual address balances are not publicly observable, complicating precise value‑at‑risk measurement. However, the protocol‑level cryptographic vulnerability applies uniformly to all outputs.

• https://explorer.beldex.io/
• https://skynet.certik.com/projects/beldex
• https://beldex.io/blog/bdx-scheduled-release-march-31-2026/

Claim: No treasuries, exchanges, custodians, bridges, foundations, or major protocol wallets have been migrated to or are protected by PQC. No PQ‑native protection exists for any critical wallet.

Coverage basis: None: zero critical wallets protected

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Foundation treasury (37.5% of block rewards), exchange‑held BDX, and bridge‑controlled BDX are all ECC‑only

Assurance: Beldex foundation receives 37.5% of block rewards (3.75 BDX per block). No public attestation of PQ‑safe custody for foundation treasury exists.

Bridge contracts (BSC wBDX, LayerZero OFT) hold native BDX in custody on the classical Beldex chain. These custody wallets are quantum‑vulnerable.

• https://explorer.beldex.io/
• https://beldex.io/blog/bdx-scheduled-release-march-31-2026/

Claim: No legacy vulnerable pool has been identified, measured, deprecated, frozen, or addressed. No policy exists for handling unmigratable quantum‑vulnerable outputs.

Coverage basis: None: no identification, measurement, or policy

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No freeze, burn, deprecation, or salvage policy for dormant quantum‑vulnerable holdings exists

Assurance: Roadmap does not mention any legacy output deprecation or frozen‑asset policy. Privacy model makes individual output identification difficult.

As a privacy chain, identifying dormant or lost outputs is inherently challenging. This complicates any future migration measurement and enforcement.

• https://www.beldex.io/roadmap

Claim: Beldex 2026‑2027 roadmap includes: Q2 2026 'Research on post‑quantum cryptography begins', Q3 2026 'First POC on lattice‑based cryptography', Q1 2027 'Quantum‑safe hardfork release'. No detailed sequencing, activation criteria, or dependency analysis is published.

Coverage basis: Roadmap only: high‑level milestones, no detailed migration plan

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Roadmap is marketing‑level content with explicit disclaimer that items are subject to change. No technical specification, algorithm selection, or implementation plan exists for the quantum‑safe hardfork.

The roadmap mentions 'lattice‑based cryptography' for the Q3 2026 POC, suggesting a direction, but no specific algorithm (e.g., CRYSTALS‑Dilithium, Falcon, SPHINCS+) has been selected or specified.

• https://www.beldex.io/roadmap
• https://coinpedia.org/information/privacy-infrastructure-is-becoming-inevitable-and-this-project-is-building-it/

Claim: No PQ/hybrid account creation, wallet tooling, custody paths, user warnings, or migration prompts exist. All wallets create Ed25519‑only accounts by default.

Coverage basis: None: no migration tooling or user‑facing migration support

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All new accounts are created with Ed25519 keys by default with no PQ alternative

Assurance: High confidence: GitHub code and wallet documentation confirm Ed25519‑only key generation. No wallet prompts users about quantum risk or offers PQ alternatives.

The absence of migration tooling means even if a quantum‑safe hardfork were deployed tomorrow, users would have no practical way to migrate their funds to PQ‑safe addresses.

• https://github.com/Beldex-Coin/beldex
• https://beldex.io/

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe‑path blocking, mandatory migration deadline) exist. No exchange, custody, bridge, wallet, or infrastructure coordination for quantum‑safe migration has been evidenced.

Coverage basis: None: no enforcement or coordination mechanisms

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No evidence of any coordination with exchanges (MEXC, Gate, KuCoin, etc. where BDX is listed) regarding quantum‑safe migration. Bridge operators (Beldex‑BSC bridge, LayerZero/Stargate) have published no quantum‑safety plans.

Given BDX's listing on multiple centralized exchanges, exchange coordination for any migration would be critical. No public coordination has been documented.

Claim: No formal quantum‑specific vulnerability disclosure process, incident‑response playbook, or emergency governance mechanism has been published.

Coverage basis: None: no quantum‑specific incident response process

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Beldex has a bug bounty program mentioned in the Q4 2025 roadmap but no quantum‑specific incident response framework. Note‑only because the absence of a playbook does not create a new quantum‑vulnerable path — the entire system is already vulnerable.

Note‑only per QRI v3.1 Section 7.4: lack of a formal quantum‑specific IR playbook does not reduce the score unless it leaves a current quantum‑vulnerable path unresolved. Here, all paths are already unresolved.

Claim: No PQC algorithms have been selected, implemented, or deployed. Roadmap mentions 'lattice‑based cryptography' for Q3 2026 POC without specifying any NIST‑standardized algorithm.

Coverage basis: None: no PQC algorithm selected

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No NIST‑standardized or broadly reviewed PQC algorithm has been selected

Assurance: Roadmap reference to 'lattice‑based cryptography' is non‑specific. NIST has standardized CRYSTALS‑Dilithium, FALCON, and SPHINCS+ for signatures, and CRYSTALS‑KYBER for KEMs. Beldex has not indicated which, if any, it will adopt.

The 'First POC on lattice‑based cryptography' milestone in Q3 2026 suggests an eventual direction but provides no technical specificity.

• https://www.beldex.io/roadmap

Claim: CertiK audit from May 2022 exists but audited masternode swarm/rules logic, not core cryptographic spend‑authorization or consensus code. Audit is stale (>4 years) and scope‑mismatched for quantum‑critical assessment. No PQC audit exists.

Coverage basis: None: no audit of quantum‑critical cryptographic implementation

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: CertiK audit (24 findings: 0 critical, 0 major, 3 medium, 9 minor, 12 informational) covered 10 files including master_node_swarm.h and master_node_rules.h. No core crypto review (Ed25519 signatures, RingCT, Bulletproofs, stealth addresses). Audit predates Obscura hardfork (Dec 2025) and all recent cryptographic changes.

Note‑only per QRI v3.1 Section 7.4: stale/scope‑mismatched audit does not reduce QRI score for a system where quantum‑critical properties are already unverifiable due to the complete absence of PQC. Would affect confidence for any future PQC implementation.

• https://skynet.certik.com/projects/beldex
• https://github.com/Beldex-Coin/beldex/releases/tag/v4.1.0

Claim: Beldex core code is open source (C++, Monero fork) on GitHub under a permissive license. Classical crypto implementation is publicly reviewable and reproducible. No PQC implementation exists to evaluate for reproducibility.

Coverage basis: Partial: classical code is open source; no PQC code exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Repository has 38 stars, 26 forks, 230 contributors. Build instructions publicly documented. Latest release v7.0.1 (Feb 2026). Code is C++ with vendored libsodium.

Classical code is open and buildable. Score of 0 reflects that no quantum‑critical PQC implementation exists to evaluate for open‑source reproducibility.

• https://github.com/Beldex-Coin/beldex

Claim: Roadmap indicates a quantum‑safe hardfork is planned for Q1 2027. No detailed upgrade path, parameter migration plan, or algorithm agility documentation has been published.

Coverage basis: Roadmap only: high‑level hardfork target with no technical upgrade path documentation

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Roadmap is marketing‑level only. No ZIP/BIP/EIP‑style proposal, no technical specification, no parameter or key‑format migration documentation exists.

Score of 0.25 reflects roadmap‑level acknowledgment of the need for an upgrade path without any technical documentation.

• https://www.beldex.io/roadmap

Claim: Not applicable: no PQC signature scheme has been selected, so no stateful‑signature safety analysis (e.g., for XMSS/LMS) or PQC‑specific side‑channel analysis exists.

Coverage basis: None: no PQC implementation to analyze

Implementation score: 0 · Evidence confidence: None

Issue classification: none · Score treatment: not applicable

Assurance: Until a specific PQC algorithm is selected and implemented, this subfactor cannot be meaningfully evaluated. Score 0 reflects the absence of any PQC implementation.

If Beldex selects a stateful hash‑based signature scheme like XMSS/LMS, state‑management discipline would become critical. This consideration is entirely premature given the current pre‑POC stage.

Claim: No performance or resource‑impact analysis for any PQC deployment has been published. No analysis of PQ signature sizes, verification costs, block‑size impact, gas/fee implications, or validator hardware requirements exists.

Coverage basis: None: no performance analysis for PQC

Implementation score: 0 · Evidence confidence: None

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

Assurance: Note‑only per QRI v3.1 Section 7.4: lack of a formal performance benchmark does not reduce QRI Score unless resource constraints prevent safe use of the PQ/hybrid path. No PQ path exists yet, so this is premature.

Beldex's dynamic block size range (300‑600 kB) and 30‑second block time would need to be evaluated against PQ signature sizes (e.g., CRYSTALS‑Dilithium signatures are ~2.4‑4.6 KB vs Ed25519's 64 bytes). This represents a ~40‑70x size increase that could significantly impact throughput.