The deployed inventory is published precisely at both layers. Consensus: ECDSA over secp256k1 for block proposals and every non-aggregatable message, BLS over BLS12-381 for votes and timeouts, which are the message types the protocol aggregates. Accounts: ECDSA over secp256k1 against a keccak256-derived 20-byte address. The EVM crypto surface is published as an addressed precompile table with the governing EIP for each entry, including the secp256r1 / P-256 verification precompile at 0x0100 per EIP-7951, the alt_bn128 (BN254) pairing precompiles and the EIP-2537 BLS12-381 G1 and G2 precompiles. Four gaps keep this short of full credit. The BLS12-381 ciphersuite and the group assignment of consensus public keys versus signatures (G1 or G2) are not published, and the EIP-2537 precompiles govern EVM-level operations rather than the consensus signing path. The one post-quantum scheme named anywhere, ML-DSA, is given without a parameter set, so ML-DSA-44, ML-DSA-65 and ML-DSA-87 are indistinguishable in the source, and without a choice between ML-DSA and HashML-DSA, which are different algorithms with different domain separators under FIPS 204. The Ed25519 entry in the same draft roster does not state the verification rule that would be enforced, cofactored or cofactorless, or whether small-order public keys would be rejected. The zero-knowledge proof system used by the third-party privacy contract live on the chain is not named in any public source, so its proof system and curve cannot be entered in the inventory.

Monad publishes no per-primitive quantum classification of its own cryptography. The classification above is reconstructed from the named primitives and their governing EIPs. The partial credit reflects one chain-authored acknowledgement, the motivation section of the account-authentication proposal published 2026-08-21, which states that a broken scheme exposes every account using it and that security cannot be upgraded in place, and which names ML-DSA as a post-quantum scheme. That is a scheme-break acknowledgement at the account layer, not a per-primitive tag, and no equivalent statement covers the BLS12-381 consensus aggregation path or the pairing-based EVM precompiles.

Zero post-quantum algorithm families are deployed, which scores 0 under the family-count rule. The draft proposal of 2026-08-21 names one post-quantum scheme, ML-DSA, which is lattice. No hash-based family (SLH-DSA per FIPS 205, XMSS or XMSS^MT per RFC 8391, LMS or HSS per RFC 8554) and no code-based family (Classic McEliece, BIKE, HQC, all of which are KEMs rather than signature schemes) appears anywhere in the public record. Were the draft roster deployed as written, a lattice-only posture would be held at the 5-point hard cap for a single lattice family.

No NIST security category can be read off any Monad artifact. The single post-quantum scheme in the public record, ML-DSA, is named without its parameter set, so category 2 (ML-DSA-44), category 3 (ML-DSA-65) and category 5 (ML-DSA-87) are not distinguishable, which is exactly the gap this sub-score measures. Scored 0 rather than not-scored: the chain has named a post-quantum scheme and has not stated its parameters, which is a real gap rather than a structural absence.

Credit for open-source clients and for mature primitives at the security-critical path: secp256k1 ECDSA and BLS12-381 pairings are long-studied classical constructions and keccak256 is high-confidence. The published release history shows cryptographic maintenance rather than neglect: Wycheproof vectors, malleability tests and security unit tests for secp256k1 shipped in v0.12.6, the ECRECOVER precompile was moved onto a vendored build against system libsecp256k1 in v0.16.2, and hashing of addresses and storage keys is seeded per process so colliding keys cannot be precomputed against node-local maps. Against that: no post-quantum implementation exists, so there is nothing to assess for formal verification, constant-time posture or library provenance. No independent audit of the monad-bft signature paths is published, no dudect-style constant-time evidence is published, no reproducible build links the deployed binary to audited source, and no deployed-verifier provenance can be assessed because no post-quantum verifier is deployed. No stateful scheme is used, so no state-management specification is required here. Poseidon is not used at any consensus-critical path, so no Poseidon discount applies.

Monad uses the Ethereum account model, so the ECDSA secp256k1 public key of any account that has ever sent a transaction is recoverable from that transaction's signature and stays recoverable forever. Under the address-type classification these accounts are exposed-after-spend and still funded. The chain's own proposal of 2026-08-21 states that an account is permanently bound to one key and one scheme and that security cannot be upgraded in place, so there is no mechanism today that moves value back out of the exposed bucket. The residual credit is for the absence of any exposed-from-creation scheme comparable to a raw pubkey output: an unspent Monad address reveals only a keccak256 hash. No public source quantifies the share of Monad supply held at addresses whose public key has been revealed, so the exposure is characterised structurally rather than by a figure.

