L2 network token
POL (ex-MATIC) POL
POL (ex-MATIC) is the native gas and staking token of Polygon PoS, an Ethereum L2 scaling network. As of June 2026, all production cryptographic mechanisms on Polygon PoS rely entirely on quantum-vulnerable classical cryptography: secp256k1 ECDSA for spend authorization (Bor block production, Heimdall account authentication) and BLS signatures for Heimdall checkpoint consensus. POL also exists as a standard ERC-20 token on Ethereum L1, inheriting Ethereum's full ECDSA vulnerability for L1 transfers and staking. The Polygon zkEVM — which had a partially PQ-safe STARK proof foundation — is confirmed to be sunset on July 1, 2026. AggLayer uses SP1 zkVM with Plonky3 SNARK-based proving with pairing-dependent cryptography. ERC-4337 account abstraction provides an optional theoretical path to PQ signatures via smart-contract wallets, but no Polygon-provided PQ implementation, tooling, or migration guidance exists. Polygon Labs has published no quantum risk assessment, cryptographic inventory, PQ roadmap, migration plan, or quantum-specific incident-response process. The Least Authority audit (2023) predates Heimdall v2 and contains no quantum scope. Score of 10/100 reflects Stage 1 (Quantum Risk Assessed) with no meaningful production protection, capped by the absence of any PQ spend authorization, complete ECC/BLS dependence across all consensus and transaction layers, unrestricted two-way bridge to quantum-vulnerable Ethereum L1, and material long-exposure value-at-risk with no migration path.
Partial ProtectionQuantum-vulnerable consensusQuantum-vulnerable spend authorizationL1-dependentTwo-way bridge exposure
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
8.25 / 35
Security Assessment & Evidence Preparedness
1.75 / 5
Critical Quantum Blockers
- All production spend authorization on Polygon PoS uses secp256k1 ECDSA exclusively — fully quantum-vulnerable to Shor's algorithm (Cap: 40)
- All consensus-critical authentication uses secp256k1 (Bor block producers) and BLS (Heimdall checkpoint signatures) — fully quantum-vulnerable (Cap: 70)
- POL exists as an ERC-20 on Ethereum L1 and inherits Ethereum's ECDSA vulnerability for all L1 transfers and staking operations (Cap: 40)
- Two-way POL bridge between Ethereum L1 and Polygon PoS allows unrestricted value flow between quantum-vulnerable systems with no PQ restrictions (Cap: 50)
- Material long-exposure quantum-vulnerable value exists across all transacted EOAs, staked POL, bridge contracts, and validator keys with no migration, freeze, deprecation, or recovery path (Cap: 55)
- No public quantum risk assessment, cryptographic inventory, or mitigation roadmap has been published by Polygon Labs (Readiness & Risk Cap: 10)
Key Risks
- Quantum-enabled theft: All POL on both Polygon PoS and Ethereum L1 is secured by secp256k1 ECDSA. Any account that has sent a transaction has an exposed public key on-chain, vulnerable to offline attack via Shor's algorithm. This includes staked POL, bridge contracts, exchange wallets, and all transacted EOAs.
- Consensus compromise: Bor block producers sign with secp256k1 and Heimdall validators sign checkpoints with BLS. A quantum adversary could forge validator signatures to finalize fraudulent checkpoints or produce malicious blocks, potentially enabling double-spend attacks, bridge theft, or chain reorganization.
- Bridge vulnerability: The two-way POL bridge between Ethereum L1 and Polygon PoS has no PQ restrictions. A quantum attacker compromising either side could drain bridge contracts. The AggLayer's Plonky3/SP1 proving system relies on pairing-based cryptography that is quantum-vulnerable.
- L1 inheritance risk: POL's ERC-20 representation on Ethereum L1 means all L1 staking, governance, and transfer operations are secured by Ethereum's ECDSA, which is quantum-vulnerable. Polygon PoS cannot independently mitigate this exposure.
- No migration path: There is no public plan, timeline, governance proposal, or technical specification for migrating Polygon PoS validators, users, or bridge infrastructure to PQ cryptography. In the event of a quantum breakthrough, all value on Polygon PoS would be at immediate risk with no coordinated response mechanism.
- Dormant and unmigratable value: Long-dormant POL holdings, abandoned contracts, lost keys, and unresponsive staking delegations have no identified deprecation, freeze, or salvage policy, representing permanently quantum-vulnerable value.
- zkEVM sunset eliminates partial PQ protection: The zkEVM's STARK-based proof system offered partial PQ safety for proof generation. Its confirmed sunset on July 1, 2026 removes this limited protection from the ecosystem without a replacement.
Assurance Notes
- Least Authority audit of Bor/Heimdall (July 2023) predates Heimdall v2 and contains no quantum or PQC review scope. It provides general implementation assurance for the classical codebase but is stale for the current production version.
- No quantum-specific audit has been performed on any Polygon PoS component (Bor, Heimdall v2, bridge contracts, AggLayer).
- The Polygon zkEVM is confirmed to be sunset on July 1, 2026, making its partially PQ-safe STARK proof foundation irrelevant to the long-term production security posture.
- AggLayer uses SP1 zkVM with Plonky3 proving system, which is SNARK-based and relies on pairing-dependent cryptography that is quantum-vulnerable.
- ERC-4337 account abstraction is available on Polygon PoS, enabling optional smart-contract wallets that could theoretically implement PQ signature schemes, but no Polygon-provided PQ signature implementation exists.
- No formal quantum-specific incident-response playbook, security contact for quantum disclosures, or quantum threat model has been published by Polygon Labs.
- LayerQu independently rates Polygon PoS at Migration Stage 0 (Unaware) with QRI 24/100 as of 2026.
- Ethereum Foundation maintains a structured PQ roadmap (pq.ethereum.org) targeting 2029 for core PQ infrastructure; Polygon PoS has published no equivalent plan and would inherit any Ethereum L1 PQ upgrades only for its L1 settlement dependency.
Non-Scoring Caveats
- ERC-4337 account abstraction provides an optional theoretical path to PQ spend authorization via smart-contract wallets, but no Polygon-provided PQ signature implementation, tooling, or migration guidance exists. This optional infrastructure does not materially protect production users.
- The Least Authority audit (2023) is stale and lacks quantum scope; this affects Confidence but not the QRI Score since the quantum-vulnerable design is independently verifiable from official documentation and open-source code.
- Polygon CDK and AggLayer documentation describe ZK-based security models but make no mention of post-quantum considerations, algorithm selection, or migration planning.
- Ethereum L1's PQ roadmap (pq.ethereum.org) may eventually provide PQ security for the L1 settlement layer, but Polygon PoS has not articulated how or when it would adopt or coordinate with these upgrades.
- No formal performance or resource-impact analysis exists for PQ signature deployment on Polygon PoS, though this does not affect current quantum-attack readiness.
- Missing exchange or custody migration attestations do not independently reduce the QRI Score since the native protocol has no PQ path for exchanges to attest to.
Evidence record
Claims and Caveats
spend_authorization
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Polygon PoS (Bor) uses secp256k1 ECDSA for all transaction and block-production signatures. ERC-4337 account abstraction provides an optional theoretical path to PQ signatures via smart-contract wallets.
Coverage basis: Production mainnet; all transactions on Polygon PoS use secp256k1 by default. ERC-4337 is deployed but no PQ signature implementation is provided by Polygon.
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All production spend authorization uses secp256k1 ECDSA exclusively — fully quantum-vulnerable (Cap: 40)
Assurance: Official Polygon docs confirm secp256k1 for Bor and Heimdall. ERC-4337 availability confirmed by secondary sources. No Polygon-provided PQ signature implementation exists.
ERC-4337 provides an optional mainnet path (Implementation Score 0.25 per 'public design/specification deployed on mainnet enabling the possibility' rather than 0.75 because no Polygon-provided PQ signature scheme, tooling, or migration guidance exists within the ERC-4337 path). Default EOA accounts remain fully ECC-only.
account_address_public_key_exposure
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: Polygon PoS uses standard Ethereum-style accounts. Public keys are exposed on-chain for any account that has sent a transaction. ERC-4337 smart accounts could theoretically use PQ keys.
Coverage basis: Production mainnet; standard EVM account model with secp256k1 key derivation. No PQ/hybrid account creation path provided by Polygon.
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All transacted EOAs have exposed secp256k1 public keys — long-exposure quantum-vulnerable with no migration path
Assurance: Standard EVM account model confirmed by official docs and Etherscan contract verification.
ERC-4337 provides a theoretical path to PQ key derivation via smart accounts, but no Polygon-provided implementation exists. Default account creation remains fully ECC-exposed.
consensus_authentication
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Bor block producers sign blocks with secp256k1 ECDSA. Heimdall validators use secp256k1 for account authentication and BLS for checkpoint signatures.
Coverage basis: Production mainnet consensus; all validator operations use classical cryptography.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All consensus authentication uses secp256k1 and BLS — fully quantum-vulnerable (Cap: 70)
Assurance: Official Polygon docs confirm secp256k1 for Bor block production and Heimdall auth, plus BLS for checkpoint signatures. Google Quantum AI / arXiv research (March 2026) confirms BLS quantum vulnerability.
No evidence of PQ or hybrid consensus signature support in any Polygon PoS component.
state_integrity
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Heimdall checkpoints use BLS signatures (quantum-vulnerable). Polygon zkEVM used STARKs (PQ-safe) but is being sunset July 1, 2026. AggLayer uses SP1 zkVM with Plonky3 (SNARK-based, pairing-dependent, quantum-vulnerable).
Coverage basis: Production mainnet; Heimdall BLS checkpoints and AggLayer Plonky3/SP1 proofs are the primary state-integrity mechanisms.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: BLS checkpoint signatures and Plonky3/SP1 pairing-based proofs are quantum-vulnerable; zkEVM STARK protection being sunset
Assurance: AggLayer architecture confirmed by official docs. zkEVM sunset confirmed by Polygon official announcement (July 1, 2026). Plonky3 is SNARK-based per Polygon blog posts. No quantum-specific audit of state-integrity mechanisms.
Implementation Score 0.25 reflects the historical existence of STARK-based proofs in the zkEVM (now sunset) and the theoretical PQ-safety of STARK primitives. The primary production path (Heimdall BLS + AggLayer Plonky3/SP1) is fully quantum-vulnerable.
- https://docs.polygon.technology/pos/architecture/heimdall_v2/authentication
- https://docs.polygon.technology/interoperability/agglayer/core-concepts/architecture
- https://polygon.technology/blog/succincts-sp1-built-with-polygon-plonky3-will-help-enable-performant-cross-chain-interoperability-for-the-agglayer
privacy_proof_layers
Privacy and proof layers are quantum-safe where applicable
Claim: Polygon zkEVM used STARK-based Plonky2/3 recursion (PQ-safe foundation) but the final SNARK wrapper on Ethereum L1 is pairing-based (quantum-vulnerable). zkEVM is being sunset July 1, 2026.
Coverage basis: Production zkEVM (being sunset); AggLayer uses Plonky3/SP1 which is SNARK-based.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: SNARK wrapper on L1 is pairing-based and quantum-vulnerable; zkEVM sunset removes partial STARK protection
Assurance: AggLayer uses SP1 zkVM with Plonky3 proving system. zkEVM sunset confirmed by official Polygon announcement.
Implementation Score 0.25 acknowledges the STARK foundation in Polygon's ZK history and the theoretical PQ-safety of STARKs, but the current production proof system is quantum-vulnerable and the zkEVM is being retired.
p2p_transport
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: P2P networking uses standard Geth (Bor) and Cosmos SDK (Heimdall) networking stacks with classical cryptography.
Coverage basis: Production mainnet P2P layer.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: P2P identity is not independently verified; assumed to use classical cryptography based on Geth/Cosmos SDK defaults.
P2P is not satisfied by design because spend authorization is not PQ-signed (see QRI Section 7 applicability example).
wallet_custody
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: Standard Ethereum wallet workflows (MetaMask, etc.) use secp256k1. No PQ wallet support exists.
Coverage basis: Production wallet ecosystem.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ wallet, custody, or HSM path exists for Polygon PoS
Assurance: POL token documentation confirms standard ERC-20 and EVM wallet compatibility. No PQ wallet support announced or documented.
Since no production PQ path exists at the protocol level, wallet/custody PQ support cannot exist. This is a downstream consequence of the protocol-level gap.
migration_value_at_risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: No migration has occurred. All POL value on both Polygon PoS and Ethereum L1 is secured by quantum-vulnerable cryptography.
Coverage basis: Total circulating supply and staked value across both chains.
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: <25% value-at-risk protected; effectively 0% — all POL value quantum-vulnerable (Cap: 55)
Assurance: POL contract verified on Etherscan. No migration events or protected value pools identified.
Coverage score of 1 (out of 20) per QRI coverage thresholds for <25%. This is the minimum non-zero score. Effectively 0% of value is protected.
critical_wallets
Critical wallets migrated, protected, or inherently PQ-native
Claim: No evidence of any critical wallet (treasury, exchange, custody, bridge, foundation) being migrated to PQ protection.
Coverage basis: All known critical wallets.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No critical wallets migrated or protected
Assurance: No public attestations, migration transactions, or announcements from Polygon, exchanges, or custodians regarding PQ migration.
Absence of evidence is treated as evidence of absence for migration claims. No migration has occurred.
legacy_pools
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No legacy pool identification, deprecation, or migration activity has been published.
Coverage basis: All quantum-vulnerable accounts and contracts.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No legacy vulnerable pool identification or deprecation mechanism exists
Assurance: Polygon Labs has not published any analysis of quantum-vulnerable value pools.
This includes dormant POL, staked POL in long-term delegations, bridge-locked POL, and MATIC-to-POL migration remnants.
migration_roadmap
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No quantum migration roadmap has been published by Polygon Labs.
Coverage basis: All Polygon Labs official communications and documentation.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No PQ roadmap or migration plan exists
Assurance: Extensive blog and documentation review through June 2026 shows no PQ-related content from Polygon Labs. Contrast with Ethereum Foundation (pq.ethereum.org) and Optimism (published 10-year PQ roadmap).
Polygon blog focuses on AggLayer, CDK, stablecoins, payments, and institutional adoption. No quantum security content found.
migration_accessibility
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts
Claim: No PQ account creation, wallet tooling, migration prompts, or user education exists.
Coverage basis: All user-facing Polygon infrastructure.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ migration accessibility features exist
Assurance: No evidence of PQ wallet support, migration prompts, or user education from Polygon or ecosystem partners.
ERC-4337 is the only infrastructure that could theoretically support PQ migration, but no Polygon-provided tooling or guidance exists.
migration_enforcement
Migration enforcement and coordination mechanisms
Claim: No enforcement mechanisms, deprecation policies, freeze capabilities, or exchange/bridge coordination for quantum migration exist.
Coverage basis: All Polygon governance and protocol enforcement mechanisms.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No migration enforcement or coordination mechanisms exist
Assurance: No governance proposals, PIPs, or forum discussions about quantum migration enforcement found.
Two-way bridge to Ethereum L1 has no PQ restrictions — value can freely flow into quantum-vulnerable systems.
emergency_process
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No quantum-specific incident response process or disclosure mechanism has been published.
Coverage basis: All Polygon Labs security and governance documentation.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Polygon has general security processes but no quantum-specific playbook. This is recorded as an assurance caveat rather than a score deduction since the absence of a quantum-specific playbook does not independently create a quantum-attack path beyond those already identified.
Treated as note-only per QRI Section 7.4: lack of formal quantum-specific IR playbook does not independently reduce QRI Score when quantum-vulnerable paths are already identified and scored.
security_assessment
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: Polygon's official documentation describes cryptographic mechanisms (secp256k1, BLS) but no quantum-focused inventory or threat model has been published by Polygon Labs.
Coverage basis: All Polygon Labs official publications.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory or quantum threat model published by project
Assurance: Cryptographic primitives are documented in official docs but not organized as a quantum risk inventory. No threat model covering quantum attack assumptions exists.
Implementation Score 0.25 reflects that cryptographic primitives are documented (secp256k1, BLS) in official architecture docs, enabling external assessment, but no quantum-focused inventory or threat model has been published by Polygon Labs.
evidence_preparedness
Public evidence record supporting the assessment
Claim: Official documentation, open-source code (GitHub), and a stale audit (Least Authority 2023) provide evidence of classical cryptographic usage.
Coverage basis: Official docs, GitHub repos, Etherscan, Least Authority audit.
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Code is open-source and verifiable. Audit is stale (2023, pre-Heimdall v2) and contains no quantum scope. Evidence supports vulnerability assessment but not any PQ claims.
Implementation Score 0.50 reflects that evidence exists (code, docs, stale audit) but is not organized as a quantum readiness evidence record and lacks quantum-specific review.
algorithm_choices
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: No PQC algorithms are in use in any Polygon PoS component.
Coverage basis: All production Polygon PoS cryptography.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQC algorithms used in any production component
Assurance: Official docs confirm exclusive use of secp256k1 and BLS. No NIST PQC standards (FIPS 203/204/205) referenced in any Polygon documentation.
independent_audit
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: Least Authority audited Bor and Heimdall in 2023 with no quantum scope. No quantum-specific audit exists.
Coverage basis: Least Authority audit (2023); no quantum audit.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The Least Authority audit (2023) is pre-Heimdall v2, contains no quantum or PQC review scope, and is stale for the current production version. Treated as note-only per QRI Section 7.4: stale audit does not independently reduce QRI Score when quantum-vulnerable design is verifiable from other evidence.
Audit age and scope gap recorded in Confidence and Assurance Notes. The quantum-vulnerable design (secp256k1, BLS) is independently verifiable from official documentation and open-source code.
open_source
Open-source, reproducible implementation
Claim: Bor and Heimdall are open-source (Geth/Cosmos SDK forks). No PQC implementation exists to be open-sourced.
Coverage basis: GitHub repositories.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Classical implementation is open-source. No PQC implementation exists to evaluate for this subfactor.
Implementation Score 0.00 because there is no PQC implementation to be open-source or reproducible. The classical codebase being open-source does not earn credit in this category.
parameter_agility
Parameter agility and future upgrade path are documented
Claim: No parameter agility or PQC upgrade path has been documented.
Coverage basis: All Polygon documentation.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No documentation of cryptographic agility, algorithm replacement procedures, or upgrade paths found.
stateful_signature_safety
Stateful-signature safety, side-channel, fault-injection, and implementation risks considered
Claim: Not applicable — no PQC signatures are in use.
Coverage basis: N/A — no PQC implementation.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: No PQC signatures in use; subfactor cannot be evaluated.
Scored 0.00 because no PQC implementation exists to assess for stateful-signature safety.
performance_analysis
Performance and resource-impact analysis for PQ signature/verification costs
Claim: No performance analysis for PQ deployment on Polygon PoS has been published.
Coverage basis: All Polygon publications.
Implementation score: 0 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Treated as note-only per QRI Section 7.4: missing formal benchmark does not independently reduce QRI Score when no PQ path exists to benchmark. Third-party analysis (Stackademic, May 2026) discusses Polygon CDK as a theoretical mitigation for PQ signature bloat.
Third-party analysis notes that Polygon CDK architecture could theoretically mitigate PQ signature size overhead through ZK proof aggregation, but this is not a Polygon-published analysis and no production implementation exists.
bridge_or_wrapped_asset_dependencies
Two-way bridge or wrapper dependency on quantum-vulnerable systems
Claim: POL bridge between Ethereum L1 and Polygon PoS is unrestricted two-way. POL ERC-20 on Ethereum L1 inherits full Ethereum quantum vulnerability.
Coverage basis: Production POL bridge and ERC-20 contract.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: Unrestricted two-way bridge allows value flow into quantum-vulnerable Ethereum L1 (Cap: 50)
Assurance: POL contract verified on Etherscan. Bridge behavior confirmed by official Polygon docs.
This is not a scored subfactor in the five categories but is recorded as an architectural dependency that triggers the Readiness & Risk Cap at 50 for two-way bridge to non-PQ-secure system.
Report metadata