A7A5 A7A5

Claim: No public cryptographic inventory or quantum threat model exists for A7A5.

Coverage basis: Absence of any quantum-specific documentation

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory exists — full quantum attack surface cannot be verified

Assurance: All official documentation (docs.a7a5.io, a7a5.io) was reviewed. No mention of cryptography beyond standard ERC-20/TRC-20 implementation exists. No quantum threat model, cryptographic inventory, or risk assessment is published. This is verifiable by absence across all primary sources.

The project documentation focuses exclusively on fiat backing, rebase mechanics, sanctions compliance under Kyrgyz law, and DeFi integrations. Quantum security is not addressed in any form.

• https://docs.a7a5.io/
• https://a7a5.io/

Claim: No public evidence record exists for any quantum-specific claims or assessment.

Coverage basis: Absence of quantum evidence artifacts

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Smart contracts are verified on Etherscan (Solidity v0.8.22) and TRON equivalent, but the code contains no PQC, hybrid, or quantum-aware logic. No audit reports, code references, specs, or reproducible analytics address quantum security.

Third-party analyses (CertiK, Chainalysis, Elliptic, TRM Labs) confirm the token's architecture and centralized control but do not constitute a project-published quantum assessment.

• https://docs.a7a5.io/
• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: All user transaction signatures are ECDSA-only, inherited from host chains Ethereum (secp256k1) and TRON (ECDSA).

Coverage basis: Host-chain dependency — token has no independent signature scheme

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization is ECDSA-only; no PQC or hybrid-PQC path exists for token transfers

Assurance: Etherscan-verified contract shows standard ERC-20 transfer/transferFrom/approve functions with no custom signature verification. Ethereum's own documentation confirms current production reliance on ECDSA secp256k1. TRON similarly uses ECDSA. Both host chains have announced PQ roadmaps but no production PQ protection as of June 2026.

Under QRI Section 7.2, the token inherits host-chain cryptographic reality. Neither Ethereum nor TRON offers production PQ transaction signing. Ethereum targets ~2029 for core PQ infrastructure; TRON has announced plans for Q3 2026 mainnet but no formal proposal exists.

• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9
• https://docs.a7a5.io/a7a5-token/tech_specification
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: All A7A5 token holders use standard Ethereum EOAs or TRON accounts with long-exposure ECDSA public keys.

Coverage basis: Host-chain dependency — token inherits address/public-key model

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Long-exposure ECDSA public keys for all active accounts — harvest-now-decrypt-later attack surface

Assurance: Any Ethereum account that has sent a transaction has an exposed public key. TRON accounts similarly expose public keys on-spend. The token has ~12,000-29,000 holders across both chains; the majority of active addresses have sent at least one transaction. No PQ address format, key-derivation, or account-abstraction protection exists.

Ethereum's EIP-8141 (native account abstraction) planned for Hegotá (H2 2026) would enable opt-in PQ signatures, but this is not yet live and would require individual user migration.

• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: A7A5 is a token and has no independent consensus mechanism.

Coverage basis: N/A — token has no consensus layer

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Host-chain consensus-layer quantum vulnerability (Ethereum BLS signatures, TRON validator keys) indirectly affects token security by threatening chain finality and reorg resistance, but this is captured under host-chain inheritance, not as a token-specific subfactor.

• https://docs.a7a5.io/a7a5-token/tech_specification

Claim: Token state integrity is protected only by ECDSA-based admin multisig keys controlling mint, burn, blacklist, pause, and rebase functions.

Coverage basis: Token-specific admin-key control of state-manipulation functions

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ECDSA-based admin multisig controls all state-manipulation functions — quantum compromise enables arbitrary mint, burn, freeze, and supply destruction

Assurance: The tech specification documents Owner (3-of-5), Accountant (3-of-5), and Compliance (5-of-5) multisig roles. These are standard on-chain multisigs using ECDSA signatures on the host chain. The destroyBlackFunds function has been used in production (August 2025) to burn ~$405M in tokens and re-mint to clean addresses, demonstrating the real power of these keys. No timelock, no governance override, no emergency recovery path.

The rebase mechanism (balance = shares × _totalLiquidity / _totalSupply) means distributeInterest can silently alter all holder balances. Combined with mint/burn, admin-key compromise enables undetectable supply inflation.

• https://docs.a7a5.io/a7a5-token/tech_specification
• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: A7A5 has no privacy features, zero-knowledge proofs, shielded transactions, or stealth addresses.

Coverage basis: N/A — no privacy layer exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://docs.a7a5.io/
• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: A7A5 is a token and has no independent P2P network layer.

Coverage basis: N/A — token has no P2P layer

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://docs.a7a5.io/

Claim: Admin multisig signers use standard ECDSA wallets with no PQ or hybrid protection.