An account that has never sent a transaction has revealed no public key, only the keccak256-derived 20-byte address, so it is mitigated-until-spend and a quantum adversary must break the hash rather than the curve. Mainnet dates from 2025-11-24, so the dormant and lost-key overhang is small in absolute time. The score is held well below maximum because the mitigation ends at the first spend and, once ended, cannot be reversed while accounts are bound to a single key, and because no public source quantifies dormant Monad balances or address-reuse rates.

Split by attacker time-budget. Long-range, at rest (2 of 13): once revealed, an ECDSA secp256k1 public key stays valid indefinitely, there is no rotation primitive, no expiry and no published sunset for the scheme, and historic signed transactions retain validity, so any CRQC on either clock suffices against a dormant exposed account. Short-range, on spend (5 of 12): the window factor is strong, because MIP-12 cut the consensus vote pace from 400ms to 300ms at mainnet round 89,758,000 on 2026-07-23 and MonadBFT gives fast finality, which materially compresses the mempool-to-confirmation race; the exposure-discipline factor is 0, because the account model reuses one address by design, there is no global mempool but also no documented mempool privacy mechanism, and no post-quantum-safe spend path exists on mainnet. Scope guard: this sub-score covers user-spend signatures only. The standing exposure of the BLS12-381 validator keys, which are public for a whole 50,000-block epoch of roughly 4 hours 12 minutes, is scored in Dim 4 sub-score 4f and is not credited here at any block time.

Two channels, scored separately. Consensus transport: RaptorCast propagates blocks over UDP, one chunk per packet, with contiguous chunk ranges aggregated into variable-depth Merkle trees and a single originator signature over each Merkle root, plus a Raptor erasure code (an RFC 5053 variant with chain-specific modifications) for loss tolerance. It provides integrity and origin authentication and no payload encryption, so an adversary harvesting that traffic captures plaintext that is public ledger data anyway and there is no harvestable consensus ciphertext whose later decryption would reveal anything new. User-to-RPC transport: the chain's documented default endpoints for mainnet and testnet terminate TLS 1.3 and negotiate the hybrid group X25519MLKEM768 (X25519 concatenated with ML-KEM-768 per FIPS 203), observed live on 2026-09-21, which is a deployed post-quantum key agreement on the channel where a user's unbroadcast transaction travels. Against that: the same probe shows the Alchemy-operated Monad mainnet and testnet endpoints rejecting X25519MLKEM768 with a TLS handshake-failure alert and negotiating classical X25519, certificate authentication on all four endpoints is classical rsa_pss_rsae_sha256, no ML-KEM appears anywhere in the protocol itself, and no RPC provider serving Monad publishes a post-quantum transition statement.

The base ledger is a fully transparent EVM chain: balances, counterparties and transaction history are public by default and the transaction graph is pseudonymous in the Ethereum sense. A third-party privacy layer, Unlink, went live on 2026-06-25 as a smart contract on Monad with no separate chain and no bridge, holding deposited ERC-20 balances as encrypted notes and hiding sender, recipient and amount for transfers inside the pool. That is opt-in and application-level, and it leaves the base graph unchanged. Monad publishes no structural-impossibility statement naming what the architecture can reveal, to whom and under what conditions, which independently holds this sub-score to at most half of maximum.

Composite. Top-three RPC origination share (2 of 8): the chain's documentation lists eighteen managed endpoint providers, among them Alchemy, Ankr, Blockdaemon, Chainstack and QuickNode, and the documented default endpoints rpc.monad.xyz and testnet-rpc.monad.xyz resolve into a single commercial provider's infrastructure, so the default path is concentrated by construction; no source publishes what share of transactions originates through the top three providers, so the concentration figure cannot be read and opacity is scored rather than assumed benign. Mempool and gossip observability with independent entry points (4 of 7): there is no global mempool, transactions are forwarded to local mempools, RaptorCast propagation is documented, and both client repositories are public and self-hostable, so independent entry points exist for anyone running a node. Validator metadata retention policy (0 of 5): no policy covering IP addresses, timing or client fingerprints is declared, which scores zero by rule. The absent structural-impossibility statement also caps this sub-score at half of maximum.

