Post-quantum privacy-preserving L1 chain
Abelian ABEL
Abelian is a PQ-native Layer 1 blockchain launched on April 17, 2022, with mandatory lattice-based post-quantum spend authorization, privacy, and state-integrity mechanisms from genesis. It has no classical (ECC/BLS/Schnorr/EdDSA) native ownership namespace, so ECC-to-PQC migration is complete by design for the native ABEL asset. The underlying signature scheme uses NIST-standardized CRYSTALS-Dilithium (Dilithium-3, FIPS 204). All critical applicable layers — spend authorization, address/key exposure, state integrity, privacy/proof layers — are PQ-protected by default. The PoW consensus uses an Ethash-based hybrid (ABEL-ETHash / ABEL-Nakamoto) and does not require validator signatures, making validator-authentication subfactors N/A. The primary QRI constraint is Algorithm & Implementation Assurance: the privacy-preserving layer uses bespoke lattice-based linkable ring signatures, zero-knowledge proofs, and commitment schemes that are inspired by but not identical to NIST FIPS 203/204/205 standards, and no public independent cryptographic implementation audit has been identified for these deployed constructions. This triggers the Readiness & Risk Cap of 75, limiting the QRI Score below the raw Factor Score of 89.15. A current, in-scope independent audit of the deployed cryptographic implementations would be the highest-impact action to raise the score.
PQ-NativePQ-ResistantPrivacy-Preserving
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
11.25 / 20
Migration Mechanism, Governance & Ecosystem Coordination
13.5 / 15
Migration Status & Value-at-Risk
25 / 25
Production Cryptographic Protection
34.4 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- The privacy-preserving layer (lattice-based linkable ring signatures, ZK range proofs, homomorphic commitments) uses bespoke academic constructions rather than exact NIST FIPS 204 standardized algorithms, and no public independent cryptographic audit of these specific deployed implementations has been confirmed. This triggers the Readiness & Risk Cap of 75.
Key Risks
- Bespoke lattice-based linkable ring signature, ZK proof, and commitment schemes lack a public independent cryptographic implementation audit, creating quantum-critical uncertainty about the correctness and quantum-resistance of the deployed privacy layer.
- Algorithm agility for a potential future PQ-to-PQ upgrade is documented in the Blanc Fork roadmap but not yet demonstrated in production.
- No formal side-channel, fault-injection, or state-management security review is publicly available for the lattice-based signature implementations.
- QDay L2 and its bridge infrastructure introduce cross-chain dependencies; the QDay Bridge currently connects to non-PQ-secure chains for stablecoin bridging, which could become a quantum-vulnerable pathway if ABEL value flows through it.
Assurance Notes
- Abelian's underlying signature scheme is CRYSTALS-Dilithium (Dilithium-3, NIST FIPS 204), but the privacy-preserving ring signature, commitment, and zero-knowledge proof constructions are bespoke academic lattice-based designs, not exact NIST standards.
- No public independent cryptographic audit of the deployed bespoke lattice-based ring signature, ZK proof, or commitment scheme implementations has been confirmed. A Hacken 'design' audit is mentioned in community sources but no public report or scope confirmation is available as of 2026-06-01.
- The Quantum Canary independent assessment (February 2026) lists Abelian as using Dilithium-3 (L3) on mainnet.
- ESORICS 2019 peer-reviewed academic paper covers the lattice-based linkable ring signature design.
- Audit gap and bespoke constructions trigger the Readiness & Risk Cap of 75 for 'PQC design relies primarily on bespoke, unaudited, or weakly reviewed cryptography.'
- No formal side-channel analysis, fault-injection review, or hardware-wallet/HSM security evaluation is publicly documented.
- No formal quantum-specific incident-response playbook is publicly documented.
- PQZK Bridge to non-PQ chains remains in yellow-paper/roadmap phase; exact mainnet operational status and audit coverage are unclear.
Non-Scoring Caveats
- QDay L2 is live on mainnet (PoS, EVM-compatible) but its quantum-resistant rollup path depends on future PQZK Bridge upgrade. This is a roadmap/operational note for the current L1 production scope.
- PQZK Bridge remains in yellow-paper/roadmap phase as of 2026-06-01; no mainnet deployment confirmed.
- Exchange listings exist (MEXC, BitMart, XT.com, SuperEx, Coinstore) but no exchange has published a PQ-custody attestation specific to Abelian. Since the native protocol makes classical ownership impossible, this is a note-only operational caveat per Section 7.1.
- Future protocol upgrades (Aconcagua Fork, Blanc Fork for PQ cryptographic agility) are roadmap items for the current PQ-secure production system and do not indicate a current quantum vulnerability.
- Desktop and mobile wallets support the PQ-native path by default. No HSM or hardware-wallet integration is documented.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: Abelian whitepaper (v1.0, 2022) provides a comprehensive cryptographic inventory covering all lattice-based primitives, security models, and quantum threat model.
Coverage basis: PQ-native by design; documentation satisfies assessment preparedness for the native asset.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Whitepaper is from 2022. Design documentation is detailed but no formal third-party review of the threat model is attested.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: Open-source code on GitHub (pqabelian org, 19 repos), active mainnet explorer, community documentation, and the whitepaper provide reproducible evidence.
Coverage basis: Open-source code, mainnet explorer, documentation.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Code is public and active; no independent audit report links the code to the whitepaper claims.
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Abelian uses lattice-based linkable ring signatures for spend authorization. All transactions on mainnet since genesis (April 2022) use lattice-based PQ signatures exclusively. The underlying signature scheme uses CRYSTALS-Dilithium (Dilithium-3, FIPS 204).
Coverage basis: PQ-native by design; no classical signature path exists.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Mainnet is active with observable blocks/transactions. Quantum Canary (Feb 2026) lists Abelian as using Dilithium-3 (L3). The privacy-preserving ring signature constructions are bespoke.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Abelian uses one-time stealth addresses derived from lattice-based pseudonym addresses. Each transaction generates a fresh coin address, preventing long-exposure public-key reuse. Key derivation is lattice-based.
Coverage basis: PQ-native by design; one-time addresses prevent classical long-exposure key vulnerabilities.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Design documented in whitepaper; SDK code shows address derivation. No independent review of key-derivation implementation.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Abelian uses Proof-of-Work (ABEL-ETHash / ABEL-Nakamoto hybrid). No validator signatures, VRFs, or threshold signatures are used for consensus.
Coverage basis: PoW chain with no validator authentication layer.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Abelian uses lattice-based commitment schemes for coin value hiding, lattice-based zero-knowledge range proofs for double-spending prevention, and hash-based chain integrity. No KZG/pairing-based commitments are used.
Coverage basis: PQ-native; all state-binding mechanisms are lattice-based or hash-based.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Whitepaper provides formal security definitions; implementation is open-source but unaudited.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable
Claim: Abelian's full-privacy mode uses lattice-based linkable ring signatures, lattice-based ZK range proofs, and lattice-based commitments for sender anonymity, amount hiding, and untraceability. No pairing-based proof systems (e.g., Groth16/PLONK) are used.
Coverage basis: PQ-native; all privacy/proof primitives are lattice-based.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Privacy features are documented and active on mainnet. No independent privacy audit exists.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: Abelian's P2P node identity is not consensus-critical. All asset-spending authorization is PQ-signed on-device. Network identity is not spend, bridge, or custody-critical.
Coverage basis: Satisfied by design per Section 7: P2P node identity is not consensus, spend, bridge, or custody-critical.
Implementation score: 1 · Evidence confidence: Low
Issue classification: none · Score treatment: not applicable
Assurance: Limited public documentation on P2P identity mechanism. Confidence Low.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: Desktop wallet (Windows, macOS, Linux), mobile wallet (iOS, Android), and CLI wallet support the PQ-native path by default. No HSM or hardware-wallet integration is documented.
Coverage basis: PQ-native wallet support exists for software wallets; no HSM path documented.
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Software wallets support PQ-native key generation and signing. No HSM, hardware wallet, or custody-grade signer integration is documented. This is an assurance/operational gap, not a quantum-critical vulnerability for the native asset.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: Abelian is PQ-native with no classical native ownership namespace. 100% of native ABEL supply is PQ-protected by design.
Coverage basis: PQ-native; migration complete by design for the native asset.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: All native ABEL value is PQ-protected by construction.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: All native ABEL wallets, including treasury, exchange-held, and foundation wallets, are PQ-native by design. No classical wallet path exists on the Abelian L1.
Coverage basis: PQ-native; all critical wallets inherently protected.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Exchanges (MEXC, BitMart, XT.com, SuperEx) have not published PQ-custody attestations specific to Abelian. This is a note-only caveat per Section 7.1 since the protocol makes classical custody impossible.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No legacy vulnerable pools exist on Abelian L1. All addresses and UTXOs are lattice-based from genesis. No classical key format, address type, or ownership path was ever supported.
Coverage basis: PQ-native; no legacy vulnerable pools exist by design.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Confirmed by genesis documentation, whitepaper, and the absence of any ECC/BLS/Schnorr/EdDSA address format in code or explorer.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Abelian is PQ-native; ECC-to-PQC migration is complete by design. Roadmap exists for PQ-to-PQ upgrades (Aconcagua Fork, Blanc Fork for cryptographic agility).
Coverage basis: PQ-native; migration roadmap is satisfied by design for native asset.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Roadmap is publicly documented on the official website. Future upgrades (Blanc Fork) are planned but not required for current quantum safety.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths are available, default, or complete by design
Claim: All account creation on Abelian is PQ-native by default. Desktop, mobile, and CLI wallets generate only lattice-based keys. No classical account creation path exists.
Coverage basis: PQ-native; PQ account creation is the only option.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Wallets are open-source. No independent wallet security audit exists.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms exist and ecosystem coordination prevents unsafe fallback
Claim: No unsafe fallback into classical systems exists for native ABEL. Protocol enforces lattice-based signatures for all transactions. Exchanges listing ABEL operate on the PQ-native chain.
Coverage basis: PQ-native; enforcement is inherent in protocol design.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: No exchange has published a formal migration attestation, but this is not required for a PQ-native asset per Section 7.1.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No formal quantum-specific incident-response playbook or emergency governance process is publicly documented. General incident response capability demonstrated through Telegram breach handling (June 2024).
Coverage basis: Limited evidence of incident-response processes; no quantum-specific IR plan.
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: General incident response capability is evidenced but no quantum-specific IR plan is publicly available. Per Section 8.2, this is not a cap-applying condition by itself.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: The underlying signature scheme uses NIST-standardized CRYSTALS-Dilithium (Dilithium-3, FIPS 204). The privacy-preserving ring signature, commitment, and ZK proof constructions are bespoke academic designs inspired by Dilithium/Kyber but not exact NIST FIPS standards.
Coverage basis: Hybrid: NIST-standardized underlying scheme with bespoke privacy constructions.
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Underlying Dilithium-3 is NIST-standardized. Privacy constructions are bespoke but based on the same lattice assumptions (Module-LWE/SIS). Academic papers (ESORICS 2019) provide peer review. Score 0.75 reflects broadly reviewed academic lattice-based cryptography with NIST-standardized base.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: A Hacken 'design' audit is mentioned in community sources, but no public audit report, scope confirmation, or implementation audit is available as of 2026-06-01.
Coverage basis: No public independent cryptographic implementation audit identified.
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: cap-applying
Quantum blocker: No public independent cryptographic implementation audit exists for the deployed bespoke lattice-based privacy constructions. This directly triggers the Readiness & Risk Cap of 75.
Assurance: A Hacken audit of the 'design' is mentioned in secondary sources but no public report, scope, or depth confirmation is available. The evidence confidence for the audit claim is Very Low.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Core node (abec), wallets (abewallet, abewalletmlp), SDKs, and mining software are publicly available on GitHub under the pqabelian organization. Active development through 2026.
Coverage basis: Open-source code on GitHub with ongoing maintenance.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Code is publicly accessible and actively maintained. No build reproducibility attestation exists.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: Abelian has demonstrated cryptographic upgrade capability through a hard fork at block 300,000 (MLP/AUT upgrade, cryptographic scheme v0 to v1). The Blanc Fork roadmap item explicitly targets post-quantum cryptographic agility.
Coverage basis: Demonstrated hard fork capability; planned Blanc Fork for PQ agility.
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Hard fork at block 300,000 demonstrated upgrade capability. Blanc Fork for PQ agility is a roadmap item, not yet deployed. Score 0.75 reflects proven upgrade path but future agility not yet production-tested.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: Abelian's lattice-based signatures are not stateful (not XMSS/LMS-style). No public side-channel analysis, fault-injection review, or hardware-wallet/HSM security evaluation is documented.
Coverage basis: No public security analysis beyond academic design papers.
Implementation score: 0.25 · Evidence confidence: Very Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: No public evidence of side-channel or fault-injection consideration. Lattice-based signatures are not stateful, so anti-reuse controls are less critical than for XMSS/LMS, but side-channel risks remain unaddressed.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No formal performance benchmarking or resource-impact analysis is publicly available. Anecdotal evidence from SDK examples shows ~10KB address sizes, indicating significant storage overhead.
Coverage basis: Anecdotal size data from SDK; no formal analysis.
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Address sizes of ~10KB and large transaction sizes are evident from SDK examples. No formal analysis of block validation time, archival growth, or node hardware requirements exists. This is an assurance-only caveat per Section 8.2.
Report metadata