Polygon PoS publishes no cryptographic primitive inventory of its own. Neither ECDSA nor secp256k1 is named in the chain's documentation, its improvement-proposal repository or its blog as a statement of what the chain uses, and keccak256 appears in the improvement-proposal repository only as the hash applied to a committed consensus key rather than as an inventory entry. The inventory above is nonetheless firm rather than assumed, because two official artifacts pin it independently. The validator-admission proposal in peer review records keccak256 of a committed 64-byte consensus key, and a 64-byte public key is an uncompressed secp256k1 point. The August 2026 consensus-layer security release normalizes the recovery byte on checkpoint signatures so that a validly signed checkpoint cannot be submitted to Ethereum in a form that fails signature recovery, and a recovery byte exists only in the (r, s, v) encoding of a recoverable ECDSA signature. Between them those two artifacts establish the consensus-layer primitive directly, and the account-layer primitive follows from the chain's stated Go-Ethereum derivation. Credit is for a primitive set that is precise, checkable and complete across both layers and both transports. The deduction is for the chain publishing none of it itself, which is the thing the sub-score measures, and for no post-quantum primitive appearing anywhere in the stack.

Polygon PoS publishes no per-primitive quantum classification of its own, so the classification above is reconstructed. Unlike an inventory with unnamed surfaces, this one closes completely: every authorization and transport primitive on both layers can be tagged, and every one of them falls into the Shor-break or Grover-weaken columns. Not a single primitive in the stack is post-quantum safe, and no primitive carries a developing-confidence problem either, because Keccak-256, SHA-256 within HKDF, ChaCha20-Poly1305, secp256k1 and X25519 are all long-studied constructions with no research-grade hash such as Poseidon on a security-critical path. There is also no pairing-based or discrete-log proof system in consensus, because Polygon PoS is not a validity rollup and settles by checkpointing a Merkle root rather than by verifying a proof. Credit is for a classification that is complete and unambiguous across every surface. The deduction is that a complete classification of an entirely Shor-breakable stack is the maximum-exposure result, and the chain does not publish the classification itself.

Zero post-quantum algorithm families are deployed, which scores 0 under the family-count rule. No lattice family appears anywhere in the stack: no ML-DSA per FIPS 204, no Falcon-512 or Falcon-1024 per the round-3 submission, no ML-KEM per FIPS 203. No hash-based family appears: no SLH-DSA per FIPS 205, no XMSS or XMSS^MT per RFC 8391, no LMS or HSS per RFC 8554, no Winternitz one-time signature construction. No code-based family appears, and in any case Classic McEliece, BIKE and HQC are key-encapsulation mechanisms rather than signature schemes, so none of them could serve as the second signature family this sub-score counts. There is no monoculture here to discount; there is an empty set. The standardization-maturity clause that allows a second family to partially lift the diversity ceiling has no first family to apply to, and the Cryptographic-Diversity Cap therefore does not bind, because the cap addresses a deployed lattice monoculture and nothing lattice-based is deployed.

No NIST post-quantum security category can be read from any Polygon PoS artifact, because no post-quantum primitive is named in one. The primitives actually in use carry no such category: ECDSA over secp256k1 and X25519 are pre-quantum elliptic-curve constructions outside the category 1 to 5 mapping, and Keccak-256 and ChaCha20-Poly1305 are symmetric primitives whose Grover margin is a separate calculation from the NIST post-quantum categories. There is no partial credit to award, because the sub-score measures whether a chain has specified the security level of its post-quantum choices, for instance ML-DSA-44 at category 2 against ML-DSA-87 at category 5, and Polygon PoS has made no such choice at any level.

Library provenance is the strongest component. Bor is a Go-Ethereum fork and heimdall-v2 is an explicit fork of CometBFT and the Cosmos SDK, so the secp256k1, Keccak-256, AES-128-CTR, X25519, HKDF-SHA256 and ChaCha20-Poly1305 implementations are the long-lived, widely reviewed upstream ones rather than bespoke code, and both forks are public and tagged per release. Cryptanalytic maturity is correspondingly high: every primitive on a security-critical path is tier 1 or tier 2, with no research-grade hash and no lattice implementation to carry a discount. Operational security posture is documented and dated: an in-house security team of more than ten full-time engineers, periodic first-party and third-party assessments and penetration tests, bug bounties paying up to one million dollars for network-infrastructure vulnerabilities, and an ISO 27001-based program. The August 2026 release pair demonstrates that posture working, having been developed privately, validated on the Amoy testnet, activated on mainnet and only then disclosed. The deductions are substantial. No formal verification applies to anything in this stack, and none is claimed. Constant-time behavior is not independently verified here; the upstream libraries' own claims are the basis, and no dudect-style validation or timing-leak audit is published for either client. The stateful-versus-stateless distinction has nothing to assess, and the deployed-verifier provenance component has nothing to assess, because there is no post-quantum verifier deployed. And one of the two August 2026 releases exists precisely because a validly signed checkpoint could be submitted to Ethereum in a recovery-byte encoding that fails signature recovery and stalls checkpoint anchoring, a defect in the chain's own handling of ECDSA signature encoding rather than in the primitive; it was found and fixed, which is the right outcome, but it is a signature-handling defect in a consensus-critical path all the same.