Monad is EVM-compatible and value arrives through ordinary EVM bridging, including swap and bridge inside MetaMask following its native Monad integration. Bridge bookkeeping is transparent on both sides, so a passive observer can link source to destination by amount and timing in the normal EVM way. No bridge-privacy mechanism, no shielded bridge path and no bridge relayer metadata policy is documented. The absent structural-impossibility statement caps this sub-score at half of maximum.

The base layer encrypts nothing, so it holds no ciphertext that a future CRQC could retroactively decrypt; everything is already readable, which is scored as a privacy failure in 3a rather than twice here. The exposure that does exist sits in the live Unlink privacy contract, whose encrypted notes and zero-knowledge proofs are the only content-hiding cryptography Monad carries: no public source names its proof system or its curve. The chain's EVM exposes pairing precompiles over alt_bn128 (BN254) at 0x06 to 0x08 and over BLS12-381 at 0x0b to 0x11, both Shor-breakable, and no source states which, if any, the Unlink verifier calls, so whether those notes rest on Shor-breakable mathematics cannot be established from the public record. Encrypted notes with an uncharacterised construction are an open retroactive-de-anonymization question, which holds the score down. The absent structural-impossibility statement caps this sub-score at half of maximum.

Above the off-chain-coin-mixing tier and below the cryptographic-shuffle tier. Unlink is an on-chain shielded note pool live as a Monad smart contract, which is structurally stronger than wallet-level mixing, but it is not a mix network: no mix nodes, no precomputation and no cover traffic are described, and the credit for a cryptographic shuffle requires naming the mechanism and citing a specification, which no public source does for Unlink. The protocol layer itself provides no commit-reveal ordering or batch-ordering mechanism.

The account-authentication proposal published 2026-08-21 is a real chain-specific artifact and describes exactly the right architecture: separate address derivation from the authentication method so an account holds a mutable authentication configuration and can add, rotate or retire authenticators, including an in-place upgrade to a post-quantum scheme, without changing its address. It earns little here because this sub-score requires a specification and at least one verifiable instance of the mechanism in production, and there is none. The proposal is Draft v1 with the concrete implementation specification deferred, it is a forum document rather than a numbered proposal in the chain's specification repository, and its own text makes agility governance-gated: the protocol ships a fixed roster of verification algorithms, each with a fixed gas cost, and adding a scheme requires a fork or governance vote. What is in production is the opposite: an account permanently bound to one ECDSA secp256k1 key with no in-place upgrade of the signature scheme.

Account abstraction is live and chain-documented. EIP-7702 is supported on mainnet with the Ethereum workflow and two Monad-specific nuances: a delegated externally-owned account cannot have its balance reduced below 10 MON, and delegated contract code cannot call CREATE or CREATE2. ERC-4337 is served by a first-party account-abstraction contract and infrastructure repository, including a Simple7702Account implementation for batching and gas sponsorship. That is the account-model component and nothing more. No native key-rotation primitive is live, and no deployed client-layer post-quantum migration path exists comparable to a hardware-wallet or vault construction carrying transaction volume, so neither the documented-path nor the deployed-path uplift applies. The proposal that would introduce rotation states it is complementary to, not a substitute for, account abstraction, noting that EIP-7702 still cannot retire the underlying ECDSA key, and it remains a draft. The Ed25519 seed-rebind floor does not apply: standard Monad accounts commit to an ECDSA secp256k1 key, not to an RFC 8032 Ed25519 seed, and the analogous floor for BIP-39 and BIP-44 hierarchical-deterministic ECDSA accounts is not applied under this methodology. The post-quantum rebind bonus is 0, since no public artifact describes a chain-specific rebind proof, let alone one with a post-quantum-sound prover and a freeze on raw ECDSA acceptance.

