Starknet STRK

Claim: StarkWare published 'Quantum Computing Is Coming: Is Starknet Prepared?' (Dec 2024) identifying STARK proofs as quantum-resistant, acknowledging Pedersen hash and signing methods as vulnerable, and outlining migration path via Poseidon and Account Abstraction.

Coverage basis: Published risk assessment covering proof system, hash functions, and wallet signing; does not constitute a comprehensive cryptographic inventory covering all attack surfaces (consensus, DA, bridge, P2P, state commitment details).

Implementation score: 0.75 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Primary source from StarkWare; credible high-level assessment but lacks exhaustive enumeration of all quantum-critical surfaces (consensus algorithm specifics, DA dependency details, bridge contract key management).

Blog post is a serious public acknowledgement of quantum risk, not merely marketing. However, it does not provide the granularity of a formal cryptographic inventory with per-component threat analysis.

• https://starkware.co/blog/quantum-computing-is-starknet-prepared/
• https://www.starknet.io/blog/bitcoin-quantum-security-with-starks/

Claim: Official documentation (docs.starknet.io) provides specifications for STARK field, STARK curve, Pedersen, Poseidon, and sn_keccak hash functions. Source code is open-source on GitHub. Falcon-512 PQC demo exists as third-party evidence of PQC viability.

Coverage basis: Public specifications, open-source code, and third-party PQC demonstration; no independent quantum-specific audit.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Code and specs are publicly verifiable. No independent quantum-specific audit exists; existing audits (Consensys Diligence for Argent, 2023) cover wallet contracts, not protocol-level quantum security.

The Falcon-512 demo (s2morrow.xyz) is a valuable third-party contribution demonstrating PQC viability, but it is not an official Starknet integration, has not been independently audited, and does not serve as a protocol-level evidence record.

• https://docs.starknet.io/learn/protocol/cryptography
• https://docs.starknet.io/learn/protocol/state
• https://github.com/starknet-io
• https://s2morrow.xyz/

Claim: Default account contracts use Stark curve ECDSA signatures. Account Abstraction enables optional use of PQC signatures; Falcon-512 verification has been demonstrated on mainnet via a third-party Cairo implementation (~9.5M L2 gas).

Coverage basis: Optional mainnet PQC path exists but is not default, mandatory, or widely adopted. Default remains ECC-only.

Implementation score: 0.75 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Default spend authorization uses Stark curve ECDSA (quantum-vulnerable); PQC path exists optionally but is not default, mandatory, or widely adopted.

Assurance: Falcon-512 verification on Starknet is evidenced by working third-party code (s2morrow.xyz), confirming mainnet viability. However, no production wallet has adopted PQC signatures as default, and the Falcon-512 implementation has not been independently audited for the Starknet context.

Implementation Score 0.75 reflects optional mainnet support (not default). The 'Mainnet PQC/hybrid-PQC exists, but active transactions remain vulnerable by default' cap (60) applies.

• https://docs.starknet.io/learn/protocol/accounts
• https://docs.starknet.io/learn/protocol/cryptography
• https://s2morrow.xyz/

Claim: Starknet uses smart contract accounts (no fixed EOAs). However, accounts that have sent transactions expose their Stark curve ECDSA public keys in transaction signatures. Account Abstraction enables key rotation but no default PQC key-derivation scheme exists.

Coverage basis: Design enables future migration but current production exposes ECC public keys; no PQ/hybrid key-derivation controls in production.

Implementation score: 0.25 · Evidence confidence: High

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

Quantum blocker: All transacted accounts have exposed ECC public keys on-chain with no migration enforcement; long-exposure quantum vulnerability exists.

Assurance: Account Abstraction is a genuine architectural advantage for future migration, but it does not protect current production users whose public keys are already exposed.

Starknet's AA model avoids the Ethereum EOA problem (where address is permanently bound to a single key pair), but current production behavior still results in ECC public key exposure in every transaction signature. Key rotation is possible but not enforced or prompted.

• https://docs.starknet.io/learn/protocol/accounts
• https://starkware.co/blog/quantum-computing-is-starknet-prepared/

Claim: Starknet's distributed sequencer architecture (v0.14.0+) uses Malachite BFT (Tendermint-based) with Ed25519 signing keys for validator authentication. Pathfinder consensus crate confirms Ed25519 public keys and signatures for consensus messages.

