cryptoasset
Aster ASTER
Aster (ASTER) scores 0/100 on the Quantum Readiness Index. The project has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, and no post-quantum or hybrid-PQ protection in any production layer. All critical cryptographic surfaces — spend authorization (ECDSA/EdDSA), consensus validator signatures (PoSA, likely ECDSA), ZK proof system (Brevis hybrid STARK/Plonk/Groth16), stealth addresses (ECDH), and bridge validator multi-sig — rely entirely on classical cryptography vulnerable to quantum attack. Core chain implementation is closed-source, making independent verification of exact algorithms impossible. The ASTER token (BEP-20 on BNB Chain) additionally inherits BNB Chain's quantum vulnerabilities. Aster Chain mainnet is live with substantial trading volume, putting significant value at quantum risk with no protection or migration path. One quantum-positive element exists: the STARK proof component (via Brevis/Pico zkVM with Plonky3 FRI and Poseidon2 hashing) is quantum-safe for proof verification, but this does not protect spend authorization, consensus, stealth addresses, or bridge authentication.
Not Assessed
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0 / 15
Migration Status & Value-at-Risk
0 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
0 / 5
Critical Quantum Blockers
- No public quantum risk assessment or cryptographic inventory published by the project.
- All production spend authorization relies on classical signatures (ECDSA/secp256k1 on EVM chains, Ed25519 on Solana) — fully quantum-vulnerable to Shor's algorithm.
- Aster Chain PoSA consensus validator signatures are classical (likely ECDSA inherited from BNB Chain Parlia engine) — quantum-vulnerable, enabling consensus compromise.
- Brevis ZK 'Proof-of-Proof' architecture uses a hybrid STARK/Plonk/Groth16 stack; Plonk and Groth16 are pairing-based and quantum-vulnerable, enabling proof forgery and privacy breaks.
- Stealth address mechanism relies on elliptic-curve Diffie-Hellman (ECDH) — quantum-vulnerable, enabling de-anonymization of all historical and future private orders.
- Bridge validator multi-sig uses classical signatures — quantum-vulnerable, enabling bridge theft.
- Core chain implementation is closed-source; quantum-critical cryptographic properties cannot be independently verified.
- No PQC migration roadmap, proposal, prototype, testnet, or mainnet support exists.
Key Risks
- Quantum-enabled theft of all ASTER tokens and bridged assets on Aster Chain via Shor's algorithm against ECDSA/EdDSA spend keys.
- Quantum forgery of ZK proofs via attacks on pairing-based Plonk/Groth16 components, enabling fabricated order execution, position manipulation, and privacy compromise.
- Quantum de-anonymization of all historical and future stealth address transactions via ECDH break.
- Quantum-enabled bridge compromise via validator signature forgery, enabling theft of all bridged assets.
- Quantum-enabled consensus takeover via validator key recovery, enabling chain reorganization and double-spending.
- Closed-source core chain prevents independent assessment of exact cryptographic primitives and their quantum vulnerability.
- No migration path exists; all value on Aster Chain is exposed with no recovery mechanism.
- ASTER token inherits BNB Chain's quantum vulnerabilities for all BEP-20 operations, including on-chain transfers, approvals, and DeFi interactions.
Assurance Notes
- Core Aster Chain contracts are closed-source, preventing independent verification of consensus signature algorithms, ZK proof system details, stealth address curve selection, and bridge signer cryptography.
- Existing smart-contract audits (PeckShield, Salus Security, HALBORN, 2024) cover AsterVault, AsterEarn, asBNB, USDF, and asCAKE — none address consensus cryptography, ZK proof assumptions, bridge security, or any quantum-critical layer.
- No quantum-specific security contact, disclosure process, or incident-response playbook published.
- ASTER token inherits BNB Chain's quantum risk profile for all BEP-20 token operations. BNB Chain itself is not quantum-ready (ECDSA/secp256k1 spend authorization).
- No public GitHub repository found for Aster Chain core implementation; only third-party bots and unrelated repositories appear in search results.
- The Brevis ZK coprocessor v2 uses a hybrid architecture combining STARK (hash-based, quantum-safe for proof verification) with Plonk/Groth16 (pairing-based, quantum-vulnerable). The exact composition used by Aster Chain for critical state verification is not fully documented.
- A separate project 'Aster Mail' (astermail.org) implements post-quantum cryptography for email encryption; this is unrelated to Aster DEX/ASTER token and should not be confused with the DEX's quantum readiness.
Non-Scoring Caveats
- Aster Chain mainnet is only ~2.5 months old as of evaluation date; early-stage projects rarely have quantum readiness programs. This is context, not a score adjustment.
- Existing smart-contract audits (PeckShield, Salus Security, HALBORN, 2024) are stale and scope-mismatched for quantum-critical evaluation but indicate general security diligence.
- The 7-validator permissioned set is a launch configuration; roadmap mentions eventual permissionless validation but no date.
- ASTER token as a BEP-20 token inherits BNB Chain's quantum risk for all token operations, but also carries independent Aster Chain risk when bridged.
- The Brevis/Pico STARK proof system uses Plonky3 FRI and Poseidon2 hashing which are quantum-safe for proof verification; however, this only protects the proof verification layer, not spend authorization, consensus, or stealth address mechanisms.
- No formal performance or resource-impact analysis for any potential PQC migration exists, but this is an operational/product caveat for a project with no PQC work.
- Aster Chain uses PoSA consensus inherited from BNB Chain's Parlia engine which uses ECDSA for validator authentication.
- Aster DEX has a bug bounty program on Immunefi (up to $200K) but this is not quantum-specific.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: No public cryptographic inventory or quantum threat model published by the project.
Coverage basis: Absence of evidence confirmed across official docs (docs.asterdex.com), website (asterdex.com), roadmap, and third-party coverage.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory published.
Assurance: Confirmed absence across all primary sources. Project is not PQ-native.
Aster is not PQ-native. No quantum-specific documentation exists in any published source.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: No quantum-specific evidence record published.
Coverage basis: Absence of quantum-related evidence across all published audits, documentation, and repositories.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum-specific evidence record published.
Assurance: Existing audits (PeckShield, Salus Security, HALBORN, 2024) cover smart contracts only; none address quantum-critical layers.
Not PQ-native; cannot receive design-based credit.
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All user transaction signing uses standard wallet signatures — ECDSA/secp256k1 on EVM chains (BNB Chain, Ethereum, Arbitrum) and Ed25519 on Solana. Aster Chain requires standard wallet signatures (MetaMask, etc.) for access.
Coverage basis: Official documentation confirms standard wallet connectivity; Coinfomania report confirms 'standard crypto wallet signature' for access.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All spend authorization is ECDSA/EdDSA-only; fully quantum-vulnerable.
Assurance: Exact signature algorithm on Aster Chain not independently verifiable due to closed-source core, but all evidence points to standard wallet ECDSA/EdDSA with no PQC.
Users connect with standard wallets like MetaMask. No PQC or hybrid-PQC signature path exists.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: Standard EOA address model on Aster Chain and all host chains. Public keys exposed on first transaction. No PQ key-derivation or address scheme.
Coverage basis: Aster Chain docs describe standard blockchain accounts; no PQ address format documented.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Long-exposure public keys on standard EOA accounts; no PQ address or key-derivation scheme.
Assurance: Core chain closed-source; exact key derivation cannot be independently verified but all indications point to standard EOA model.
ASTER token accounts on BNB Chain/Ethereum follow standard EOA model with long-exposure public keys after first spend.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: PoSA consensus uses 7 permissioned validators signing blocks. Signatures are classical (likely ECDSA, inherited from BNB Chain's Parlia engine).
Coverage basis: Official docs describe PoSA consensus; AsterScan validator page confirms 7-validator set with cryptographic header signing.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: PoSA validator signatures are classical; quantum-vulnerable consensus authentication.
Assurance: Exact signature algorithm (ECDSA vs EdDSA vs BLS) not published. Inherited from BNB Chain PoSA design which uses ECDSA. No independent audit of consensus cryptography.
Validator set is permissioned and small (7 nodes). Quantum key recovery of any validator could enable block forgery and chain compromise.
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Aster Chain uses Brevis 'Proof-of-Proof' ZK structure for state integrity and privacy. Brevis v2 uses hybrid STARK/Plonk/Groth16 architecture. Plonk and Groth16 are pairing-based and quantum-vulnerable.
Coverage basis: Coinfomania report confirms Brevis Proof-of-Proof; Brevis blog confirms Plonk/Groth16 pairing-based components in v2 architecture.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: ZK proof system uses pairing-based (Plonk/Groth16) components vulnerable to quantum proof forgery.
Assurance: Exact proof system composition on Aster Chain not independently verifiable (closed-source). Brevis STARK components may offer partial quantum resistance but the Plonk/Groth16 wrapping for on-chain verification is quantum-vulnerable.
A quantum adversary could forge ZK proofs, fabricating order execution, manipulating positions, breaking privacy, and potentially draining protocol value.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable
Claim: Aster Chain privacy stack: ZK-verifiable encrypted orders + stealth address mechanism. ZK uses Brevis (pairing-vulnerable). Stealth addresses use ECDH (elliptic-curve Diffie-Hellman), quantum-vulnerable.
Coverage basis: Official docs describe ZK-verifiable encryption and stealth address mechanism. Standard stealth address implementations use ECDH over secp256k1 or similar curves.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Stealth addresses use ECDH (quantum-vulnerable); ZK encryption uses pairing-based proofs (quantum-vulnerable).
Assurance: Exact elliptic curve for stealth addresses cannot be verified (closed-source). Standard implementations use secp256k1 or Curve25519, both quantum-vulnerable.
A quantum adversary could break ECDH to de-anonymize all historical and future stealth address transactions, exposing every private order ever placed.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: No evidence of PQ protection for P2P transport or node identity. No satisfied-by-design justification.
Coverage basis: No P2P cryptography documentation found.
Implementation score: 0 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: P2P layer cryptography is undocumented. Typically uses TLS with classical assumptions. Not independently verifiable.
While P2P transport compromise does not directly enable asset theft, it could enable transaction censorship, eclipse attacks, and validator isolation in a quantum-adversary scenario.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: No PQ wallet or custody support exists. Users interact via standard wallets (MetaMask, etc.) with no PQC capabilities.
Coverage basis: Official docs reference standard wallet connectivity only.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ wallet, custody, or HSM workflow supported.
Assurance: Standard wallet ecosystem has no PQC capability; Aster adds no PQ extensions.
All critical wallets (treasuries, validators, bridges) operate with classical signatures only.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: 0% of value-at-risk is quantum-protected. All value on Aster Chain and ASTER token holdings on classical cryptography with no PQC protection.
Coverage basis: CoinGecko market data, DefiLlama TVL data, Blockonomi report on trading volume. No PQC protection found in any layer.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 100% of value-at-risk is quantum-vulnerable with no migration or protection path.
Assurance: Value figures from third-party sources (DefiLlama, CoinGecko) as of early 2026. Coverage is 0% by any measure.
ASTER token exists on multiple chains; all host chains are quantum-vulnerable. Bridged assets add bridge-specific quantum risk.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets are PQ-protected. All 7 validators, bridge signers, treasury, and protocol-controlled wallets use classical signatures.
Coverage basis: AsterScan validator page confirms operator identities; no evidence of PQ key migration.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All critical wallets (validators, bridge, treasury) are quantum-vulnerable.
Assurance: Validator identities are publicly known but their key management and exact signature schemes are not disclosed.
7 validators include Aster team (2), Trust Wallet, BNB Chain, WLFI, PancakeSwap, Lista — all operating with classical keys.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No legacy vulnerable pool identification, measurement, or deprecation published. All accounts on Aster Chain are quantum-vulnerable by default.
Coverage basis: No migration documentation or vulnerable-pool analytics found.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No identification or measurement of vulnerable value pools.
Assurance: Aster Chain launched March 2026; all accounts are 'legacy' in the quantum sense from genesis.
Not PQ-native; all accounts were created with classical key material.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No quantum migration or PQC protection roadmap published. The published roadmap covers staking, governance, Smart Money, and UI — no PQC items.
Coverage basis: Official roadmap at docs.asterdex.com/overview/roadmap contains no quantum or PQC entries.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQC migration roadmap published.
Assurance: Roadmap covers through Q2 2026 with no quantum-related items.
Not PQ-native; roadmap absence is a gap, not design credit.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, warnings, education, migration prompts
Claim: No PQ account creation, wallet tooling, custody paths, warnings, or migration prompts exist.
Coverage basis: All documentation describes standard wallet interaction with no PQ alternatives.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ migration accessibility for users.
Assurance: Users can only create quantum-vulnerable accounts by default.
Not PQ-native.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: deprecation, freeze, disabled legacy signing, restricted withdrawals, exchange coordination
Claim: No migration enforcement mechanisms exist. No exchange, custody, bridge, or wallet coordination for quantum safety.
Coverage basis: No evidence of any quantum-related coordination or enforcement.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No migration enforcement or coordination mechanisms.
Assurance: Two-way bridge to BNB Chain allows value flow back into non-PQ-secure system without restrictions.
Bridge to BNB Chain is unrestricted two-way; even if Aster Chain became PQ-secure, value could flow back to quantum-vulnerable BNB Chain.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No quantum-specific emergency disclosure, incident-response, or governance process published.
Coverage basis: No quantum incident-response documentation found.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No security contact or disclosure process publicly documented for quantum issues. Bug bounty (Immunefi, up to $200K) exists but is not quantum-specific.
Aster governance is planned for Q2 2026 but no quantum-specific governance provisions are described.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: No NIST-standardized or standards-track PQC algorithms used in any layer.
Coverage basis: All documented cryptography is classical (ECDSA, EdDSA, ECDH, pairing-based ZK).
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No NIST PQC algorithms used.
Assurance: None of ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS, or XMSS are used or planned.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: No independent audit of quantum-critical cryptographic implementation exists. Existing audits cover smart contracts only.
Coverage basis: Audit reports page lists only smart-contract audits (PeckShield, Salus Security, HALBORN, 2024). No consensus, ZK, or bridge cryptography audits.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No cryptographic audit of quantum-critical implementation.
Assurance: All existing audits are smart-contract scoped (AsterVault, AsterEarn, asBNB, USDF, asCAKE) and predate Aster Chain mainnet.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Core Aster Chain contracts and RPC infrastructure are closed-source. Bridge contracts are partially open.
Coverage basis: Official docs state: 'Core chain contracts and RPC infrastructure will not be open-sourced at the moment.'
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: Core chain implementation is closed-source; quantum-critical properties cannot be independently verified.
Assurance: Docs state this approach is 'to protect proprietary matching engine algorithms and improve network security during early deployment stages.' ZK architecture is claimed to ensure trust minimization despite closed source.
Closed-source core means exact signature algorithms, ZK proof composition, stealth address curves, and bridge cryptography cannot be independently audited or verified.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: No cryptographic parameter agility or PQC upgrade path documented.
Coverage basis: No agility documentation found in any published source.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No cryptographic agility or upgrade path documented.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks considered
Claim: No PQC stateful signatures in use; no quantum-specific side-channel or custody risk analysis published.
Coverage basis: No relevant documentation found.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No PQC signatures deployed, so stateful-signature safety is not a current concern. However, the absence of any analysis is noted.
Applicable for future PQC adoption but currently no implementation to evaluate.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No PQC performance or resource-impact analysis published.
Coverage basis: No relevant documentation found.
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Note-only: no PQC deployment exists, so performance analysis is premature. Would become relevant if PQC migration begins.
Aster Chain's 50ms block time and 100K TPS claims would need re-evaluation under PQC signature sizes and verification costs.
Report metadata