Three coordinated mainnet hard-fork activations during 2026 on a chain less than a year into mainnet, each with a published activation timestamp and a client release gating it: MONAD_NINE at 2026-03-19 14:30 UTC (block-tag behaviour, transaction return receipts, EVM linear memory), MIP-12 at mainnet round 89,758,000 on 2026-07-23 (consensus vote pace cut from 400ms to 300ms, block gas limit cut from 200M to 150M, block reward cut from 25 to 18 MON), and MONAD_TEN at 2026-09-02 14:30 UTC activating MIP-8 page-encoded storage, where a node that has not completed the database migration fails to start. Around twenty client releases are catalogued with per-network dates, through v0.16.3. No contested fork appears in the record. Held short of maximum because the record is short, none of these upgrades changed a cryptographic scheme, and coordination across a young validator set is a lighter test than a chain-wide signature migration.

Shipping a hybrid classical-plus-post-quantum signature is not architecturally possible today. An account authenticates under exactly one scheme, ECDSA over secp256k1, with no second authenticator slot to hold an ML-DSA signature alongside it, and the consensus aggregation path is fixed on BLS12-381. The design that would make a composition expressible is the Draft v1 proposal with its implementation specification deferred. That proposal does describe composition rather than mere selection: an account holds a set of authenticators under a declarative policy where AND is THRESHOLD(n, ...) and OR is THRESHOLD(1, ...) over a roster that includes both ECDSA over secp256k1 and ML-DSA, and an authenticator may store a hash of a public key instead of the key itself for post-quantum protection of a non-post-quantum scheme. What is absent is everything that would make it deployable: no implementation specification, no ML-DSA parameter set, no pure-or-pre-hash choice under FIPS 204, no gas costs, no combiner security reduction, and no code in either client. Adding any verification algorithm requires a fork or governance vote. The small credit is for the published design direction, not for capability.

Full credit by the stateless default. Monad deploys no stateful hash-based signature scheme: no XMSS or XMSS^MT per RFC 8391 (approved for use per NIST SP 800-208; RFC 8391 is itself an Informational IRTF-stream document, not a NIST approval), no LMS or HSS per RFC 8554, and no Winternitz one-time-signature construction. The deployed schemes, ECDSA over secp256k1 and BLS over BLS12-381, are stateless, so no state-tracking protocol, no rewind-safe restore procedure and no multi-device index partitioning is required, and the 90-day state-management operational record that stateful schemes must show before Stage 5 does not apply here.

In scope and undeclared, which scores zero. MonadBFT depends on BLS signature aggregation over BLS12-381 to compress validator votes and timeouts into quorum certificates and timeout certificates, a pairing-based construction that Shor breaks; all other consensus messages, including proposals, are authenticated with ECDSA over secp256k1, which Shor also breaks. No path to post-quantum aggregation is declared: no hash-based signatures with SNARK or STARK aggregation, no authenticated-channel or MPC consensus replacing signatures with symmetric primitives, and no staged checkpoint migration signing every k-th block with a post-quantum scheme. The client changelog through v0.16.3 contains no entry touching the signature scheme, and a search of both public client repositories for ML-DSA, Dilithium, SLH-DSA, SPHINCS, Falcon, ML-KEM, Kyber and post-quantum returns no code, no merged pull request and no open issue. The chain is therefore flagged consensus-layer-exposed: validator public keys are public for a whole 50,000-block epoch of roughly 4 hours 12 minutes, so a CRQC fabricates a quorum certificate without racing any confirmation window, and the 300ms block time is no defence at this layer. Under the Stage 5 prerequisites, a chain in scope of this sub-score scoring zero cannot reach Stage 5.

Zero percent. No post-quantum signature scheme is live on Monad mainnet or testnet. All mainnet transaction signing is ECDSA over secp256k1 and all aggregated consensus signing is BLS over BLS12-381. The only named post-quantum scheme, ML-DSA, exists solely inside a Draft v1 account-authentication proposal of 2026-08-21 whose implementation specification is deferred. Migration Stage derives from this sub-score.

Zero. A code search of both public client repositories, monad-bft (consensus) and monad (execution), for ML-DSA, MLDSA, Dilithium, SLH-DSA, SPHINCS, Falcon, ML-KEM, Kyber, post-quantum and postquantum returns no match, and a search of issues and pull requests in both repositories returns none either. The chain's specification repository holds MIP-1 through MIP-12 and MIP-15, and none of them references a post-quantum scheme. The published release history through v0.16.3 covers storage, snapshot-protocol, gas and RPC changes with no cryptographic-scheme content. There is no testnet-only post-quantum code to discount either.