Coverage basis: No PQC or hybrid-PQC consensus authentication; entirely Ed25519 (quantum-vulnerable).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Consensus authentication (Malachite BFT / Pathfinder consensus) uses Ed25519 signatures, which are quantum-vulnerable.

Assurance: Ed25519 usage confirmed by pathfinder_consensus Rust crate documentation (SigningKey type alias = Ed25519 signing key). Malachite is a Tendermint-based BFT engine using classical signature schemes. No evidence of PQC integration in consensus layer.

Staking v3 (decentralized block validation) and v4 (fully decentralized consensus) are roadmap items in Phase 4 (in progress). Even when deployed, there is no evidence these will use PQC signatures by default. Current staking v2 (block attestation) uses classical signatures.

• https://docs.rs/pathfinder-consensus/latest/pathfinder_consensus/index.html
• https://github.com/circlefin/malachite
• https://nansen.ai/post/starknet-h2-2025-report
• https://www.starknet.io/roadmap/

Claim: STARK proofs are hash-based and quantum-resistant. State commitment uses Poseidon (top-level, algebraic hash) but contract trie leaf encoding and Merkle-Patricia trie nodes use Pedersen hash (ECC-based). Data Availability depends on Ethereum EIP-4844 blobs using KZG commitments (BLS12-381, quantum-vulnerable).

Coverage basis: Partial protection: STARK proof system is quantum-resistant, but DA layer (KZG) and state trie hashing (Pedersen) are quantum-vulnerable.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Data Availability relies on Ethereum EIP-4844 blobs using KZG polynomial commitments (BLS12-381), which are vulnerable to Shor's algorithm. State commitment contract trie and MPT nodes use Pedersen hash (ECC-based).

Assurance: The Pedersen hash vulnerability in the state commitment is partially mitigated by the STARK proof verifying state transitions — a Pedersen collision would need to produce a valid STARK proof to corrupt state. However, the KZG vulnerability in DA is a direct path to corrupting data availability verification, which could enable invalid state updates. v0.14.1 migrated compiled class hashes from Poseidon to Blake, but contract trie Pedersen usage remains.

The KZG/DA vulnerability is inherited from Ethereum L1 and is outside Starknet's direct control. It applies the 'Application-layer proof systems, bridge verification, or rollup settlement depend on quantum-vulnerable pairings or commitments' cap (70). Pedersen in state tries is a separate vulnerability that Starknet could address independently.

• https://docs.starknet.io/learn/protocol/state
• https://docs.starknet.io/learn/protocol/blocks
• https://docs.starknet.io/learn/protocol/cryptography
• https://quantumresistantcrypto.com/
• https://starkware.co/blog/quantum-computing-is-starknet-prepared/

Claim: STARK proofs rely on hash functions and polynomial testing rather than number-theoretic assumptions. Unlike SNARKs (Groth16, PLONK) that depend on elliptic curve pairings, STARKs are transparent and use hash-based security widely considered quantum-resistant.

Coverage basis: STARK proof system is quantum-resistant by design; well-evidenced by protocol documentation and academic understanding.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: STARK quantum resistance via hash-based assumptions is well-established in cryptographic literature. The production Starknet prover (S-two, deployed November 2025) is hash-based and inherits these properties.

This subfactor specifically concerns the ZK proof system assumptions. STARKs correctly avoid pairing-based cryptography. Starknet's choice of STARKs over SNARKs is the single strongest quantum-security architectural decision in the protocol.

• https://docs.starknet.io/learn/protocol/cryptography
• https://starkware.co/blog/quantum-computing-is-starknet-prepared/
• https://www.starknet.io/blog/bitcoin-quantum-security-with-starks/

Claim: Starknet nodes use libp2p for P2P communication. Malachite implements a validator proof protocol binding libp2p peer IDs to consensus public keys (Ed25519). Pure P2P transport authentication is not directly consensus, spend, bridge, or custody-critical.