Coverage basis: Token-specific admin signer key management

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Admin multisig signers (5 unique wallet addresses per role) use classical ECDSA wallets — quantum compromise of any quorum breaks token supply integrity

Assurance: The multisig specification confirms 5 unique wallet addresses per role. These are standard blockchain addresses implying ECDSA key pairs. No evidence of HSM, MPC, threshold signing, or hardware-wallet configurations with PQ properties. The identities of key holders are not publicly known (anonymous technical team). No custody attestation or key-ceremony documentation exists.

The documentation does not specify whether admin signers use hardware wallets, MPC, or any advanced key management. Given the project's sanctions-evasion design pattern (rapid adaptation to enforcement actions), key management practices cannot be independently verified.

• https://docs.a7a5.io/a7a5-token/tech_specification

Claim: 0% of A7A5 value-at-risk is protected from quantum key-recovery attacks. All ~$500M market cap and $110B+ cumulative volume remain entirely ECDSA-dependent.

Coverage basis: Token circulating supply and cumulative transaction volume — all quantum-vulnerable

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ~$500M fully diluted value and $110B+ cumulative volume have zero quantum protection

Assurance: Market cap figures vary by source (~$489M–$542M). Circulating supply is ~39–42B tokens across Ethereum and TRON. CertiK reports $110B+ cumulative on-chain transactions as of June 2026. All value is held in standard ECDSA-secured accounts. No portion has been migrated to PQ-safe custody. The coverage threshold of <25% maps to the minimum Implementation Score equivalent of 0.05 (1/20 subfactor points).

The project has no mechanism to measure, attest, or report quantum-vulnerable value. Token concentration (~98% in top 10 addresses) means a small number of key compromises could capture nearly all value.

• https://coinmarketcap.com/currencies/a7a5/
• https://cointelegraph.com/news/russian-ruble-stablecoin-growing-western-sanctions-report
• https://www.elliptic.co/blog/the-rise-of-a7a5-the-ruble-stablecoin-now-transfers-1-billion-per-day

Claim: No critical wallets (admin multisig signers, treasury, issuer, liquidity pools) have been migrated to or protected by PQC or hybrid-PQC controls.

Coverage basis: Token-specific admin and treasury key assessment

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Admin multisig wallets are ECDSA-only with no migration path

Assurance: The 15 unique signer addresses (5 each for Owner, Accountant, Compliance roles) are standard ECDSA wallets. No PQ migration has been announced or implemented. The identities of signers are not public. No treasury wallet addresses are separately documented beyond the token contract itself.

The top holder address (0x45d2...3fc36) holds 57% of Ethereum supply (~296M tokens). The nature of this wallet (issuer treasury, liquidity pool, exchange) is not publicly documented. All top-10 addresses holding >98% of supply are quantum-vulnerable ECDSA accounts.

• https://docs.a7a5.io/a7a5-token/tech_specification
• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: No legacy vulnerable pools, accounts, or contracts have been identified, measured, deprecated, migrated, frozen, or proven not to exist by design.

Coverage basis: Absence of any legacy-asset identification or deprecation process

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The project has not published any quantum-vulnerability inventory, legacy-asset register, or deprecation plan. A deprecated wrapped token contract (0x0d57436f2d39c0664c6f0f2e349229483f87ea38) exists but its deprecation was not for quantum reasons and no migration path was provided.

The destroyBlackFunds function demonstrates technical capability to burn tokens from specific addresses, but this has been used for sanctions response, not quantum-risk mitigation.

• https://docs.a7a5.io/

Claim: No public quantum migration or protection roadmap exists for A7A5.

Coverage basis: Absence of any migration planning documentation

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No migration roadmap — no sequencing, activation criteria, or dependencies defined

Assurance: All official project documentation was reviewed. No quantum-related content exists. The project roadmap (as publicly visible) focuses on exchange listings, DeFi integrations, payment products (Stable Pay, Harbour, Cryptonote, MIR card), and regulatory expansion — none of which addresses cryptographic migration.

Even if A7A5 wanted to migrate, the token's dependence on host-chain signature schemes means it cannot independently offer PQ transaction signing until Ethereum and/or TRON support it at the protocol level.

• https://docs.a7a5.io/
• https://a7a5.io/

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: Absence of any migration tooling or user guidance

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No PQ wallet support, no migration prompts, no user education about quantum risk, and no mechanism for users to opt into quantum-safe custody. The project's wallet product (A7A5 Wallet) documentation mentions multi-currency support and fiat gateways but no cryptographic security features.

Given the project's primary user base operates through sanctioned exchanges (Grinex) and proprietary DEXs with limited KYC, conventional migration coordination through regulated exchanges and custodians is structurally unavailable.

• https://docs.a7a5.io/
• https://a7a5.io/

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration deadlines) exist for quantum migration.

