Stable STABLE

Claim: No public cryptographic inventory or quantum threat model exists. The whitepaper documents the architecture (Stable EVM, StableBFT/CometBFT) but does not enumerate cryptographic algorithms for quantum assessment.

Coverage basis: Architectural documentation implies classical cryptographic primitives; no quantum-focused inventory.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: No quantum threat model published; cryptographic inventory is implicit rather than explicit and quantum-focused.

Assurance: Cryptographic algorithms are inferred from EVM and CometBFT compatibility rather than explicitly enumerated in a quantum-focused inventory.

The whitepaper documents the architecture at a design level but does not list cryptographic algorithms, key sizes, or attack surfaces. The project has not acknowledged quantum computing as a threat.

• https://www.stable.xyz/whitepaper.pdf
• https://docs.stable.xyz/en/explanation/tech-overview

Claim: Whitepaper, official docs, and third-party research provide evidence of the cryptographic architecture but none is quantum-specific.

Coverage basis: Third-party research and official documentation confirm classical cryptographic primitives; no code, audits, or transaction analysis exist for quantum assessment.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Evidence confirms classical cryptography but is not structured for quantum-risk assessment. Third-party sources corroborate ECDSA usage.

Implementation Score 0.25 reflects public design/specification exists via whitepaper and third-party research, per QRI spec.

• https://www.stable.xyz/whitepaper.pdf
• https://www.fourpillars.io/en/research/stable-a-digital-nation-of-usdt-by-usdt-for-usdt
• https://www.datawallet.com/crypto/stablechain-explained

Claim: Stable EVM provides full Ethereum compatibility; EOAs use ECDSA (secp256k1) signatures exclusively. Account abstraction (EIP-7702) is supported but underlying EOA control remains ECDSA.

Coverage basis: EVM compatibility inherently requires ECDSA for EOAs; Four Pillars research explicitly states 'EOA signatures are only possible with the ECDSA algorithm.'

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All spend authorization is ECDSA-only; fully quantum-vulnerable. Every transacted EOA exposes its public key, enabling offline Shor's algorithm attacks with no time constraint.

Assurance: ECDSA usage is confirmed by EVM compatibility requirements and explicitly stated in third-party research.

EIP-7702 account abstraction allows EOAs to adopt smart-contract logic but does not change the underlying ECDSA signature requirement for EOA control.

• https://stable.xyz/whitepaper
• https://www.fourpillars.io/en/research/stable-a-digital-nation-of-usdt-by-usdt-for-usdt

Claim: Standard Ethereum-style accounts; public keys are exposed on first transaction. No PQ address format, no hybrid key derivation, no protection against long-exposure quantum attacks.

Coverage basis: EVM account model exposes public keys upon transaction broadcast; all active addresses that have sent transactions have exposed public keys.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Long-exposure public keys from transacted EOAs create permanent offline attack surface with no migration, freeze, or deprecation path.

Assurance: Standard EVM account semantics are well-understood; public-key exposure on transaction broadcast is inherent to the account model.

No evidence of stealth addresses, hybrid key derivation, or any mechanism to limit public-key exposure.

• https://www.stable.xyz/whitepaper.pdf
• https://www.fourpillars.io/en/research/stable-a-digital-nation-of-usdt-by-usdt-for-usdt

Claim: StableBFT is a customized DPoS protocol built on CometBFT. Validator signatures use classical cryptography — Ed25519 or ECDSA, as standard in CometBFT.

Coverage basis: Official docs confirm StableBFT is built on CometBFT, which uses Ed25519 by default for validator signing.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Consensus validator signatures are quantum-vulnerable; a quantum adversary could forge validator signatures to compromise finality.

Assurance: CometBFT's default Ed25519 is inferred from standard configurations; the exact algorithm is not explicitly stated in Stable's documentation.

Future Autobahn DAG-based consensus upgrade does not address quantum security of validator authentication.

• https://docs.stable.xyz/en/explanation/consensus
• https://stable.xyz/whitepaper