Polygon PoS uses the Ethereum account model, so an address is the low-order 20 bytes of the Keccak-256 hash of the public key until the account sends its first transaction, at which point the full secp256k1 public key is recoverable from the signature and stays recoverable forever. Every account that has ever transacted therefore sits in the exposed-after-spend bucket permanently, and the chain is designed for payment throughput above a thousand transactions per second, which moves accounts into that bucket quickly and keeps them there. The Heimdall validator set is worse placed still: a Signer Key is described in the Heimdall validator key-management documentation as a hot key held on the validator node and used continuously for signing Heimdall blocks and checkpoints, and every checkpoint it signs publishes a recoverable ECDSA signature on Ethereum, so the validator public key is derivable from public L1 data and is not merely exposed but published by the protocol's normal operation. In the most recent published stake series, with data as of 1 March 2026, named exchange operators run three of the top five validators by stake, so that standing exposure sits on consensus-critical keys held by high-value custodial operators. No public source publishes the split of Polygon PoS supply between exposed-active, exposed-dormant and never-revealed addresses, so the exposure cannot be quantified against total value, only established as structural and near-universal for active accounts. The small credit is for the hashed-address construction, which is a genuine mitigation and is what separates this from a chain that publishes raw account public keys at creation.

An externally-owned account that has never sent a transaction is in the mitigated-until-spend state: its address is a Keccak-256 hash truncated to 20 bytes and its public key has never appeared on chain, so a CRQC running Shor has no public key to attack. That is a real structural mitigation and it covers every dormant, never-spent balance on the chain, which is why this sub-score sits well above the active-key one. Three deductions apply. The truncation to 20 bytes means the address commits to only 160 bits, so the hash barrier is a 160-bit preimage problem rather than a 256-bit one, which is a second-order concern rather than a near-term one but is the actual bound and should be stated as such. Contract accounts, which hold a large share of value on an EVM chain, have no key at all and are therefore controlled by whatever externally-owned accounts or multisig signers can call them, which pushes their exposure back onto the exposed-after-spend bucket scored in 2a. And no public source publishes how much Polygon PoS supply sits at never-revealed addresses, so the size of the mitigated bucket is unknown; the mitigation is established structurally, not measured. No freeze, burn, rescue or rate-limit policy is declared for dormant exposed keys, which is scored in the burn-versus-rescue declaration and removes any credit for a planned response.

Long-range component, 3 of 13. A signed Polygon PoS transaction remains valid indefinitely, no key expires, and no scheme sunset is published, so a public key revealed in 2026 is a forgery target for as long as the address holds value. The standing exposures are worse than the spend-window ones: Heimdall Signer Keys are epoch-persistent and published in recoverable form on Ethereum with every checkpoint, and the validator-admission proposal in peer review would commit the 64-byte consensus key on-chain explicitly at admission. The one real mitigation is that the Ethereum StakeManager contract supports validator signer rotation, so a validator can retire a key, which bounds the period during which a recovered key authorizes new checkpoints, though it does nothing for signatures already made. Short-range component, 7 of 12, made of a window factor of 5 and an exposure-discipline factor of 2. The window factor is high because this chain confirms fast: the chain's own overview puts deterministic finality at two to five seconds through the Heimdall milestone mechanism, which finalizes Bor blocks within seconds rather than minutes, and successive 2026 upgrades have targeted finality latency and milestone liveness directly, so the gap between a spend revealing a public key in the mempool and that spend confirming is small, and a fast-clock CRQC has little room to work in. The exposure-discipline factor takes the maximum applicable rather than a sum: single-use addresses are not enforced and are not the norm on an account-model chain, no post-quantum-safe spend path exists, and the one thing that qualifies is the Private Mempool, an opt-in endpoint live since April 2026 that routes a transaction directly to the elected block producers and bypasses the public mempool entirely, which removes the pre-confirmation public reveal for transactions that use it. It earns partial rather than full credit because it is opt-in rather than default, and because it hides the transaction only until confirmation, after which the public key is on a public ledger like any other.