Zero percent of the active validator set, which is the dynamic top 200 by total stake recalculated each epoch, holds or uses a post-quantum key. Validators sign votes and timeouts with BLS over BLS12-381 and proposals with ECDSA over secp256k1. Scored as a real zero rather than not-scored: key-holding block producers exist and their keys could have been migrated. No credit is taken here for user-transaction signing, which is measured in 5a.

Zero on two independent grounds. This sub-score is voided whenever 5a is zero, because milestone discipline without shipped mainnet post-quantum traffic is publishing rather than engineering. Independently, no dated post-quantum milestone exists to score: the proposal of 2026-08-21 publishes no target date, no activation fork and no phased sunset for ECDSA over secp256k1, and no protocol-enforced deadline binds any of it. With no prior published post-quantum date, there is also no hit, slip or miss record to assess.

Full credit, because there is no gap between what is claimed and what is shipped. Press-release-class post-quantum claims in the trailing twelve months number zero: no foundation blog post, chief-executive social post, keynote, whitepaper, standards submission or exchange announcement asserts a post-quantum primitive on Monad. The single post-quantum artifact is a design proposal on the governance forum that states its own status as Draft v1 with the implementation specification deferred and names ML-DSA as one selectable authenticator among six, which is an engineering document rather than a claim of deployment; reputable coverage of it on 2026-08-25 also describes it as a proposal. Shipped post-quantum bytes are zero, so the announced-to-shipped ratio is 0, below the 1.5 deduction trigger, the 2.0 QRI-cap trigger and the 5.0 narrative-only trigger.

Zero, on the undisclosed branch. No post-quantum deployment exists, so no per-block signature-data multiplier can be read from chain data, and none is projected in any document: the draft proposal assigns a fixed gas cost to each verification algorithm in its roster but publishes no figure and no parameter set, so even a prospective multiplier for ML-DSA-44 (2,420-byte signature under FIPS 204) against the 64-byte compact ECDSA baseline is not stated for Monad. No SNARK batching or aggregation plan for post-quantum signatures is documented, and no recalibration of transaction-weight or gas accounting to avoid fee-penalising post-quantum-secured transactions has been published, although the fee model charges on the gas limit rather than gas used, which would make any such recalibration a deliberate act. Scored as a real zero rather than not-scored: the chain could deploy and disclose, and has not.

Named vendors, from the chain's own wallet documentation and vendor announcements: MetaMask, which added native Monad network support with in-wallet swap and bridge on 2025-11-24, and the three hardware wallets listed as supported on mainnet, Ledger, SafePal and Tangem. Of those four vendors, Ledger alone publishes post-quantum work: on 2026-06-07 it documented ML-KEM-512, ML-KEM-768 and ML-KEM-1024 per FIPS 203 and ML-DSA-44, ML-DSA-65 and ML-DSA-87 per FIPS 204 in its device SDK across the Nano X, Nano S Plus, Flex, Stax and Nano Gen5, with shuffling and arithmetic masking side-channel countermeasures deferred to a later SDK version. That is vendor-side algorithm availability, not a dated migration of Monad signing, and no firmware activation date is published. MetaMask publishes no post-quantum roadmap. No concentration points are earned because no source publishes signing-share figures by wallet for Monad. The binding constraint sits upstream of the vendors: the chain accepts only ECDSA secp256k1 transaction signatures, so no wallet can sign a Monad transaction with a post-quantum key however its own firmware is equipped.

Bridging into Monad runs through ordinary EVM routes. The chain's cross-chain documentation names thirty providers, among them LayerZero, Wormhole / Portal, Across, Stargate, Circle CCTP, Chainlink CCIP, Axelar and Hyperlane, and MetaMask's native Monad integration carries a bridge function. No bridge or messaging vendor serving Monad publishes a post-quantum roadmap with dates, and none has stated a plan to move its message authentication or relayer signing off ECDSA over secp256k1 or off pairing-based constructions. Zero roadmap points; the single point is for a named, documented and diverse route set rather than one opaque canonical bridge.