Claim: StableDB (MemDB + VersionDB) uses standard Merkle-tree-based state commitments. SHA-256 hashing provides some quantum preimage resistance, but overall state binding depends on classical signature-based block certification.

Coverage basis: Standard blockchain state management; no evidence of quantum-safe vector commitments, hash-based accumulators, or PQ state-binding mechanisms.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: State-integrity mechanisms are not explicitly documented at cryptographic level. SHA-256-based Merkle trees provide partial quantum resistance for hashing but the overall state binding is only as strong as the validator signature scheme.

StableDB architecture (MemDB/VersionDB separation) is a storage optimization, not a cryptographic innovation for quantum security.

• https://docs.stable.xyz/en/explanation/tech-overview
• https://www.stable.xyz/whitepaper.pdf

Claim: StableChain supports Confidential Transfers using zero-knowledge cryptography. Algorithm is unspecified but EVM-compatible ZK systems typically use pairing-based SNARKs (e.g., Groth16/PLONK with BN254/BLS12-381), which are quantum-vulnerable.

Coverage basis: Multiple sources confirm ZK-based Confidential Transfers; specific proof system and curve are not publicly documented.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Confidential Transfer ZK proofs are likely quantum-vulnerable; unverifiable without algorithm disclosure.

Assurance: Algorithm and curve parameters are not publicly specified. The quantum-vulnerability assessment is based on the industry-standard assumption that EVM-compatible ZK systems use pairing-based cryptography.

This is a quantum-critical uncertainty due to missing algorithm disclosure. If a STARK-based or other hash-based system is used instead, the quantum risk profile would differ materially.

• https://www.datawallet.com/crypto/stablechain-explained
• https://www.stable.xyz/whitepaper.pdf

Claim: No evidence of PQ protection for P2P networking layer. Likely uses standard libp2p or CometBFT P2P stack with classical cryptography (Ed25519/ECDSA for node identity).

Coverage basis: Standard blockchain P2P networking; no PQ features documented.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: P2P layer cryptography is not explicitly documented. Assessment is based on standard CometBFT/libp2p defaults.

P2P node identity compromise alone would not enable asset theft but could facilitate eclipse attacks or consensus disruption when combined with other quantum vulnerabilities.

• https://docs.stable.xyz/en/explanation/tech-overview

Claim: Standard EVM wallet support (MetaMask, etc.) with ECDSA-only signing. No PQ wallet, custody, or HSM workflow support documented.

Coverage basis: EVM compatibility means standard Ethereum wallets are used; these are ECDSA-only.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No PQ wallet, custody, or HSM paths exist. Anchorage Digital provides institutional custody but its cryptographic controls for StableChain are not publicly documented.

Even if the protocol supported PQ signatures, the lack of PQ-capable wallets and custody infrastructure would block practical migration.

• https://www.fourpillars.io/en/research/stable-a-digital-nation-of-usdt-by-usdt-for-usdt

Claim: 0% of on-chain value (~$780M) is protected from quantum key-recovery attacks. All value is held in ECDSA-controlled accounts.

Coverage basis: All active addresses use standard EVM accounts with ECDSA. No PQ accounts exist. No migration has occurred.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: 100% of value-at-risk is quantum-vulnerable with no migration path.

Assurance: Value figures are from project blog. Precise breakdown of exposed vs. unexposed public keys is not available without on-chain analysis.

The project's youth means value-at-risk is growing rapidly.

• https://blog.stable.xyz/stable-2025-year-in-review-and-2026-outlook

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations) have been migrated to PQ protection.

Coverage basis: No evidence of any PQ wallet migration. Anchorage Digital custody uses standard institutional custody practices; PQ status unverified.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Foundation treasury, validator stakes, bridge contracts, and major protocol-controlled value remain entirely ECC-protected.

Assurance: Anchorage Digital's custody security model for StableChain is not publicly documented.

The 3/3 DVN bridge configuration means bridge signer keys at LayerZero Labs, Canary, and Horizen are additional critical wallets whose quantum posture is unverifiable.