Both peer transports rest on Shor-breakable key agreement and neither has a hybrid fallback. On the execution layer, Bor inherits devp2p RLPx from Go-Ethereum, whose handshake performs ECDH and ECIES over secp256k1, authenticated by a static secp256k1 node identity key, before AES-128-CTR framing. On the consensus layer, heimdall-v2 inherits the CometBFT secret connection, which performs X25519 Diffie-Hellman, derives keys with HKDF-SHA256 under a fixed info string, encrypts frames with ChaCha20-Poly1305 and hashes the transcript with a Keccak-based construction for non-malleability. An adversary harvesting either transport today decrypts it once a CRQC breaks the curve. Public JSON-RPC access is a third surface and a growing one: Polygon retired its own public RPC endpoint in July 2026, so user traffic terminates TLS at third-party providers, and no provider serving this chain publishes a hybrid key-exchange posture for that termination. No hybrid KEM combining a classical key agreement with ML-KEM per FIPS 203 is deployed, announced or proposed at any layer. The small credit reflects that the durable-secret corpus is thin by construction rather than by protection: the ledger itself encrypts nothing, there are no shielded note ciphertexts and no on-chain encrypted payloads, so most of what a harvester captures is public data in transit. The exception is specific and worth naming: a transaction routed through the Private Mempool is intended to be invisible before confirmation, so a harvested session from that channel, decrypted later, reveals trading intent that the mechanism exists to protect.

Polygon PoS is a fully public, pseudonymous EVM ledger. Every transfer, its sender, its recipient, its amount and its contract calls are visible to any observer running a Bor node or querying a public RPC endpoint, and the chain's own overview documents no default transaction-content privacy and no shielded pool. The account model is worse than a UTXO model for graph analysis, because an address is a persistent identity that accumulates history rather than a one-time output, so heuristics that struggle on a UTXO chain apply directly here. Pseudonymity is real and earns the credit: addresses are not bound to legal identity at the protocol layer. It is the only thing earning credit. Polygon publishes no structural-impossibility statement naming what the architecture can reveal, to whom and under what conditions, which is the evidence the rubric requires before privacy claims count, and the absence of that statement is what keeps this sub-score at the low end rather than the floor.

Origination-share component, 2 of 8. No public source publishes what share of Polygon PoS transactions originate through the top three RPC providers, so low concentration cannot be established. Partial credit is for genuine provider plurality, which Polygon's own developer documentation sets out with several independent commercial and community endpoints, and for the fact that the RPC interface is an open standard any operator can serve. Working against it, Polygon retired its own public RPC endpoint in July 2026, which removes the one endpoint not operated by a commercial provider and pushes origination further toward that unmeasured top three. Mempool-observability component, 3 of 7. Independent entry points are strong: anyone can run a Bor node and broadcast directly, which is the anti-censorship half of this component. The anonymity half is weak in both directions. The public mempool is observable to any peer, and the alternative, the Private Mempool, removes public observability by routing transactions directly to the elected block producers, which under the VeBloP model are described by Polygon as a known set of Polygon-operated producers whose role the validator set can vote away at any time. That concentrates pre-confirmation visibility in a small, named, chain-operated set rather than eliminating it. Metadata-retention component, 0 of 5. No Polygon source publishes a validator or block-producer metadata retention policy covering peer IP addresses, timing or client fingerprints, and this component scores zero where the policy is undeclared.

Correlation across the bridge is not merely possible on this chain, it is the protocol's normal operation. The Heimdall checkpoint mechanism publishes a Merkle root of Bor block data to an Ethereum contract on a regular cadence, so Polygon PoS state is continuously anchored to a public L1 record, and the native PoS bridge records deposits and withdrawals with matching amounts and addresses on both sides, allowing a passive observer to link source to destination directly. Third-party messaging and bridging layers serving this chain add more of the same bookkeeping. No mixing, batching, amount-blinding, timing jitter or address-unlinking mechanism is applied to any bridge flow, and no source claims one. The small credit is for the fact that the bridge bookkeeping is honest and fully public rather than selectively disclosed, which is a property this sub-score should not punish; the score is near the floor because public and correlatable is exactly what it measures.