The chain's custody documentation names six providers, among them Anchorage Digital, BitGo, Fireblocks, HexTrust and Zerohash. Anchorage Digital announced custody support for MON on 2025-11-13, ahead of the 2025-11-24 mainnet and token launch, covering its custodial platform and its institutional self-custody wallet. On 2026-07-29 Anchorage published a post-quantum preparedness program: post-quantum cryptography deployed inside its security architecture, benchmarking across the NIST-final signature algorithms, HSM-based cryptographic agility, quantum-resistant TLS, a STARK-based construction for transferring signing authority from legacy credentials without exposing key material, and an open-source Rust implementation of SQIsign. That is a published and operational program, and it earns the roadmap points for one named vendor, but it carries no dated migration milestone for MON custody signing and none of the other five named custodians publishes one, so no further roadmap points and no concentration points are earned. The MPC-compatibility question does not bite here, since Monad mandates no post-quantum scheme: the draft roster names ML-DSA, for which threshold-MPC constructions are published at the cost of extra rounds, rather than SLH-DSA.

RPC provider component (2 of 8): the chain's documentation lists eighteen managed endpoint providers including Alchemy, Ankr, Blockdaemon, Chainstack and QuickNode. A TLS handshake probe on 2026-09-21 shows the chain's documented default endpoints, rpc.monad.xyz and testnet-rpc.monad.xyz, negotiating the hybrid group X25519MLKEM768 under TLS 1.3, while the Alchemy-operated Monad mainnet and testnet endpoints reject that group with a handshake-failure alert and negotiate classical X25519; certificate authentication on all four is classical rsa_pss_rsae_sha256. Neither provider publishes a post-quantum transition roadmap, so this is observed behaviour on one edge rather than a commitment, and it protects the transport only, not the signature. HSM algorithm support (0 of 8): no HSM vendor is named for Monad validator key custody in the public record, so no vendor roadmap can be scored. TEE remote attestation (0 of 9): no trusted-execution environment is documented in Monad block building, sequencing or oracle paths, so no vendor roadmap for moving attestation off RSA to a post-quantum scheme applies.

The active set is the top 200 validators by stake weight, recalculated at a boundary block every 50,000 blocks, roughly every 4 hours 12 minutes, with documented entry thresholds of 100,000 MON self-delegation by the validator's auth address and 10,000,000 MON total delegation. The rules are published and the set is large enough to coordinate through, and a proposal to raise the cap to 300 was filed publicly and did not proceed, so the governance path for the parameter is visible. Held low because no Nakamoto coefficient or stake-concentration figure is published for Monad, the delegation thresholds concentrate entry, and client diversity is absent: one implementation appears in the public record, split across a consensus and an execution repository, so a signature-scheme migration would run through a single codebase with no second client to cross-check it.

Cadence is genuinely high for a chain this young: three coordinated mainnet hard-fork activations during 2026, including the consensus vote-pace change to 300ms on 2026-07-23 and a mandatory node upgrade activating page-encoded storage on 2026-09-02 where an unmigrated node fails to start, against roughly twenty catalogued client releases with per-network dates. What is missing is the pressure half of the sub-score: no upgrade in the record was coordinated against a deadline set by an adversary or an active exploit, so the demonstrated capability is scheduled delivery rather than emergency delivery.

Coordination structure is public and split: the Monad Foundation holds validator-led governance, community improvement proposals and ecosystem development, while Category Labs holds software development and research, an arrangement announced 2024-12-16 and corroborated by later independent coverage. Protocol changes run as Monad Improvement Proposals through a public specification repository and a public discussion forum, and that repository shows a working process, with numbered proposals recording their own lifecycle status. For post-quantum work specifically there is no working group, no published mandate and no owner: the account-authentication proposal is not a numbered proposal in the specification repository, and the closest the record comes to an owner is its two documented authors, Kushal Babel and Jan Camenisch.

No precedent exists. Nothing in the public record shows Monad coordinating a cryptographic change while an attacker was actively threatening the network. Mainnet dates from 2025-11-24 and the 2026 upgrades were scheduled protocol work, with release notes covering storage, gas and validation changes rather than a response to an adversary. Scored as a real zero rather than not-scored: the capability is measurable and has not been demonstrated.

No canary or tripwire of any tier. There is no monitored honeypot address holding an exposed ECDSA secp256k1 public key, no rate-limited spending rule for exposed keys, no cryptographic tripwire embedded in consensus with a published threshold, and no automated response such as pausing signing or switching to a hybrid scheme on detection. No deadline or go-live date is attached to the draft account-authentication work either, so the design gives no early warning.