Coverage basis: P2P transport authentication alone does not create a quantum-enabled path to asset compromise; satisfied by design for asset security.

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: P2P is scored as satisfied by design per QRI spec Section 7 example: 'P2P node identity uses classical cryptography, but all asset-spending authorization is PQ-signed on device and network identity is not consensus, spend, bridge, or custody-critical → P2P is satisfied by design.' Note: spend authorization is NOT PQ-signed in Starknet's case, but P2P authentication compromise alone still does not directly enable asset theft.

The Malachite validator proof protocol (ADR-006) adds an Ed25519-based proof binding libp2p PeerIds to consensus public keys. This is consensus-adjacent but scored under consensus authentication (2.3). Pure P2P transport without the consensus binding is satisfied by design.

• https://github.com/circlefin/malachite
• https://docs.rs/pathfinder-consensus/latest/pathfinder_consensus/index.html

Claim: Major Starknet wallets (Argent, Braavos) use Stark curve ECDSA for transaction signing. No evidence of production PQC wallet support, HSM integration, or hardware-wallet PQC signing paths.

Coverage basis: No production PQ/hybrid wallet, custody, or HSM workflow support.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Wallet support was inferred from documentation of major Starknet wallets (Argent, Braavos) which use Stark curve ECDSA signatures. No PQC hardware wallet or HSM integration was identified. Falcon-512 demo exists as Cairo code but is not integrated into any production wallet.

Account Abstraction theoretically enables wallet-level PQC migration without protocol changes, but no major wallet has implemented this. The gap between technical capability (AA + Falcon-512) and production adoption is significant.

• https://docs.starknet.io/learn/protocol/accounts
• https://www.starknet.io/blog/how-braavos-on-starknet-is-revolutionizing-crypto-signing/
• https://eco.com/support/en/articles/15254043-argent-wallet-deep-dive-2026-starknet-and-account-abstraction

Claim: Essentially 0% of Starknet economic value is protected by PQC signatures. All active accounts use Stark curve ECDSA. No value has been migrated to PQC-controlled accounts.

Coverage basis: <25% coverage; effectively 0% of value-at-risk is quantum-protected.

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path.

Assurance: Coverage estimate is conservative. No on-chain measurement of PQC-protected value is possible because PQC adoption is negligible. All evidence points to near-0% PQC protection of economic value.

Starknet is not PQ-native; it launched with ECC-based signatures and has not completed migration. The 'Material long-exposure quantum-vulnerable value exists with no migration path' cap (55) applies.

• https://starkware.co/blog/quantum-computing-is-starknet-prepared/
• https://docs.starknet.io/learn/protocol/accounts

Claim: No evidence that any critical wallets (foundation treasuries, exchanges, custodians, bridges, major protocols) have migrated to PQC-controlled accounts on Starknet.

Coverage basis: No critical wallet migration identified.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: No public attestations or on-chain evidence of PQC migration by critical wallets were identified. Absence of evidence is treated conservatively as no migration.

This is a significant gap. Even if retail users could theoretically upgrade via AA, critical infrastructure wallets (bridges, treasuries, foundation) represent concentrated value-at-risk that should be prioritized for PQC migration.

Claim: StarkWare's December 2024 blog post acknowledges the vulnerability of current signing methods and Pedersen hash. No formal program exists to identify, measure, deprecate, or freeze vulnerable accounts.

Coverage basis: Vulnerability acknowledged in public assessment; no measurement, deprecation, or migration program in production.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The blog post acknowledges vulnerability but does not constitute a formal measurement, deprecation, or migration program. No on-chain analytics or public dashboard for quantum-vulnerable value were identified.

Starknet's smart-contract account model means 'legacy pools' are less clearly defined than UTXO-based chains, but all accounts using Stark curve ECDSA are effectively a single large vulnerable pool.

• https://starkware.co/blog/quantum-computing-is-starknet-prepared/

Claim: Starknet roadmap Phase 4 (in progress) lists 'Quantum-resistant cryptography.' StarkWare blog discusses migration path via Poseidon hash and Account Abstraction for wallet signatures. No detailed sequencing, activation criteria, or dependency map published.

Coverage basis: Roadmap and proposal-level documentation exists; prototype Falcon-512 verification demonstrated.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Roadmap is official but high-level. Phase 4 is marked 'in progress' as of March 2026 but 'Quantum-resistant cryptography' is listed alongside other features with no dedicated timeline, sequencing, or technical specification.