Polygon PoS stores no encrypted content on chain. There are no shielded note ciphertexts, no ElGamal encryption, no discrete-log ring signatures and no encrypted memo fields, and the chain operates no zero-knowledge proof system in consensus, because it settles by checkpointing a Keccak-256 Merkle root rather than by verifying a validity proof. There is consequently no historical corpus of Shor-breakable ciphertext sitting on chain waiting to be opened once a CRQC arrives, which is a real and material difference from a chain that stores encrypted content on chain, and is what earns the credit. The credit stops at half because the retroactive exposure is displaced to the transport layer rather than removed. Harvested devp2p RLPx sessions and harvested CometBFT secret connections, both of which rest on Shor-breakable key agreement, decrypt later into peer identities, broadcast timing and address-to-IP linkage, and harvested Private Mempool sessions decrypt into pre-confirmation transaction intent that the mechanism exists to hide. None of those channels has a hybrid KEM, so that entire corpus is retroactively openable on the same clock as the signatures. A third-party zero-knowledge shielded pool operating on this chain adds a further consideration, treated under 3e.

Polygon PoS provides no structural hiding of its own: no mixnet, no cryptographic shuffle, no commit-reveal ordering and no batch-ordering mechanism appears in the protocol, and the Private Mempool is a private routing channel to a known producer set rather than a shuffle, so it earns its credit under 2c and 3b and is not paid for again here. What does apply is third-party: RAILGUN, an on-chain zero-knowledge privacy system whose own documentation states it is built directly on-chain for Ethereum, BSC, Polygon and Arbitrum, operates as smart contracts on Polygon PoS and provides shielded balances through a Merkle-tree accumulator with UTXO-style private spending and relayed transaction broadcast. That is genuine cryptographic hiding available to users of this chain, which places it above the bare no-mechanism floor. It earns only a quarter of the maximum for three reasons. It is an opt-in third-party contract deployment, not a property of the chain, so it covers only the value users deliberately shield. Its anonymity set is computational and depends on shielded volume rather than being information-theoretic. And the proof system and curve are not named in the protocol's own public documentation, so the one question that matters here, whether the hiding survives a CRQC, cannot be answered from the public record; a zero-knowledge system built on elliptic-curve commitments would not survive it.

Polygon PoS satisfies both halves of the evidence requirement for account-layer agility: a cited specification and a verifiable production instance. EIP-7702 has been live at the protocol level since the Bhilai hardfork of 1 July 2025, which upgraded Bor to the Go-Ethereum 1.15 line and added support for it, and ERC-4337 is documented for the chain with its UserOperation, Bundler, EntryPoint and ContractAccount components, though that page states no mainnet status. The live production instance is EIP-7702: an externally-owned account can delegate to contract code today, and contract code sets its own verification rule, so a post-quantum verifier for ML-DSA per FIPS 204 or SLH-DSA per FIPS 205 could be deployed as contract code without a consensus fork, subject only to gas cost. A second, narrower agility property is evidenced by the validator-admission proposal in peer review, which routes admission policy through a Registry-resolved swappable module on the Ethereum StakeManager so that policy can change by re-pointing a single registry key without a StakeManager upgrade, showing the L1 contract path is built to be modular. The deductions are the reason this is not a high score. There is no protocol-level versioned signature type for externally-owned accounts and no post-quantum precompile or opcode, so the base account scheme cannot be switched at all, only escaped by moving users to smart accounts. The consensus and checkpoint path is fixed to address recovery from a secp256k1 ECDSA signature in an Ethereum contract, which is the least agile surface on the chain and the one that anchors everything else. And the swappable module that does exist governs who may become a validator, not which algorithm verifies their signatures.

The account-model component scores 15 for deployed account abstraction: EIP-7702 is live at the protocol level, having shipped with the Bhilai hardfork on 1 July 2025, and ERC-4337 is documented for this chain, so per-user opt-in migration to a contract-defined verification rule is available today. Native key rotation is also present, though on the validator side rather than the user side: the Ethereum StakeManager contract exposes a signer-update function allowing a validator to change the address that validates blocks and checkpoint signatures, and the validator-admission proposal in peer review confirms that post-entry signer rotation remains a live validator operation under its design. It does not reach 17, because that band requires a documented client-layer migration path to post-quantum protection at the wallet or signing-device layer, and no such path exists for Polygon PoS: no Winternitz-style vault construction, no quantum-safe bridge design and no wallet-layer post-quantum scheme is published for this chain. The Ed25519 seed-rebind floor does not apply, because Polygon PoS accounts are secp256k1 rather than RFC 8032 Ed25519 and therefore commit to no Ed25519 seed. The post-quantum rebind bonus is 0, because it is gated on a cited public artifact specific to this chain's rebind path and none exists. The score is what a chain earns for having built genuine, in-production account flexibility and same-scheme rotation, and nothing beyond it.

