cryptoasset
Aster ASTER
Aster (ASTER) is a privacy-focused L1 blockchain with a multi-chain token presence, launched in 2026. The project uses classical PoSA consensus, ECDSA/EdDSA spend authorization, and ZK-based privacy features with no evidence of post-quantum cryptography implementation, design, or roadmap. Core chain contracts are closed-source, preventing independent verification of cryptographic primitives, signature algorithms, or ZK proof systems. Validator-signed bridges connect Aster Chain to quantum-vulnerable host chains without restrictions. No audits, cryptographic inventories, threat models, or quantum-readiness plans have been published. The project receives a Stage 1 (Quantum Risk Assessed) rating with Very Low confidence due to the complete absence of post-quantum cryptography evidence and the closed-source nature of critical implementations. All critical layers (spend authorization, consensus, privacy, bridges) remain quantum-vulnerable by default.
Category breakdown
QRI Factors
Critical Quantum Blockers
- No evidence of post-quantum cryptography implementation, design, or roadmap for any critical layer (spend authorization, consensus, privacy, bridges).
- Closed-source core implementation prevents verification of cryptographic primitives and quantum-vulnerability status.
- Classical PoSA consensus and validator-signed bridges are quantum-vulnerable by default with no disclosed mitigation.
- Privacy layer (ZK proofs, stealth addresses) likely relies on classical ECC/pairing assumptions with no PQ alternatives evidenced.
- No public cryptographic inventory or quantum threat model exists.
Key Risks
- All user funds on Aster Chain are secured by quantum-vulnerable ECDSA/EdDSA signatures.
- Validator signatures and bridge verification are quantum-vulnerable, risking consensus security and cross-chain asset integrity.
- Privacy features (ZK-encrypted orders, stealth addresses) likely depend on classical pairing-based cryptography, creating long-exposure structural risk.
- Closed-source core implementation prevents independent verification of cryptographic primitives and quantum vulnerability surface.
- Multi-chain token presence on BNB Chain, Ethereum, Solana, and Arbitrum inherits quantum vulnerabilities of those host chains.
- No migration path, freeze mechanism, or deprecation policy for quantum-vulnerable accounts or long-exposure balances.
- Lack of quantum-specific incident-response plan or emergency governance process for quantum-related vulnerabilities.
Assurance Notes
- No independent cryptographic or implementation audits identified for Aster Chain core, consensus, privacy layer, or bridge verification.
- Core chain contracts and protocol implementation are not open-sourced, preventing independent verification of cryptographic primitives, signature algorithms, or ZK proof systems.
- No public cryptographic inventory, threat model, or quantum-readiness roadmap published by the Aster core team.
- Exact signature algorithms for PoSA validator authentication, transaction spend authorization, and bridge verification remain unspecified in public documentation.
- ZK proof system specifics (pairing-based vs hash-based) and stealth address construction are undocumented, leaving quantum-critical privacy and state-binding properties unverifiable.
Non-Scoring Caveats
- Aster (ASTER) also exists as a multi-chain token (BEP-20, ERC-20, etc.) on quantum-vulnerable host chains; this evaluation covers the native Aster Chain L1 asset and its multi-chain representations.
- Third-party R&D by Kairos Lab exists but does not constitute base-layer protection for the current production scope.
- ZK proof verification (Plonky3/Poseidon2) may be quantum-safe, but this does not protect user funds or chain consensus from quantum attacks.
- Lack of open-source code limits community review and independent security assessment.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: No public cryptographic inventory or quantum threat model exists.
Coverage basis: No evidence of inventory or threat model in official documentation or public sources.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory or quantum threat model.
Assurance: No evidence of any quantum risk assessment or cryptographic inventory.
Project documentation describes PoSA consensus and privacy features but provides no cryptographic algorithm specifications or threat model.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: No public evidence record supporting quantum risk assessment exists.
Coverage basis: No code references, specs, audits, or reproducible analytics for quantum risk.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public evidence record for quantum risk assessment.
Assurance: No audits, transaction examples, or reproducible analytics identified.
Official documentation provides high-level architecture descriptions but no cryptographic evidence record.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: Spend authorization uses classical ECDSA/EdDSA signatures with no PQC or hybrid-PQC support.
Coverage basis: No evidence of PQC or hybrid-PQC transaction signatures in documentation or public sources.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only.
Assurance: High confidence that spend authorization is classical based on official documentation and dossier analysis. Exact algorithm unspecified but both ECDSA and EdDSA are quantum-vulnerable.
No evidence of PQ signature support (e.g., Dilithium, Falcon, SPHINCS+) or hybrid construction.
Production Cryptographic Protection
Account, address, public-key exposure, and key derivation
Claim: Account and public-key exposure design is classical with no PQ/hybrid controls.
Coverage basis: No evidence of PQ-safe address derivation, key rotation, or exposure mitigation.
Implementation score: 0 · Evidence confidence: Low
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Long-exposure quantum-vulnerable ownership paths exist with no mitigation.
Assurance: No documentation on address formats, key derivation, or public-key exposure controls.
Stealth addresses are mentioned for privacy but likely rely on classical ECC; no PQ-safe key management is evidenced.
Production Cryptographic Protection
Consensus-critical authentication
Claim: PoSA consensus uses validator signatures that are quantum-vulnerable.
Coverage basis: Validator authentication in PoSA is classical; no PQC or hybrid-PQC evidence.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus finality and validator authentication remain quantum-vulnerable.
Assurance: PoSA consensus is described but signature algorithms are not specified; classical ECDSA/BLS is assumed.
Validator signatures are critical for block production and finality; quantum vulnerability here threatens chain security.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: State-integrity mechanisms include ZK proofs and bridge verification, all likely classical.
Coverage basis: ZK-verifiable encrypted orders and validator-signed bridges; no PQ-safe commitments evidenced.
Implementation score: 0 · Evidence confidence: Low
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Bridge verification and ZK proof assumptions are likely quantum-vulnerable.
Assurance: ZK proof system (Plonky3/Poseidon2) may be quantum-safe for verification, but bridge signer sets and other state-binding mechanisms are classical.
While ZK proof verification may use STARK-like primitives, bridge security depends on validator signatures which are quantum-vulnerable.
Production Cryptographic Protection
Privacy and proof layers
Claim: Privacy features (ZK-encrypted orders, stealth addresses) likely rely on classical cryptography.
Coverage basis: No evidence of PQ-safe ZK proofs or stealth address schemes.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Privacy layers likely depend on quantum-vulnerable pairings or ECC.
Assurance: Plonky3/Poseidon2 may provide quantum-safe proof verification, but stealth addresses and encrypted orders likely use classical ECC.
Privacy claims are high-level; no cryptographic specifications are provided to verify quantum safety.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: P2P node identity and transport are classical with no PQC evidence.
Coverage basis: No evidence of PQC or hybrid-PQC for node identity or peer authentication.
Implementation score: 0 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: confidence-only
Assurance: No documentation on P2P identity or transport security; assumed classical.
P2P layer is not described in available documentation; quantum vulnerability is assumed but not directly evidenced.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: No evidence of PQ/hybrid wallet, custody, or HSM support.
Coverage basis: No wallet or custody documentation referencing PQC or hybrid-PQC.
Implementation score: 0 · Evidence confidence: Very Low
Issue classification: quantum-critical uncertainty · Score treatment: confidence-only
Assurance: No wallet or custody documentation available; assumed no PQ support.
Critical wallet and custody workflows are not addressed in available sources.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: No value-at-risk is protected from quantum key-recovery attacks.
Coverage basis: No migration, protection, or PQ-native design for native asset.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration path.
Assurance: No migration mechanism or protection exists; all value is quantum-vulnerable.
Aster Chain launched in 2026 with classical cryptography; all native asset value is exposed.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets are migrated, protected, or inherently PQ-native.
Coverage basis: No evidence of PQ-safe treasuries, exchanges, custodians, or bridges.
Implementation score: 0 · Evidence confidence: Very Low
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Major value pools and critical wallets remain quantum-vulnerable with no migration path.
Assurance: No information on treasury, exchange, or custody wallet configurations.
Critical wallet status cannot be assessed due to lack of public information.
Migration Status & Value-at-Risk
Legacy vulnerable pools identified, measurable, deprecated, migrated, frozen, or absent by design
Claim: Legacy vulnerable pools are not identified, measurable, or addressed.
Coverage basis: No identification, deprecation, or migration of vulnerable accounts/UTXOs.
Implementation score: 0 · Evidence confidence: Very Low
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No mechanism to identify or address legacy vulnerable pools.
Assurance: No analytics or policy for vulnerable pools exists.
As a new chain, legacy pools may be minimal, but no evidence of identification or policy exists.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap
Claim: No public migration or protection roadmap exists.
Coverage basis: No roadmap, sequencing, activation criteria, or dependencies published.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public roadmap for quantum migration or protection.
Assurance: No roadmap or migration plan identified in any source.
Third-party R&D by Kairos Lab exists but is not an official Aster team roadmap.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: No PQ/hybrid account creation, wallet tooling, or migration prompts exist.
Coverage basis: No evidence of PQ-accessible transaction paths or user-facing migration tools.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Users can only create quantum-vulnerable accounts by default.
Assurance: No PQ wallet, account, or migration tooling identified.
All current user-facing paths are classical-only.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and ecosystem coordination
Claim: No enforcement mechanisms or ecosystem coordination for quantum migration exist.
Coverage basis: No deprecation, freeze, disabled legacy signing, or coordination evidence.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No enforcement or coordination mechanisms for quantum safety.
Assurance: No evidence of exchange, custody, or wallet coordination.
Ecosystem coordination for quantum migration is entirely absent.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident response, or quantum governance
Claim: No emergency disclosure, incident-response, or governance process for quantum vulnerabilities exists.
Coverage basis: No quantum-specific incident-response or governance process documented.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No quantum-specific emergency process identified.
General governance may exist but no quantum-specific incident response is evidenced.
Algorithm & Implementation Assurance
Standardized, standards-track, or broadly reviewed PQC algorithm selection
Claim: No PQC or hybrid-PQC algorithms are used or proposed.
Coverage basis: No evidence of NIST-standardized or reviewed PQC algorithms.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQC algorithm selection or proposal exists.
Assurance: All current cryptography is classical; no PQC algorithms identified.
Algorithm selection is entirely classical with no quantum-safe alternatives.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit
Claim: No independent cryptographic or implementation audit exists for quantum-critical scope.
Coverage basis: No audit reports identified for any cryptographic component.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No audits identified; this is an assurance gap but does not independently reduce QRI score as no quantum-safe implementation exists to audit.
Audit absence is noted but score impact is already captured by lack of any PQC implementation.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Core chain contracts are not open-sourced, limiting reproducibility.
Coverage basis: Official documentation states core chain contracts are not open-sourced.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: Closed-source implementation prevents independent verification of cryptographic primitives.
Assurance: Core implementation is closed-source per official documentation.
This prevents verification of exact cryptographic algorithms used and any potential quantum vulnerabilities.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
Claim: No parameter agility or future upgrade path is documented.
Coverage basis: No documentation on cryptographic agility or upgrade mechanisms.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No cryptographic agility or upgrade path documented.
Parameter agility is not addressed in available documentation.
Algorithm & Implementation Assurance
Stateful-signature, side-channel, fault-injection, HSM, and custody implementation risks
Claim: No stateful-signature safety, side-channel, or implementation risk controls are documented.
Coverage basis: No evidence of implementation risk consideration for quantum-safe cryptography.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No implementation risk controls documented; noted as assurance gap.
This is an assurance gap but does not independently reduce score as no PQC implementation exists.
Algorithm & Implementation Assurance
Performance and resource-impact analysis
Claim: No performance or resource-impact analysis for PQC deployment exists.
Coverage basis: No analysis of PQ signature/verification costs, block validation impact, or node requirements.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No performance analysis for quantum-safe migration exists.
Performance analysis absence is noted but does not independently reduce score as no PQC implementation exists.
Report metadata