The Falcon-512 demo provides evidence that the technical migration path is viable, but the roadmap lacks the specificity needed for institutional planning (no activation criteria, no migration phases, no dependency mapping for consensus/DA/bridge layers).

• https://www.starknet.io/roadmap/
• https://starkware.co/blog/quantum-computing-is-starknet-prepared/
• https://s2morrow.xyz/

Claim: Account Abstraction enables PQC wallet upgrades without protocol hard forks. Falcon-512 verification is available as Cairo code. However, no default PQC account creation exists, no user-facing migration warnings or prompts are deployed, and no wallet has adopted PQC as default.

Coverage basis: Optional PQC path exists (Falcon-512 via AA) but is not default, prompted, or user-accessible without technical expertise.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Assurance: The Falcon-512 demo proves PQC migration is technically feasible on Starknet mainnet. However, the path from technical demo to default user experience (wallet integration, key generation UI, gas cost optimization) remains unimplemented.

The 'Users can still create new quantum-vulnerable high-value accounts by default' cap (60) applies. Starknet's AA architecture is genuinely superior to Ethereum's EOA model for migration, but the gap between capability and accessibility is large.

• https://s2morrow.xyz/
• https://docs.starknet.io/learn/protocol/accounts
• https://starkware.co/blog/quantum-computing-is-starknet-prepared/

Claim: No enforcement mechanisms exist: no deprecation of ECC signatures, no disabled legacy signing, no restricted withdrawals to vulnerable addresses, no mandatory migration deadlines, and no exchange/custody/bridge coordination for PQC migration.

Coverage basis: No enforcement or coordination mechanisms in production.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence of enforcement mechanisms is confirmed by the lack of any public documentation, governance proposals, or protocol parameters related to ECC deprecation or PQC enforcement.