The upgrade record between July 2025 and August 2026 is dense, dated and independently checkable, and it is the strongest evidence on this card. Bhilai activated 1 July 2025, raised throughput capacity past a thousand transactions per second and added EIP-7702. Madhugiri activated at mainnet block 80,084,800 on 9 December 2025. Giugliano activated at mainnet block 85,268,500 on 8 April 2026 and cut finality. Zurich shipped in Heimdall v0.9.0 and Bor v2.8.3, activating on Amoy at block 37,750,000 on 17 June 2026 and on mainnet at block 47,880,000 on 25 June 2026, with deterministic state-sync processing and commit-only checkpoint aggregation. Ithaca shipped in Heimdall v0.10.0, activating on Amoy at block 40,776,000 on 20 July 2026 and on mainnet at block 50,185,000 on 29 July 2026, restoring autonomous liveness recovery when a block producer stalls with a milestone pending. Valencia shipped in Bor v2.9.0 in August 2026. Austin shipped in Bor v2.10.0, activating on mainnet at block 91,949,700 on 13 August 2026. Kyoto shipped in Heimdall v0.11.0, activating on Amoy at height 42,252,000 on 6 August 2026 at 08:08:46 UTC and on mainnet at height 51,533,000 on 18 August 2026 at 10:10:31 UTC. Every one of those activated on the Amoy testnet before mainnet, each carried a published activation height and a mandatory-upgrade notice, and no contested fork or chain split appears on the public record. Two points are withheld because part of that cadence is remediation of liveness regressions introduced by the chain's own earlier changes, so the record demonstrates capacity to ship under pressure some of which it created, and because no upgrade in the series has ever changed a cryptographic primitive, which is the specific change this sub-score is a proxy for.

At the account layer a hybrid is architecturally possible today and not merely announceable. An ERC-4337 smart account or an EIP-7702-delegated account on this chain can be written to require both an ECDSA signature over secp256k1 and a post-quantum signature, verified in contract code, which is an AND-composition needing no consensus change, and the mechanism carrying it is already live on mainnet. That is what the sub-score asks for and it earns the credit. Three deductions bring it under half. Nothing hybrid is deployed or specified: no ML-DSA per FIPS 204 or SLH-DSA per FIPS 205 verifier contract exists on Polygon PoS, no gas benchmark for one is published for this chain, and no proposal describes a combiner or a domain-separation construction. Signature-size and verification-cost economics are entirely unaddressed, with no recalibration of transaction weighting so that a post-quantum-secured transaction is not fee-penalized against a classical one. And the consensus and checkpoint layer has no hybrid slot at all: a checkpoint is accepted on Ethereum by recovering one address from one ECDSA signature, so adding a second post-quantum signature there requires a coordinated Heimdall fork and an upgrade to the StakeManager contract on Ethereum, which is a cross-chain change rather than a hybrid deployment.

No stateful hash-based signature scheme is deployed, proposed or referenced anywhere in the Polygon PoS stack: no XMSS or XMSS^MT per RFC 8391, no LMS or HSS per RFC 8554, no leanXMSS and no HORS construction with index tracking. There is therefore no signing state to track, no backup-restoration procedure that could rewind an index, no multi-device signing race to prevent and no validator-client enforcement to specify, and the sub-score's default for a chain carrying no stateful-scheme state applies in full. This score records the absence of a specific operational risk, not the presence of post-quantum engineering. Polygon PoS runs no hash-based signature scheme of any kind, stateful or stateless, and the Stage 5 prerequisite of a ninety-day state-management record without a state-reuse incident has nothing to attach to.

Not scored. This sub-score applies to chains whose consensus depends on Shor-vulnerable signature aggregation or threshold primitives, such as BLS sync-committee aggregation or BLS multi-signatures in BFT consensus, and Polygon PoS has neither. Its own checkpoint documentation describes every node validating the Merkle root hash and attaching its signature to it, with a selected proposer collecting those signatures and committing the checkpoint to Ethereum: collection, not cryptographic aggregation. The August 2026 consensus-layer security release settles it independently by normalizing the recovery byte on checkpoint signatures before Ethereum-side submission, because a recovery byte exists only where each signature is individually recoverable, which an aggregate signature is not. Polygon PoS therefore uses a non-aggregating signature scheme at consensus and falls outside this sub-score's scope, so both the numerator and the denominator exclude it and the weight redistributes across the other Dimension 4 sub-scores. Two consequences follow and should be read together. The Stage 5 prerequisite that in-scope chains score above zero here does not bind, because the chain is not in scope. And the absence of an aggregation surface is genuinely easier to migrate than a BLS one, since there is no aggregate-signature construction that a post-quantum replacement would have to reproduce. The validator keys are still standing-public, which is scored in 2c rather than here.

