Post-quantum privacy-preserving L1 chain
Abelian ABEL
Abelian is a PQ-native Layer 1 blockchain that launched in early 2022 with mandatory lattice-based post-quantum cryptography for all native asset ownership and spend authorization. The native ABEL asset has no classical ECC/BLS ownership namespace, making ECC-to-PQC migration complete by design. Spend authorization uses NIST-standardized Dilithium/ML-DSA-inspired lattice signatures for transparent (pseudonymous) transactions, and custom lattice-based linkable ring signatures for full-privacy transactions. Consensus is Proof-of-Work using quantum-resistant hash functions (ABEL-ETHash, ABEL-Nakamoto), eliminating validator signature vulnerabilities entirely. The mainnet is active (past block 480K), open-source (MIT-licensed Go implementation on GitHub), and supports multi-level privacy (full-private, pseudo-private, accountable). The primary assurance gap is the absence of any independent third-party cryptographic or implementation audit of the custom privacy-layer constructions, despite formal security proofs in the 2022 whitepaper by academic cryptographers. The QDay L2 and cross-chain bridges are outside the L1 native scope but may introduce classical quantum vulnerabilities for wrapped assets.
PQ-NativePQ-ResistantPrivacy-PreservingPoW
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
11 / 20
Migration Mechanism, Governance & Ecosystem Coordination
13.5 / 15
Migration Status & Value-at-Risk
25 / 25
Production Cryptographic Protection
34.5 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- Custom lattice-based linkable ring signature scheme used in full-privacy transaction spend path is bespoke cryptography without independent audit; a structural flaw could compromise both privacy and spend authorization for private transactions.
- QDay L2 bridge (wABEL) and cross-chain bridges to EVM networks likely depend on classical ECDSA-based controls, creating quantum-vulnerable value pools outside the PQ-native L1.
Key Risks
- Custom lattice-based linkable ring signature scheme used in full-privacy transaction spend path is bespoke cryptography without independent audit; a structural flaw could compromise both privacy and spend authorization for private transactions.
- No independent implementation audit of any quantum-critical component (core node, SDK, cryptographic primitives) despite mainnet operation since 2022.
- QDay L2 bridge (wABEL) and cross-chain bridges to EVM networks likely depend on classical ECDSA-based controls, creating quantum-vulnerable value pools outside the PQ-native L1.
- No hardware wallet or HSM support for PQ key material; all custody relies on software wallets with potential side-channel exposure.
- Large lattice-based signature sizes (~10KB addresses) drive significant state growth (190GB–1.4TB node storage), potentially affecting long-term decentralization and archival node viability.
Assurance Notes
- No independent third-party cryptographic or implementation audit of the Abelian L1 core (abec) or its custom lattice-based linkable ring signature, commitment, or ZK range-proof constructions has been located as of 2026-06-11.
- The 2022 whitepaper provides formal security definitions and proofs for the DAPOA scheme under lattice assumptions (LWE/Ring-LWE), and the founding team includes published academic cryptographers (e.g., co-inventor of linkable ring signatures), but this does not substitute for an independent implementation audit of production code.
- Custom lattice-based ring signature and ZK proof constructions used in the full-privacy transaction path are bespoke cryptography; while based on well-reviewed lattice assumptions, the specific constructions lack independent peer review of the deployed implementation.
- No hardware wallet or HSM support for Abelian's PQ key material has been documented; custody is limited to software wallets (Desktop Pro, Mobile Pro, CLI).
- QDay L2 and cross-chain bridge infrastructure (wABEL, QDay Bridge) are outside the evaluated L1 native scope but may introduce classical ECDSA-dependent quantum vulnerabilities for wrapped or bridged ABEL representations.
- Node storage requirements are substantial (190GB–1.4TB depending on node type), which is consistent with large lattice-based signature sizes but may affect decentralization and archival node viability.
- Abelian was named in the Google Quantum AI white paper (arXiv:2603.28846, March 2026) as one of three projects that have completed full PQC migration.
Non-Scoring Caveats
- No independent audit of the custom lattice-based privacy layer (ring signatures, commitments, ZK proofs) despite mainnet deployment since 2022.
- No hardware wallet or HSM integration for PQ key storage.
- QDay L2 bridge to EVM chains likely relies on classical ECDSA multisig or smart contract controls, exposing wrapped ABEL (wABEL) to quantum risk outside the L1 scope.
- Emergency quantum-specific incident-response playbook not documented.
- Formal performance benchmarks for lattice signature impact on state growth and node requirements not published.
- Telegram channel was compromised in June 2024 via phishing attack; operational security concerns noted.
Evidence record
Claims and Caveats
Transaction
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Abelian uses lattice-based cryptography (Dilithium/ML-DSA inspired) for transaction spend authorization on mainnet since 2022 launch.
Coverage basis: PQ-native mandatory PQC spend authorization
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Whitepaper describes Dilithium-based signatures; SDK code shows lattice-consistent key sizes (~10KB addresses). No independent audit of implementation. Confidence is Medium due to public code + mainnet evidence without independent audit.
Transparent (pseudonymous) transactions use standard Dilithium-inspired signatures. Full-privacy transactions use custom lattice ring signatures in the spend path.
Transaction
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: Abelian uses one-time coin addresses derived from pseudonym addresses via stealth address mechanism; no long-exposure classical public keys exist.
Coverage basis: PQ-native design with one-time lattice-based addresses
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Whitepaper formalizes stealth address security with key-derivation properties. EuroS&P 2019 paper by team members addresses secure deterministic wallets and stealth addresses.
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Abelian uses Proof-of-Work consensus (ABEL-ETHash GPU mining, ABEL-Nakamoto CPU mining) relying on quantum-resistant hash functions. No validator signatures, VRFs, or finality signatures exist.
Coverage basis: Satisfied by design - PoW hash-based consensus
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Mining clients and node software are open-source. Aconcagua fork at block 464,000 introduced hybrid PoW with DSA (ABEL-ETHash + ABEL-Nakamoto).
Validator signature subfactors are N/A or satisfied by design due to PoW architecture.
State Integrity
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Abelian uses lattice-based additively homomorphic commitments to hide transaction values and lattice-based zero-knowledge range proofs to prevent negative values. All based on LWE/Ring-LWE assumptions.
Coverage basis: PQ-native lattice-based commitments and ZK proofs
Implementation score: 1 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Commitment and ZK proof constructions are custom lattice-based schemes described in the 2022 whitepaper with formal security proofs. No independent audit of implementation. Based on well-reviewed LWE/Ring-LWE assumptions but bespoke constructions.
Custom constructions are PQ in assumption but lack independent implementation review.
Privacy
Privacy and proof layers are quantum-safe where applicable
Claim: Abelian implements multi-level privacy using lattice-based linkable ring signatures (sender anonymity), stealth addresses (receiver anonymity), lattice commitments (value hiding), and lattice ZK range proofs. All quantum-resistant under lattice assumptions.
Coverage basis: PQ-native custom lattice-based privacy layer
Implementation score: 1 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: cap-applying
Quantum blocker: Custom lattice-based linkable ring signature scheme is bespoke cryptography without independent audit; a structural flaw could compromise both privacy and spend authorization for private transactions.
Assurance: Custom lattice-based linkable ring signature is bespoke cryptography. While based on well-reviewed LWE/Ring-LWE assumptions and designed by academic cryptographers (Dr. Duncan Wong is co-inventor of linkable ring signatures), no independent third-party audit of the deployed implementation exists. This is the primary assurance gap.
Multi-Level Privacy (MLP) introduced at block 300,000 (July 2024). Supports full-privacy (ring sig + commitments + stealth), pseudo-private (transparent), and accountable privacy levels.
P2P
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: P2P node identity uses standard TLS/network authentication. For a PoW chain, P2P identity is not consensus-critical, spend-critical, or custody-critical.
Coverage basis: Satisfied by design - PoW chain where P2P identity does not affect asset ownership
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Node documentation shows standard RPC security configuration. P2P port 8666.
Wallet/Custody
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: Abelian provides Desktop Wallet Pro (MLP), Mobile Wallet (Abelian Pro), and CLI Wallet (MLP) all supporting PQ lattice-based keys. No hardware wallet or HSM support documented.
Coverage basis: Software wallet support for PQ keys; no hardware wallet
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: Multiple software wallets available (Desktop Pro v2.2.0, Mobile v8.0.2, CLI v3.0.0). SDKs in Go and Java. No Ledger/Trezor/HSM integration found. Large lattice key sizes (~10KB) may present hardware wallet integration challenges.
Score reduced to 0.75 because hardware wallet/HSM support is absent, limiting custody options for high-value holders.
Migration
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: 100% of native ABEL is PQ-protected by design. The native asset launched with mandatory lattice-based spend authorization and has no classical ECC/BLS ownership namespace.
Coverage basis: PQ-native with no classical native ownership space
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Mainnet launched early 2022 with PQ from genesis. All native ABEL has always been under lattice-based control.
Legacy wallet format (pre-height 300K) is still PQ (different privacy scheme version, not classical ECC). Migration from legacy to MLP wallets is a UX/privacy upgrade, not a quantum migration.
Migration
Critical wallets migrated, protected, or inherently PQ-native
Claim: All native ABEL wallets (treasuries, exchanges, custodians, users) are PQ-native by design. No classical ownership path exists for the native asset.
Coverage basis: PQ-native - all native wallets are PQ by construction
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Wrapped ABEL (wABEL) on QDay L2 is a separate asset evaluated under bridge/token inheritance rules, not as legacy native value.
Migration
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No legacy quantum-vulnerable native pools exist. The chain launched PQ-native from genesis.
Coverage basis: PQ-native - no legacy vulnerable native value exists
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Governance
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Abelian has a public roadmap including MLP privacy upgrades (block 300K), Aconcagua fork (block 464K with hybrid PoW), QDay L2 development, and ongoing wallet improvements.
Coverage basis: PQ-native - roadmap is for feature evolution, not quantum migration
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Governance
Migration accessibility and defaults
Claim: All Abelian wallets create PQ addresses by default. MLP wallet migration prompts exist for UX upgrade from legacy to new wallet format. No classical address creation is possible.
Coverage basis: PQ-native - PQ is mandatory and default
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Governance
Migration enforcement and coordination
Claim: PQ enforcement is inherent in protocol design. No classical signing path exists for native ABEL. Hard forks (300K, 464K) demonstrate coordination capability.
Coverage basis: PQ-native - enforcement by protocol design
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Governance
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No formal quantum-specific incident-response playbook or emergency disclosure process has been documented. General security contacts exist via Discord and community channels.
Coverage basis: Assurance gap - no formal quantum IR process
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: No formal security disclosure process, bug bounty program, or quantum-specific IR playbook found. Community Discord and GitHub issues are the primary communication channels. Note: Telegram channel was compromised via phishing in June 2024.
Score reduced to 0.50 because while the PQ-native design eliminates most quantum emergency scenarios, a formal process for responding to lattice cryptanalysis breakthroughs or implementation vulnerabilities is not documented.
Algorithm
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: Spend authorization uses Dilithium/ML-DSA (NIST-standardized) for transparent transactions. Privacy layer uses custom lattice-based constructions (ring signatures, commitments, ZK proofs) based on LWE/Ring-LWE assumptions.
Coverage basis: Mixed - core is NIST-standard, privacy is bespoke lattice
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Core spend auth uses NIST-standardized Dilithium. Privacy layer uses bespoke lattice constructions based on well-reviewed assumptions (LWE/Ring-LWE) but not independently standardized or audited. Team includes academic cryptographers with relevant publications.
Score 0.75 reflects that the primary algorithm is NIST-standard but the full cryptographic suite includes bespoke constructions.
Algorithm
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: No independent third-party audit of Abelian's quantum-critical implementation has been located. The 2022 whitepaper provides formal security proofs by the project team. Team members have published peer-reviewed papers on underlying primitives (EuroS&P 2019).
Coverage basis: Public design specification with academic review of primitives; no implementation audit
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Whitepaper (2022) provides formal DAPOA security model and proofs. Team member Dr. Duncan Wong published on secure stealth addresses at EuroS&P 2019. However, no independent audit of the production implementation exists. This is the most significant assurance gap.
Score 0.25 reflects public design/specification level. No CertiK, Trail of Bits, Halborn, or similar independent audit found.
Implementation
Open-source, reproducible implementation
Claim: Abelian core node (abec), SDKs (Go, Java), mining clients, and wallet software are open-source on GitHub under MIT license.
Coverage basis: Public open-source code
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: GitHub org (pqabelian) created 2023-06-07. Core node (abec) last pushed 2026-01-26. 19 public repos. 7 contributors to abec. MIT licensed.
Implementation
Parameter agility and future upgrade path are documented
Claim: Abelian has demonstrated upgrade capability through hard forks (block 300K for MLP, block 464K for Aconcagua). Whitepaper documents cryptographic parameter choices. Abelian Improvement Proposals (AIPs) repository exists.
Coverage basis: Documented parameters with demonstrated fork capability
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: AIPs repository exists. Two major hard forks successfully executed. Cryptographic scheme versioning (v0 to v1 at height 300K) demonstrates parameter agility.
Score 0.75 because while upgrade capability is demonstrated, formal documentation of parameter migration paths for future PQ algorithm transitions is limited.
Implementation
Stateful-signature safety, side-channel, fault-injection, and custody implementation risks
Claim: Dilithium is a stateless signature scheme, eliminating state-reuse risks inherent in XMSS/LMS. No documentation of side-channel countermeasures, fault-injection resistance, or formal custody security review.
Coverage basis: Stateless signatures (no state management risk); side-channel/custody not documented
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Dilithium/ML-DSA is stateless, avoiding XMSS/LMS state-management risks. However, no documentation of side-channel protections in the Go implementation, no hardware security module integration, and no formal custody security review.
Score 0.50 reflects that stateful signature risks are N/A (Dilithium is stateless) but side-channel and custody implementation risks are not addressed in public documentation.
Implementation
Performance and resource-impact analysis exists
Claim: Node documentation specifies storage requirements (Normal ~190GB, SemiFull ~450GB, Full ~1.4TB). Whitepaper discusses resource costs of lattice signatures. No formal benchmark publication.
Coverage basis: Informal resource documentation; no formal benchmarks
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: Node manual documents storage requirements. Block time is 256 seconds. Large lattice signatures (~10KB addresses) drive significant state growth. No formal performance benchmark comparing PQ overhead to classical alternatives.
Score 0.50 because resource requirements are documented in node manuals but no formal performance analysis publication exists.
Report metadata