Without enforcement mechanisms, migration relies entirely on voluntary user action. Given the historical difficulty of coordinating voluntary cryptographic migrations (e.g., Ethereum's slow EOA-to-smart-contract-account transition), this represents a significant practical barrier to achieving quantum readiness.

Claim: No public quantum-specific incident-response process, emergency disclosure mechanism, or governance procedure for quantum vulnerabilities was identified.

Coverage basis: No quantum-specific emergency process documented.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Starknet has a Security Council for governance and a general incident response capability (demonstrated in the January 2026 incident report). However, no quantum-specific IR playbook, disclosure process, or emergency upgrade path for quantum vulnerabilities was identified.

Per QRI v3.1 Note-Only Caveat Rule: lack of a formal quantum-specific incident-response playbook is treated as an assurance-only caveat since it does not by itself create a current quantum-enabled attack path. It is noted here for institutional awareness.

Claim: Falcon-512 (NIST-standardized PQC signature scheme) has been demonstrated on Starknet. Poseidon hash (used in state commitment and block hashing) is a broadly reviewed algebraic hash. STARK proofs use well-reviewed hash-based constructions.

Coverage basis: NIST-standardized PQC algorithm (Falcon-512) validated for optional use; core proof system uses well-reviewed hash constructions. Default signatures remain non-PQC.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Falcon-512 is a NIST-standardized PQC algorithm (FIPS 204 draft standard). Poseidon is not NIST-standardized but has undergone significant academic review as a ZK-optimized hash function. Pedersen hash (still used in contract trie) is ECC-based and not quantum-resistant.

Score is 0.50 because while NIST-standardized PQC algorithms are validated for optional use, the production protocol defaults to non-PQC algorithms (Stark curve ECDSA, Pedersen).

• https://s2morrow.xyz/
• https://docs.starknet.io/learn/protocol/cryptography

Claim: No independent quantum-specific cryptographic audit of Starknet's production protocol, PQC integration path, or Falcon-512 Cairo implementation was identified. Existing audits cover wallet contracts (e.g., Argent) but not protocol-level quantum security.

Coverage basis: No quantum-specific independent audit exists for the production scope.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Per QRI v3.1: 'No independent audit and the quantum-security property cannot be verified from other public evidence → Lower Implementation Score or apply a Readiness & Risk Cap.' Here, the STARK proof quantum resistance IS verifiable from public evidence (academic literature, protocol design), but the Falcon-512 implementation and overall PQC migration path have not been independently audited. Score reduced to 0.25 to reflect absent quantum-specific audit for non-STARK components.

Existing audits (Consensys Diligence for Argent 2023, BlockApex) cover smart contract security, not quantum-specific cryptographic assurance. A dedicated quantum-security audit covering the PQC signature integration, state commitment quantum resistance, and migration path would be valuable.

• https://diligence.security/audits/2023/06/argent-account-multisig-for-starknet/
• https://blockapex.io/starknet-smart-contract-security-audit/

Claim: Core Starknet cryptography (STARK field, STARK curve, Pedersen, Poseidon, sn_keccak) is specified in official documentation with reference implementations available on GitHub. Falcon-512 Cairo verification code is available via s2morrow.xyz. Malachite consensus engine is open-source (Apache 2.0).

Coverage basis: All quantum-critical implementations are open-source and reproducible.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: All major components are open-source with permissive licenses. Reference implementations in Python (cairo-lang) and Cairo exist for hash functions. Malachite (Apache 2.0) and Pathfinder consensus are open-source Rust crates.

Strong open-source posture across the stack. The Falcon-512 Cairo implementation is third-party but publicly available and reproducible.

• https://github.com/starknet-io
• https://github.com/circlefin/malachite
• https://docs.starknet.io/learn/protocol/cryptography
• https://s2morrow.xyz/

Claim: Starknet has demonstrated parameter agility through the Poseidon-to-Blake compiled class hash migration (v0.14.1, December 2025). Account Abstraction provides an upgrade path for wallet signatures. Roadmap documents multiple cryptographic transitions. No formal parameter-agility specification for quantum migration exists.

Coverage basis: Demonstrated agility (Poseidon→Blake) and documented upgrade path (AA for signatures); no formal quantum-specific parameter-agility specification.

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The successful v0.14.1 deployment with smooth Poseidon-to-Blake migration of compiled class hashes (completed within blocks, no issues) demonstrates real-world parameter agility. The All Core Devs call #42 confirmed contract migration success.

Score is 0.75 rather than 1.00 because while agility has been demonstrated for hash functions, no formal specification exists for the more complex migration of consensus signatures, state trie hashing, or bridge dependencies.

• https://docs.starknet.io/learn/cheatsheets/version-notes
• https://github.com/starknet-io/pm/blob/main/AllCoreDevs-Full-Nodes-Meetings/call_042.md
• https://www.starknet.io/roadmap/

Claim: Falcon-512 is a stateless signature scheme (unlike XMSS/LMS), so stateful-signature concerns do not apply. No side-channel analysis, fault-injection assessment, or HSM/custody implementation review for PQC on Starknet was identified.

Coverage basis: Stateless signature scheme avoids state-management risks; no other PQC implementation risk analysis exists.

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Falcon-512 being stateless is an advantage over XMSS/LMS for blockchain use cases. However, Falcon implementations have known side-channel concerns (floating-point operations, timing variability) that have not been assessed in the Starknet/Cairo context. No HSM or hardware-wallet PQC integration analysis exists.

Per QRI v3.1: lack of formal side-channel analysis for an optional PQC path that is not yet materially protecting production users is treated as an assurance-only caveat. This should be addressed before PQC becomes default.

Claim: Falcon-512 signature verification on Starknet costs ~9.5M L2 gas (documented by s2morrow.xyz). This is a real measurement on mainnet. No comprehensive performance analysis exists covering block validation impact, mempool policy, archival growth, or validator/node hardware requirements under PQC.

Coverage basis: Preliminary performance data exists (Falcon-512 gas cost); no comprehensive resource-impact analysis for production PQC deployment.

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The ~9.5M L2 gas cost for Falcon-512 verification is a valuable real-world measurement. For context, this is significantly higher than Stark curve ECDSA verification (~hundreds of thousands of gas). STARK-based signature aggregation (as proposed by BTQ) could mitigate this but has not been productionized.

Per QRI v3.1: 'Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment.' The s2morrow.xyz measurement partially satisfies this. Score 0.75 reflects that data exists but is not comprehensive (no block-level impact analysis, no consensus performance modeling, no archival growth projections).

• https://s2morrow.xyz/