Zero percent of mainnet signing traffic on Polygon PoS uses a post-quantum primitive. Every transaction is authorized by ECDSA over secp256k1 against a Keccak-256 digest, and every checkpoint is authorized by the same scheme. No ML-DSA per FIPS 204, SLH-DSA per FIPS 205, Falcon-512 or Falcon-1024 per the round-3 submission, XMSS or XMSS^MT per RFC 8391, or LMS or HSS per RFC 8554 signature has ever been verified by this chain, because no verifier for any of them exists in Bor, in heimdall-v2 or in a deployed contract. This sets Migration Stage to 0 and triggers the Mainnet-Traffic Cap.

Zero bytes of post-quantum cryptographic code are merged into either client. Bor, the execution client, tracks the Go-Ethereum line and its August 2026 release removed an unbounded wire field and bounded per-block state-sync gas, both changes to block-processing denial-of-service surface rather than to cryptography. heimdall-v2, the consensus client, is a fork of CometBFT and the Cosmos SDK, and its August 2026 release bounded nested protobuf Any depth, capped the fee-coin list, normalized checkpoint signature recovery bytes, bound milestone range voting to the signed parent hash and fixed L1-event replay key collisions, again with no cryptographic primitive touched. The Erigon implementation, which carried no post-quantum code either, was sunset for this chain on 1 August 2026. Nothing is present on a testnet branch to deduct from, because nothing is present at all.

Zero percent of active validators or stake hold a post-quantum key. This is a real zero rather than a non-applicability, because the key exists and could have been migrated: every Heimdall validator holds a Signer Key that is an Ethereum-compatible secp256k1 keypair, used continuously to sign Heimdall blocks and checkpoints, and the Ethereum StakeManager contract already supports rotating it. The rotation primitive is in place and has never been used to rotate toward anything post-quantum, because no post-quantum key type is accepted by the verification path on either Polygon PoS or the Ethereum contract that checks the checkpoints. This sub-score measures validator key adoption only and is not paid from any user-transaction evidence, which is measured in 5a and is itself zero.

No dated, named, publicly verifiable post-quantum milestone is published for Polygon PoS. The improvement-proposal repository runs to PIP-91 with no proposal addressing post-quantum cryptography, hybrid signatures, signature-scheme migration or stateful-hash state management, and no post-quantum entry appears in the developer changelog, the protocol documentation or the chain's blog. The most recent core proposal in the window, in peer review since 18 August 2026, adds an on-chain validator-admission gate that consumes a single-use expiring pass bound to a validator's address and to keccak256 of its committed 64-byte consensus key, issued under authority delegated by the Protocol Council; it is admission permissioning, it is not deployed, and it is unrelated to signature schemes. Separately, this sub-score is voided to zero where mainnet post-quantum traffic is zero, since milestone discipline without shipped code is publishing rather than engineering. Both routes reach the same number, and it triggers the Milestone-Discipline Cap.

The announced-to-shipped ratio is 0, because nothing is announced and nothing is shipped. No press-release claim, no keynote claim, no whitepaper claim and no social claim of a post-quantum primitive, parameter set or migration for Polygon PoS is published in Polygon Labs or Polygon Foundation communications, in the improvement-proposal repository, in the protocol documentation, in the developer changelog or on the community forum over the trailing twelve months. There is therefore no gap between claim and delivery to penalize: the ratio sits below the 1.5 threshold that would apply a Dimension 5 deduction, below the 2.0 threshold that would apply the PQC-Washing Cap, and below the 5.0 threshold that would apply the narrative-only tag. Full credit here measures the absence of overstatement and nothing else. It is not evidence of post-quantum work, and it sits alongside zeros on every sub-score that measures shipped post-quantum engineering.

Undisclosed, which the rubric scores as zero alongside a multiplier above 38 times. No per-block post-quantum signature-data multiplier can be stated for Polygon PoS because no post-quantum signature is deployed, so there is no bytes-per-block figure to measure against the 64-byte compact ECDSA baseline the chain uses today. Nothing offsets that. No SNARK-based aggregation of post-quantum signatures is designed or benchmarked for this chain, no data-availability offloading scheme for signature data is proposed, and no recalibration of transaction weighting or gas accounting has been made so that a post-quantum-secured transaction would not be fee-penalized against a classical one, which matters because at current EVM gas pricing an on-chain ML-DSA-44 verification would be the dominant cost of any transaction using it and the fee economics would actively discourage the migration. No per-quarter rate of exposed-address migration to post-quantum-safe outputs is published, because there are no such outputs to migrate to.