Coverage basis: Absence of any migration enforcement infrastructure

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The token contract does include pause, blacklist, and destroyBlackFunds functions that could theoretically be repurposed for quantum migration enforcement. However, these are controlled by the same ECDSA multisig keys that would be vulnerable in a quantum attack, creating a circular dependency. No exchange, custody, bridge, wallet, or infrastructure coordination plan exists for quantum migration.

The project's sanctioned status means it cannot coordinate migration through major exchanges (Coinbase, Binance, Kraken) or regulated custodians, severely limiting any future migration even if a technical path were developed.

• https://docs.a7a5.io/a7a5-token/tech_specification

Claim: No emergency disclosure process, incident-response plan, or governance mechanism exists for quantum-related vulnerabilities.

Coverage basis: Absence of any quantum-specific emergency process

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No security contact, vulnerability disclosure policy, bug bounty program, or incident-response playbook is published. The anonymous technical team has no public communication channel for security issues. The project has demonstrated operational adaptability (rapid response to sanctions via destroyBlackFunds) but this capability is not formalized for cryptographic emergencies.

The QRI specification notes that the absence of a formal quantum-specific incident-response playbook should not independently create a Readiness & Risk Cap, but it does reduce the category score when combined with the complete absence of other migration mechanisms.

• https://docs.a7a5.io/
• https://a7a5.io/

Claim: A7A5 uses no PQC or hybrid-PQC algorithms of any kind.

Coverage basis: Absence of any PQC algorithm usage

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No NIST-standardized or broadly reviewed PQC algorithms are used anywhere in the token system

Assurance: The verified Solidity source code on Etherscan (compiler v0.8.22) contains only standard ERC-20 logic, a rebase mechanism, and access-control modifiers. No reference to ML-KEM, ML-DSA, SLH-DSA, FN-DSA, XMSS, LMS, SPHINCS+, Dilithium, Falcon, or any other PQC algorithm exists.

Even if the token contract were to implement on-chain PQC signature verification, user transactions would still require host-chain ECDSA signatures to be included in blocks.

• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9
• https://docs.a7a5.io/a7a5-token/tech_specification

Claim: No independent cryptographic audit exists for any quantum-critical scope of A7A5.

Coverage basis: Absence of any quantum-specific audit

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The Stengarl investigation (a comprehensive third-party review) found zero results from CertiK, PeckShield, Trail of Bits, Hacken, or any recognized auditor. A Cyberscope automated scan exists (score 55%, 'Neutral Risk') but is not a formal audit and does not evaluate quantum security. The project claims smart-contract audits have been completed but provides no links, firm names, dates, or scope.

The absence of any audit is particularly concerning given the extreme centralization of admin powers and the $110B+ cumulative volume processed. However, even a conventional smart-contract audit would not address quantum security unless specifically scoped for it.

• https://stengarl.eth.limo/posts/a7a5-report/
• https://www.cyberscope.io/audits/coin-a7a5

Claim: The token contract is verified on Etherscan but contains no PQC implementation to be open-source or reproducible.

Coverage basis: Verified source code without quantum-relevant content

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The Ethereum contract is verified on Etherscan (Solidity v0.8.22, optimization disabled). The TRON contract is similarly verifiable. Source code is publicly accessible. However, there is no PQC implementation to evaluate for reproducibility. No GitHub organization, build system, or test suite is publicly linked by the project.

The contract is standard, verifiable, and relatively simple — but contains zero quantum-relevant code. The score of 0.00 reflects the absence of any PQC implementation, not a judgment on code quality or availability.

• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: No parameter agility or future cryptographic upgrade path is documented.

Coverage basis: Absence of any cryptographic agility design

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The token contract has no upgradeability pattern (no proxy, no mutable implementation reference, no governance-controlled logic replacement). While this prevents unauthorized upgrades, it also means there is no documented path to introduce PQC signature verification without deploying an entirely new token contract and coordinating a full migration.

The project has demonstrated willingness to deploy new contracts (deprecated wA7A5 at 0x0d57... replaced by 0xF442...) but has not articulated any cryptographic upgrade strategy.

• https://docs.a7a5.io/a7a5-token/tech_specification
• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: A7A5 uses no stateful signatures (XMSS/LMS) and has no PQC signature implementation to evaluate for state-management risks.

Coverage basis: N/A — no stateful PQC signatures in use

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

If A7A5 were to adopt hash-based signatures in the future (e.g., following Ethereum's leanXMSS path), stateful-signature safety would become applicable and require evaluation.

• https://etherscan.io/address/0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9

Claim: No performance or resource-impact analysis exists for PQ signature/verification deployment.

Coverage basis: N/A — no PQ deployment to analyze

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Performance analysis would become applicable if the project published a concrete PQ migration proposal. At the host-chain level, Ethereum's PQ team has published performance benchmarks for leanXMSS and leanVM.