1 Signature scheme 0/10, weighted 30%
Band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.
Bor recovers every transaction sender with ECDSA on secp256k1, and Heimdall's consensus parameters on mainnet accept secp256k1 validator keys and nothing else. The P-256 precompile added under PIP-27 verifies another elliptic curve. Nothing post-quantum protects POL or any asset on Polygon PoS.
source
2 Deployment stage 1/10, weighted 25%
Band 1: Tier 5: Exposed.
Tier 5: Exposed. The signatures protecting funds and finalising blocks are quantum-vulnerable, and no Polygon Improvement Proposal, Polygon Labs publication, forum proposal or research programme on post-quantum signatures for Polygon PoS was found.
source
3 NIST alignment 0/10, weighted 15%
Band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.
No post-quantum scheme has been named for Polygon PoS's account, block-producer or validator signatures, so there is nothing to assess against a NIST standard.
source
Placement in the band The floor of the band rather than a 1 or a 2: no scheme has been named at all, even as an example, by anyone with authority over the chain, so there is no choice to align with a standard.
4 Migration path 2/10, weighted 15%
Band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.
No migration plan or published position exists. Polygon does have a working route for changing signature verification: PIP-27, a Final core proposal, added a secp256r1 precompile that shipped in the Napoli hard fork under PIP-33, and PIP-31, shipped in the same fork, brought Ethereum's Cancun EVM changes to Bor, which follows go-ethereum by merging upstream changes. Nothing has been proposed to put a post-quantum scheme through that process, and nothing addresses accounts whose keys are already public.
source
Placement in the band The top of the band rather than a 0 or a 1: the PIP process has already carried a new signature-verification primitive to mainnet through a hard fork, and Bor's practice of adopting Ethereum's EVM changes gives Polygon a path to reuse Ethereum's work. Not a 3, because Polygon has not acknowledged the quantum problem in public, let alone described a route for holders.
5 Exposure 2/10, weighted 10%
Band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.
Polygon PoS keeps Ethereum's account model: an address is a hash of the public key, so an account that has never signed keeps its key private. Every account that has sent a transaction has published its key, and because Polygon accepts the same keys and addresses as Ethereum, a key published on any EVM chain exposes the same address here. Validator signer keys are public in Heimdall's validator set by design.
source
Placement in the band The top of the band rather than a 1: never-signed addresses keep their keys hidden. Not a 3, because almost all economically active POL sits behind a key that has signed, here or on another EVM chain, and no measurement of the unexposed share has been published.
6 Verification 2/10, weighted 5%
Band 0 to 2: No post-quantum component exists, or the claims rest on marketing.
No post-quantum component exists for Polygon PoS: no code, specification or testnet implementation was found in Bor, Heimdall or the PIPs repository. Bor and Heimdall are open source, but under v1.8 the openness of classical code earns nothing on this dimension.
source
Placement in the band The top of the band rather than a 0 or a 1: there is nothing post-quantum to verify, but nothing about Polygon PoS is marketed as quantum-safe, so its position does not rest on marketing.