One named wallet vendor in this chain's supply chain has shipped post-quantum cryptography, and it is the hardware one. Ledger supports POL account creation and management through its wallet software and hardware devices, and a 2026 engineering post from the vendor states that its embedded-OS SDK implements ML-KEM per FIPS 203 at the 512, 768 and 1024 parameter sets and ML-DSA per FIPS 204 at the 44, 65 and 87 parameter sets, in both the pure form and the pre-hash form, with ML-DSA-87 not enabled by default and requiring an optimization build flag because key generation and signing otherwise exceed the device stack budget. The same post is explicit that the implementation provides algorithmic security only and does not include hardware countermeasures against fault injection or side-channel attacks, with masking and shuffling deferred to a future version and no date attached, so this is a shipped capability with a stated caveat rather than a dated roadmap. No other named wallet serving this chain, software or custodial, publishes a post-quantum roadmap for key generation, signing or firmware. The concentration component earns little, because no public source measures what share of Polygon PoS key volume sits behind hardware devices, and because the capability has no counterpart on the chain: Polygon PoS verifies only ECDSA over secp256k1, so an ML-DSA key held on a device cannot sign anything this chain would accept. The vendor is ready before the protocol is.

No bridge or cross-chain messaging vendor serving Polygon PoS publishes a post-quantum roadmap. That covers the chain's own native PoS bridge, whose security rests on the Heimdall checkpoint anchoring described in Dimension 1 and therefore on the same secp256k1 ECDSA signatures, and it covers the general messaging layers that carry Polygon PoS liquidity. What those vendors publish is comparison content and security-model explainers, with no post-quantum statement, no named primitive, no parameter set and no date from any of them. Bridges are the highest-value forgery target in this tile, because a forged bridge approval releases assets on the destination chain without any need to touch the source chain's consensus, and none of the top vendors here has published anything addressing it.

No named custodian or exchange in this chain's supply chain publishes a post-quantum roadmap covering POL or Polygon PoS keys. The exposure in this tile is unusually direct, because the three largest validators are exchange-operated staking services, so they are not merely holding assets here, they are operating consensus. Third-party monthly staking reports published on Polygon's own forum put those three at the top of the stake table as of 1 March 2026, at 384,785,971, 337,193,778 and 255,296,616 POL respectively, so those operators hold the long-lived, recoverable checkpoint-signing keys described in 2a, in addition to customer balances. What the major qualified custodians publish is generic custody-model material carrying no Polygon-specific and no post-quantum-specific commitment. The parameter-set restriction that would cap this tile where a chain mandates SLH-DSA per FIPS 205 without a documented custodian multi-party-computation alternative does not apply, because Polygon PoS mandates no post-quantum scheme at all.

RPC-provider component, 0 of 8. None of the commercial providers serving Polygon PoS publishes a post-quantum roadmap for its endpoints or its TLS termination, and the surface grew in July 2026 when Polygon retired its own public RPC endpoint, moving the remaining non-commercial traffic onto those providers. Hardware-security and key-management component, 5 of 8. Amazon Web Services Key Management Service made post-quantum signatures generally available on 13 June 2025, with key specifications ML_DSA_44, ML_DSA_65 and ML_DSA_87 per FIPS 204, keys and signing operations held in hardware security modules validated to FIPS 140-3 Security Level 3. The scheme is pure ML-DSA, and the vendor's own documentation states explicitly that its externally-computed-mu signing path is not the pre-hash HashML-DSA of FIPS 204 section 5.4. That is a shipped capability from a named key-management vendor that institutional validator operators on this chain use, which is why it earns most of this component. It does not earn all of it, because there is no Polygon-specific statement, no other named hardware-security-module vendor with a published algorithm-support roadmap for this chain, and the capability terminates at the custody boundary, since Polygon PoS cannot verify an ML-DSA signature. Trusted-execution component, no instance to score. Polygon PoS documents no trusted-execution environment in block building, in an oracle path or in a sequencer path; under the VeBloP model block production is handled by a known set of chain-operated producers with no attestation chain named, so there is no remote-attestation transition to assess and this component contributes nothing in either direction.