• https://blog.stable.xyz/stable-2025-year-in-review-and-2026-outlook

Claim: No legacy vulnerable pools have been identified, measured, or addressed. No deprecation, freeze, or migration policy exists.

Coverage basis: No quantum-related account classification, measurement, or policy documentation exists.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No on-chain analytics or protocol-level mechanisms exist to identify, track, or manage quantum-vulnerable balances.

All existing accounts are legacy-vulnerable by definition since only ECDSA accounts can exist on an EVM chain without PQC infrastructure.

Claim: No quantum migration or PQC protection roadmap exists. The published roadmap (Autobahn, StableVM++, StableDB) contains zero quantum-security items.

Coverage basis: Official roadmap and 2026 outlook contain no quantum or PQC references.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No quantum migration roadmap exists; quantum risk is not acknowledged in any published planning document.

Assurance: Roadmap is well-documented for performance and payment features but completely silent on cryptographic upgrades or quantum threats.

• https://blog.stable.xyz/stable-2025-year-in-review-and-2026-outlook
• https://docs.stable.xyz/en/explanation/technical-roadmap

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

Coverage basis: EVM-only environment supports only ECDSA accounts. No PQ infrastructure exists at any level.

Implementation score: 0 · Evidence confidence: High

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

Assurance: EVM compatibility means PQ account creation would require protocol-level changes to the execution environment.

Claim: No enforcement mechanisms, deprecation policies, legacy signing restrictions, or exchange/custody coordination for quantum migration exist.

Coverage basis: No evidence of any migration coordination or enforcement planning.

Implementation score: 0 · Evidence confidence: Medium

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

Claim: No quantum-specific vulnerability disclosure process, incident-response plan, or emergency governance mechanism exists.

Coverage basis: No quantum-related security process documentation found.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The project has general governance mechanisms (STABLE token voting) that could theoretically address quantum emergencies, but no specific quantum-incident process is documented.

The absence of a documented process does not necessarily mean the project cannot respond; however, the lack of preparation increases risk.

Claim: No PQC algorithms are used anywhere in the protocol. All cryptography is classical (ECDSA, Ed25519, likely pairing-based ZK).

Coverage basis: Complete absence of PQC in all documented layers.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No NIST-standardized or standards-track PQC algorithms are used in any protocol layer.

Claim: No independent cryptographic or security audit identified for any StableChain component.

Coverage basis: No audit reports found in documentation, website, or third-party sources.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Audit absence affects confidence and assurance. Score is already zero due to absence of PQC implementation; audit absence reinforces the Implementation Score of 0.

OGAudit's OG Score (12.52) is a social-audit methodology rating community trust, not a cryptographic security review.

Claim: No public source-code repositories found for the StableChain protocol implementation. TypeScript SDK is available on npm but covers client-side interactions only.

Coverage basis: No protocol-level repositories found. Only client SDK available.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The absence of open-source protocol code makes quantum-critical properties unverifiable by independent parties.

Closed-source protocol implementation is a significant barrier to independent quantum-risk verification.

• https://stablelabs.mintlify.app/en/explanation/sdk-overview

Claim: No documented cryptographic agility or upgrade path. Roadmap covers performance upgrades (Autobahn, StableVM++) but not cryptographic transitions.

Coverage basis: No cryptographic agility documentation exists.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The project has demonstrated upgrade capability (v1.2.0, v1.3.0 hard forks) suggesting some organizational capacity for protocol changes, but no cryptographic agility framework is documented.

• https://docs.stable.xyz/en/explanation/technical-roadmap

Claim: No stateful PQC signatures (XMSS/LMS) are in use, so stateful-signature safety considerations are not applicable to current implementation.

Coverage basis: No stateful signatures deployed.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Marked N/A because no stateful signatures exist to evaluate.

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

Coverage basis: No PQ performance documentation exists.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Performance analysis absence is primarily an operational caveat.

StableChain's emphasis on sub-second finality and 10,000+ TPS throughput could face significant challenges from PQ signature sizes and verification costs.