blockchain network
Quranium QRN
Quranium claims to be a PQ-native Layer 1 blockchain using SLH-DSA (SPHINCS+) for transaction signatures with EVM compatibility. A verifiable public testnet exists with active transaction activity, and developer tooling (QSafe wallet documentation, Hardhat deploy scripts) demonstrates SLH-DSA signing capabilities. However, the project's mainnet status is unverifiable and contradicted by its own roadmap, press releases, and CoinMarketCap data (0 circulating supply). Core node software, consensus mechanisms, and protocol specifications remain closed-source. The claimed CertiK audit has no publicly accessible report. EVM compatibility raises unresolved questions about classical fallback paths. The project is currently at Stage 2 (Mitigation / Development) with a score of 25, reflecting the verifiable testnet prototype but severe quantum-critical uncertainty regarding production enforcement.
PrototypePQ-Native Claim (Unverifiable)Roadmap Only
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
6.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
4 / 15
Migration Status & Value-at-Risk
3.75 / 25
Production Cryptographic Protection
8.5 / 35
Security Assessment & Evidence Preparedness
2.5 / 5
Critical Quantum Blockers
- No verifiable public mainnet or open-source node software to confirm SLH-DSA enforcement or absence of classical fallback paths.
- Unverifiable CertiK audit claims; no public audit report available for core protocol or PQC integration.
- EVM compatibility introduces potential classical ECC paths (e.g., ecrecover) that are not documented as disabled or overridden.
Key Risks
- Closed-source core protocol prevents independent verification of SLH-DSA enforcement and absence of classical ECC fallback paths.
- EVM compatibility may expose quantum-vulnerable smart contract interactions if classical opcodes like ecrecover are not disabled.
- Unverifiable audit claims create false assurance for institutional investors and users.
- Contradictory mainnet launch announcements across different sources suggest unclear production readiness.
- No verifiable mainnet explorer or transaction telemetry exists to confirm PQ signatures are mandatory on all spend paths.
Assurance Notes
- No public mainnet explorer exists; only testnet.qrnscan.com is verifiable with active transaction activity.
- Core node software, consensus implementation, and protocol specifications are closed-source and not publicly reproducible.
- CEO claims CertiK audit completion (August 2025 per whitepaper), but CertiK Skynet lists the project under 'Pre-Launch' with no public audit report accessible.
- EVM compatibility claims lack documentation on whether classical opcodes (e.g., ecrecover) are disabled or overridden to prevent quantum-vulnerable fallback paths.
- Mainnet launch status is contradicted by multiple sources: roadmap shows PoW mainnet 'live' Q1 2025 but also 'Mainnet Launch of Quranium Layer 1' as planned Q3 2025; whitepaper targets TGE/Mainnet September 2025; CoinMarketCap shows 0 circulating supply as of evaluation date.
- Whitepaper indicates TGE starting date 2025-09-26 with ~1.95% of max supply minted at TGE, but no verifiable on-chain evidence of TGE execution exists.
Non-Scoring Caveats
- Marketing materials heavily emphasize AI-native features and institutional partnerships, which do not contribute to QRI scoring.
- QSafe wallet is available as binary downloads only; source code for the wallet's PQC integration is not publicly auditable.
- CoinMarketCap lists QRN as a 'preview page' with 0 circulating supply, suggesting TGE may not have executed as of evaluation date.
- Project roadmap timeline is internally inconsistent across different pages (mainnet live Q1 2025 vs planned Q3 2025 vs TGE September 2025).
Evidence record
Claims and Caveats
Transaction
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Uses SLH-DSA (SPHINCS+) for transaction signatures. QSafe wallet documentation confirms SLH-DSA signing with 49,856-byte signatures for testnet transactions.
Coverage basis: PQ-native claim
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No verifiable public mainnet or open-source node software to confirm SLH-DSA enforcement on mainnet.
Assurance: Implementation score lowered to 0.50 (Prototype/Testnet) because mainnet status is unverifiable and core node code is closed-source. Testnet signing confirmed via QSafe documentation and deploy scripts.
QSafe wallet docs show SLH-DSA signing with Keccak-256 hash then SLHDSA signature. Deploy script uses @noble/post-quantum library. Mainnet enforcement cannot be verified.
Account/Address
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: QSafe uses BIP39 mnemonic to generate PQ keypair. Addresses derived via Keccak-256 hash of SLH-DSA public key.
Coverage basis: PQ-native claim
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: EVM compatibility may allow classical account models; no documentation confirms absence of classical ownership paths.
Assurance: Scored as public design/claim only (0.25). No protocol specification or mainnet address format documentation available.
QSafe docs describe address derivation from SLH-DSA public key, but no documentation confirms whether EVM compatibility introduces classical ECC-based account paths.
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: PoS consensus with validator protocol. Marketing claims quantum-secure consensus.
Coverage basis: PQ-native claim
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Scored as public design/claim only (0.25) due to absence of consensus code or validator protocol specifications in accessible form.
Marketing mentions PoS and SLH-DSA, but no technical details on validator signatures, BLS replacement, or finality mechanisms are available.
State Integrity
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: EVM-compatible Layer 1 with quantum-secure smart contracts.
Coverage basis: EVM compatibility claim
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: EVM compatibility introduces potential classical ECC paths (e.g., ecrecover) that are not documented as disabled or overridden.
Assurance: EVM compatibility typically implies classical account models and opcodes. No documentation confirms ecrecover is disabled or replaced with PQ verification.
If ecrecover remains active, smart contracts relying on classical signature verification remain quantum-vulnerable.
P2P
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: Decentralized P2P stack inspired by devp2p/libp2p, enhanced with post-quantum protections.
Coverage basis: PQ-native claim
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Only marketing press release mentions PQ-enhanced P2P. No technical specification available.
P2P PQ protection claimed in marketing materials but not verifiable from any primary source.
Wallet/Custody
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: QSafe wallet supports SLH-DSA signing for Quranium chain transactions. Binary downloads available.
Coverage basis: PQ-native claim
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: QSafe wallet exists with SLH-DSA signing capability per documentation. Binary-only distribution; no public source code for wallet PQC integration.
QSafe wallet docs confirm SLH-DSA signing. Wallet is available as binary downloads only.
Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: PQ-native claim: no classical ownership namespace for native asset. TGE targeted September 2025 but CoinMarketCap shows 0 circulating supply.
Coverage basis: PQ-native claim (unverifiable)
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: PQ-native claim cannot be verified; no mainnet explorer, no verifiable TGE, and 0 circulating supply on CoinMarketCap.
Assurance: If TGE did not occur or circulating supply is 0, value-at-risk is negligible. PQ-native claim still requires verification for scoring purposes.
Whitepaper states TGE date 2025-09-26 with ~1.95% of max supply minted. CoinMarketCap shows 0 supply as of evaluation date. Cannot verify actual mainnet status or circulating supply.
Algorithm
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: Adopts SLH-DSA (SPHINCS+), a NIST-standardized post-quantum signature scheme. Developer tooling confirms use of @noble/post-quantum.
Coverage basis: Algorithm selection
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: SLH-DSA is a NIST-standardized algorithm (FIPS 205). Developer tooling confirms use of @noble/post-quantum library for SLH-DSA signing.
Algorithm choice is sound and conservative (hash-based), but integration assurance is lacking due to closed-source node.
Audit
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: Chain has undergone and passed a comprehensive audit by CertiK (August 2025 per whitepaper). CEO confirms in interview.
Coverage basis: Audit claim
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: Unverifiable CertiK audit claims; no public audit report available for core protocol or PQC integration.
Assurance: CEO claims CertiK audit completion. Whitepaper states 'CertiK completed a full security audit of the Quranium codebase on August 16, 2025'. However, CertiK Skynet lists project under 'Pre-Launch' with no public audit report. No public report link found.
Audit claim is treated as unsubstantiated until a public report is released. Score 0.00 because no verifiable independent audit exists.
Code
Open-source, reproducible implementation
Claim: GitHub org has 5 repos (smart-contracts-example, deploy-script-hardhat, qsafe-download, trezor-hardware, private). Core node is closed-source.
Coverage basis: Partial open-source
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Only developer tooling and wallet binaries are public. Core node, consensus, and PQC integration code are closed-source.
GitHub org contains 5 repos, none of which include core protocol implementation. smart-contracts-example explicitly states contracts are 'not audited' and 'experimental'.
Migration Roadmap
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Detailed roadmap published on website showing phased rollout from PoW testnet through mainnet to institutional infrastructure.
Coverage basis: Roadmap documentation
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Roadmap exists but timeline is internally inconsistent across pages.
Roadmap shows phased development from PoW testnet through PoS mainnet to institutional infrastructure. Timeline contradictions exist between different pages.
Migration Accessibility
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling available
Claim: QSafe wallet available for download. Testnet faucet available. EVM-compatible contract deployment via QRemix AI.
Coverage basis: Prototype tooling
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: QSafe wallet and QRemix AI tooling exist for testnet. No evidence of mainnet migration tools.
Wallet and developer tools are available but limited to testnet scope.
Report metadata