Stake is concentrated in exchange-operated validators. Third-party monthly reports published on Polygon's own forum give the top five by stake as of 1 March 2026 as three exchange-operated staking services at 384,785,971 POL, 337,193,778 POL and 255,296,616 POL, then two independent staking providers at 226,757,132 POL and 219,088,289 POL, with the January report showing the same top three and a different fourth and fifth, so the ordering below the top three moves month to month while the top three do not. No public source publishes a Nakamoto coefficient for Polygon PoS. Client diversity narrowed during the period: support for the Erigon execution implementation was sunset for this chain on 1 August 2026, and the client's own maintainer separately announced that it was discontinuing official Polygon support, leaving Bor as the one maintained execution client alongside the one consensus client, heimdall-v2. A defect in either therefore has no second implementation to fail over to. The block-production role is separately concentrated: under VeBloP, Polygon states that block production is handled by a known set of chain-operated producers, with the validator set holding an explicit power to vote any producer out at any time. Credit is for a published and independently produced stake series and for the disclosed producer-replacement power, which is a real governance lever honestly described. The deductions are exchange-dominated stake, a single maintained client on each layer, no published concentration metric, a chain-operated producer set, and a core proposal in peer review that would gate new validator entry behind a pass issued under authority delegated by the Protocol Council with Polygon Labs as initial issuer.

Four consensus-affecting upgrades shipped in roughly ten weeks, each with a published activation height and a mandatory-upgrade notice, and two of them under embargo. Zurich activated on mainnet at block 47,880,000 on 25 June 2026 with deterministic state-sync processing and commit-only checkpoint aggregation. Ithaca activated at block 50,185,000 on 29 July 2026, restoring autonomous liveness recovery when a block producer stalls with a milestone pending. Austin and Kyoto were then developed privately, validated on the Amoy testnet, activated on mainnet at Bor block 91,949,700 on 13 August 2026 and at Heimdall height 51,533,000 on 18 August 2026 at 10:10:31 UTC, and only disclosed publicly on 27 August 2026, closing denial-of-service paths in block processing and, on the consensus side, a defect that allowed a validly signed checkpoint to be submitted to Ethereum in a form that fails signature recovery and stalls checkpoint anchoring. Coordinating a fix across two clients, two layers and a testnet-first rollout while keeping it embargoed is the operation this sub-score measures, and the chain performed it. Four points are withheld because the pressure was operational and security-driven rather than cryptographic, and because no upgrade in this series or any earlier one has changed a signature scheme, which is a materially harder coordination problem than a wire-format bound.

Coordination authority is named at the level of bodies and is documented. The Polygon Protocol Council is described as a community-governed body of thirteen members responsible for narrow-in-scope, timelock-limited changes to the system smart contracts implemented on Ethereum, its membership is periodically recertified through a published process in which sitting members reconfirm interest, alignment and availability, and the core proposal in peer review places validator-admission issuance authority under a role administered by governance controlled by that Council. Alongside it, Polygon Labs documents an in-house security team of more than ten full-time security engineers and leaders, periodic first-party and third-party assessments and penetration tests, bug bounties paying up to one million dollars for network-infrastructure vulnerabilities, and an ISO 27001-based program. Credit is for a real, named, mandated structure with a documented security function and a demonstrated ability to use it. The deductions are that no individual is publicly named as the coordination lead for cryptographic matters, no working group exists with a published post-quantum mandate, and the Council's own published mandate is scoped to narrow, timelock-limited system-contract changes rather than to a protocol-wide cryptographic transition, so the body best placed to coordinate one has not been given the remit.

The August 2026 release pair is a genuine precedent for coordinating a protocol change against a live, undisclosed defect. The work was developed privately, validated on Amoy, activated on mainnet across both the execution and consensus layers, and disclosed only afterwards, which is the correct sequence when the disclosure itself would hand an attacker the exploit. One of the defects closed was a checkpoint-anchoring stall reachable by submitting a validly signed checkpoint in an encoding that fails signature recovery, which is a liveness attack on the chain's anchor to Ethereum rather than a correctness break, and it is the closest thing on this record to an adversarial cryptographic situation. Credit stops at 8 for two reasons. No cryptographic primitive has ever been changed on this chain, so the precedent is for shipping a fix under embargo rather than for migrating a scheme while an attacker holds an advantage. And no public source places an attacker as actively exploiting during the window, so the pressure was a known vulnerability rather than an active adversary, which is the harder case this sub-score is written for.

No canary or tripwire mechanism of any kind is published for Polygon PoS. There is no monitored honeypot address holding value at a publicly exposed key, no rate-limited spending rule for legacy or exposed outputs, no cryptographic tripwire embedded in consensus with a published threshold, and no automated response that would pause signing, switch to a hybrid scheme or alert wallets on detection. The chain is well instrumented for operational failure, with mandatory-upgrade notices, per-module operator logging added in a July 2026 release and monitored producer-stall recovery, and none of that instrumentation is aimed at detecting cryptographic compromise. The absence is consistent with the burn-versus-rescue position: with no policy declared for quantum-vulnerable legacy keys, there is nothing for a tripwire to trigger.