The inventory above is complete at the security-critical path and precise at every entry, but almost none of it is stated by Plasma as cryptography. The chain publishes no cryptographic specification: no page names a signature algorithm, a curve, a digest or a key-exchange group anywhere in prose. The account path is entailed by the chain's own claim of exact Ethereum opcode, precompile and execution equivalence and confirmed by the client version its endpoint reports. The consensus path is readable only from the committee key format and the validator-key generation procedure in the chain's published node configuration, not from any document that discusses it. Credit is for an inventory that is complete and checkable; the deduction is for a chain that describes its consensus as aggregating validator signatures without ever naming the scheme those signatures use, and for a BLS ciphersuite string that appears nowhere, which leaves the hash-to-curve construction and the proof-of-possession discipline unspecified.

Plasma publishes no per-primitive quantum classification of its own cryptography, so the classification above is reconstructed in full from the deployed artifacts. It resolves cleanly for every primitive on a security-critical path, which is the substance of the credit: secp256k1 discrete log, BLS12-381 pairing-group discrete log and keccak256 preimage resistance are all well studied, and none carries an unstated confidence problem. No Poseidon-class or research-grade hash sits on a security-critical path here. The deduction is for the chain publishing none of this itself, and for one parameter that is genuinely unresolvable from the public record: the BLS ciphersuite string is not published, so the hash-to-curve construction behind the aggregation cannot be pinned, and the proof system and note-encryption scheme of the confidential-payments module in development are likewise unnamed, which leaves the future privacy surface untaggable.

Zero post-quantum algorithm families are deployed in the chain's own cryptography, which scores 0 under the family-count rule. No lattice family (ML-DSA per FIPS 204, Falcon per the round-3 submission), no hash-based family (SLH-DSA per FIPS 205, XMSS or XMSS^MT per RFC 8391, LMS or HSS per RFC 8554, Winternitz one-time signatures) and no code-based family (Classic McEliece, BIKE and HQC, all of which are key encapsulation mechanisms and none of which is a signature scheme) appears in Plasma's documentation, its published node configuration, its container releases, its third-party technical coverage or any proposal. There is not a monoculture to discount at the signature and protocol layer, there is an empty set: the standardization-maturity clause that lets a second family partially lift the diversity ceiling has no first family to apply to. The one lattice primitive in evidence, ML-KEM-768 per FIPS 203, sits in endpoint transport rather than in chain cryptography and is scored in sub-score 2d rather than counted as a family here.

No NIST post-quantum security category is stated for any component of Plasma's own cryptography, because no post-quantum primitive is deployed in it. The classical primitives in use carry no such category: ECDSA over secp256k1 and BLS over BLS12-381 are pre-quantum constructions outside the category-1-to-5 mapping, and keccak256 is a hash rather than a categorised signature or key encapsulation mechanism. Nothing distinguishes a category-2 target (ML-DSA-44) from a category-3 target (ML-DSA-65) or a category-5 target (ML-DSA-87) because no target is stated, and no category is stated for the consensus layer where the aggregation requirement would drive the choice. The Category 3 parameter set observable in the endpoint key exchange is a property of the transport stack rather than a category the chain has selected, and is scored in sub-score 2d.

Credit rests on three checkable facts. The execution layer is upstream Reth rather than a fork: the chain's published node configuration pins the stock upstream image by sha256 digest at v1.11.3, and the public endpoint reports that same version, so the execution client is a public, widely reviewed Rust codebase whose deployed build is identifiable. The node configuration pins every container image by digest rather than by mutable tag. Validator keys are generated with a pinned, publicly available deposit tool on the standard BLS12-381 derivation path into a password-protected keystore, and the configuration documents verifying that tool's build attestation before running it, which is a real software supply-chain control. Everything the sub-score measures beyond that is absent. The consensus client ships only as a container image with no published source, so its implementation cannot be reviewed, its dependencies cannot be enumerated and its deployed verifier cannot be provenanced. No formal-verification status is published for any component, in the machine-checked-proof sense or any other. No constant-time posture is stated for any signing or verification path, and constant-time behaviour is not independently established here; where a library's own claims exist they are the only basis. No named independent audit of either layer is published. No library provenance statement names a post-quantum implementation, because there is no post-quantum signature code to provenance. The stateful-versus-stateless distinction is moot: no signature scheme in use carries state.

Plasma 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 that is exposed-after-spend and still-funded, the worst of the three states. The chain's purpose sharpens it: Plasma is built for high-frequency stablecoin payment flow and was reported ahead of launch as carrying over two billion dollars of committed stablecoin liquidity across more than a hundred protocol integrations, so the accounts holding value are the accounts that transact, and they expose their keys on the first outbound payment rather than accumulating dormant unexposed value. No mitigation exists at any layer: no rotation primitive, no single-use address discipline, no post-quantum spend path, no declared policy for exposed keys. No public source sizes the exposed-key balance on Plasma, so the figure is unquantified rather than small; the near-zero score reflects the unmitigated architecture, not a measured total.

An account that has never sent a transaction has revealed no public key, only the 20-byte keccak256-derived address, so it is mitigated-until-spend and a quantum adversary must break a hash preimage rather than a curve. That is real structural protection and it is inherited from the account model rather than engineered by the chain, which is why the credit is partial rather than full. Mainnet beta dates from 2025-09-25, so at most a one-year window of dormancy has accumulated and there is no long tail of lost keys comparable to an older chain. No public source quantifies dormant or never-revealed balances on Plasma. The protection is also temporary by construction: the first outbound payment from any of these accounts moves its residual value into the exposed bucket, and on a payments chain that transition is the normal case rather than the exception.

Split by attacker time-budget. Long-range, at rest (2 of 13): once revealed, an ECDSA secp256k1 public key on Plasma stays valid indefinitely, with no rotation primitive, no key expiry and no published sunset for the scheme, so a signature authorising value today is forgeable by any capable adversary at any future point, slow-clock or fast-clock. Short-range, on spend (5 of 12): the window factor is genuinely strong, because block time is about one second and PlasmaBFT's fast path finalises after two consecutive quorum certificates, so the chain's own documentation places finality in seconds. That leaves very little time between a broadcast that reveals the public key in the mempool and irreversible confirmation, and forging inside it would require a fast-clock machine that breaks secp256k1 within seconds. The exposure-discipline factor earns nothing: single-use addresses are not enforced, no mempool privacy is documented, and there is no live post-quantum-safe spend destination. The consensus guard applies. This sub-score covers user-spend signatures only. The standing exposure of the BLS12-381 committee keys is scored in Dimension 4 sub-score 4f, not here, and fast finality is no defence there.

The chain's own public endpoints are already protected against harvest-now-decrypt-later at the key-exchange layer, and that is the substance of the credit. Both the mainnet endpoint and the testnet endpoint negotiate TLS 1.3 with the X25519MLKEM768 group by default, deriving the session secret from an X25519 exchange combined with ML-KEM-768 per FIPS 203, so a recorded session cannot be opened later by breaking the elliptic-curve component alone. The credit stops short of half for four specific reasons. The protection is uneven across the surface the chain points users at: at least one of the seven managed endpoint providers named in its own documentation rejects the hybrid group on its Plasma gateway and negotiates classical X25519 only, so a user following the chain's own provider list may land on a session with no post-quantum protection at all. Validator-to-validator consensus transport carries no documented or observable post-quantum key exchange. The consensus-to-execution Engine API hop runs as plain HTTP authenticated by a shared HMAC-SHA256 token rather than an encrypted channel, and the execution layer's own peer transport is the standard Ethereum construction keyed on secp256k1. And the chain publishes none of this: no document states a transport configuration, a cipher suite or a key-exchange group for its own endpoint or for any provider, so the posture that exists is not a posture the chain has committed to maintain. The offsetting structural fact, scored in the class split rather than here, is that the ledger itself encrypts nothing, so the harvestable corpus is confined to transport rather than extending to on-chain payloads.

The ledger is a fully transparent EVM chain: balances, counterparties, amounts and history are public by default and the transaction graph is pseudonymous in the Ethereum sense, with no shielding, no stealth addressing and no confidential amounts live on mainnet. On a chain whose declared purpose is stablecoin payments, that means payroll, remittance and settlement flows are readable in full by any observer, which is a heavier anonymity exposure than the same architecture carries on a general-purpose chain. The chain states it is developing a protocol-native confidential-payments module using zero-knowledge proofs and stealth addresses with selective disclosure for compliance, opt-in and designed to work alongside the rest of the EVM ecosystem; it is in development rather than deployment and earns no credit here. The structural-impossibility requirement also bites: Plasma publishes no statement naming what its architecture can reveal, to whom and under what conditions, so this sub-score could not exceed half of maximum even if the ledger were shielded.

Composite. Top-three origination share (3 of 8): the chain's own documentation lists seven managed endpoint providers serving mainnet, QuickNode, Tenderly, Alchemy, dRPC, thirdweb RPC Edge, Chainstack and BoltRPC, alongside its own rate-limited public endpoint, and running a non-validator node is permissionless with a published configuration template covering mainnet, testnet and devnet, so a reader who wants an independent entry point can build one. That is genuine plurality, but no public source measures what share of transactions originates through the top three, so the concentration curve cannot be evaluated and only the plurality is credited. Mempool and gossip observability (3 of 7): the mempool is a standard public EVM mempool with no broadcast privacy, which is the fully observable case, and the credit is for the plurality of independent documented entry points rather than for any protection of what passes through them. Validator metadata retention (0 of 5): scored zero because the policy is undeclared. No public source states whether validator or endpoint operators retain IP addresses, timing data or client fingerprints, or for how long, and the published validator configuration runs trusted-peers-only with discovery disabled, which concentrates who sees a validator's traffic without saying what they do with it.

Value arrives through documented cross-chain routes whose bookkeeping is transparent on both sides. The chain's own tooling documentation names twelve cross-chain providers serving mainnet, among them a native-stablecoin burn-and-mint transfer protocol whose Plasma token contract address is published, a general omnichain messaging protocol whose endpoint and verification-library contracts are published, a unified-liquidity bridge built on it, and a separate compliant cross-chain messaging layer. A passive observer can align a burn on the origin chain with the corresponding mint on Plasma by amount and timing, and the reverse for exits, so source-to-destination linkage is available without privileged access. Nothing in the design breaks that correlation: there is no batching, no shielded pool at any bridge boundary and no delay mechanism. No public source ranks which routes carry the largest share of flow into the chain, so the correlation surface is described rather than sized. The credit is for the routes being documented with on-chain addresses a reader can inspect, which is more than an undocumented bridge offers.

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 paid for twice here. There are no discrete-log ring signatures, no ElGamal note payloads and no elliptic-curve SNARK privacy primitives live on mainnet at the protocol layer whose break would retroactively unmask historical transactions. Two prospective exposures are specific and named. The confidential-payments module the chain states it is developing uses zero-knowledge proofs and stealth addresses, and no proof system, curve or note-encryption scheme is named for it, so no commitment to a post-quantum construction, and no commitment against a Shor-breakable one, exists in the public record; a module shipped on elliptic-curve note encryption or a pairing-based proof system would make every shielded transfer from its launch date retroactively readable once the curve breaks, and no published design constraint currently prevents that choice. Separately, the alt_bn128 and BLS12-381 pairing precompiles are deployed and callable today, so any application-layer privacy construction built on a pairing-based proof system on this chain already carries that retroactive property, without any protocol change. The structural-impossibility ceiling of half of maximum also applies here.

No mixing or shuffling mechanism of any tier exists. There is no off-chain wallet coin-mixing service documented for the chain, no on-chain commit-reveal or batch-ordering mechanism, no cryptographic shuffle with independent mix nodes, and no structural mix network with precomputation and cover traffic. The confidential-payments module in development is described as a shielded-transfer capability with selective disclosure rather than as a mix network, and it is not deployed in any case. This is a real zero rather than a not-applicable: the mechanism class exists and is deployable on an EVM chain, and Plasma has none of it.

Zero. The sub-score requires a cited specification for switching signature algorithm without a hard fork, plus at least one verifiable instance of that mechanism working in production. Plasma has neither, at either layer. No public source describes a versioned signature type, an authenticator abstraction that separates address derivation from verification method, a key-path-disable with post-quantum script-path activation in the BIP-360 pattern, or any other agility construction for accounts. The published validator configuration carries exactly one key field per committee member and no scheme identifier, so a validator is bound to BLS over BLS12-381 by the format itself. An account is bound at creation to ECDSA over secp256k1 and there is no published route to rebinding it. Nor is there a chain-specific proposal at any stage: no draft, no improvement-proposal process output, and no research note addressing signature-scheme change is on the public record for this chain.

Credit at the account-model tier for deployed account abstraction, not above it. The chain's own documentation states that Plasma uses Ethereum's account model and state structure and maintains full compatibility with smart accounts under both ERC-4337 and EIP-7702, and its mainnet blocks carry Prague-era header fields, so the protocol-level prerequisite for EIP-7702 delegation is active. Its tooling documentation names eight account-abstraction infrastructure and wallet providers marked as serving Plasma Mainnet, covering smart-account factories, bundlers, paymasters, gas sponsorship, multi-signature accounts and embedded wallets, so the account-abstraction layer is deployed infrastructure rather than roadmap framing. There is no documented client-layer migration path of the kind that would earn the higher tiers: nothing equivalent to a deployed hash-based vault signing at the wallet layer, and no post-quantum protection reachable by a user without a consensus change. The Ed25519 seed floor does not apply. Plasma's standard accounts commit to an ECDSA secp256k1 key under the Ethereum account model, not to an RFC 8032 Ed25519 seed, so the scheme-universal seed-rebind property is absent and no floor is granted. No post-quantum rebind bonus applies either: no cited public artifact specific to this chain describes a rebind proof, no testnet prover exists, and nothing freezes acceptance of raw classical signatures.

Partial credit for demonstrated coordination machinery, withheld for the absence of a completed mainnet consensus fork. What exists: the consensus client is published as a public container release series across five versions, and the chain publishes a step-by-step migration procedure for the breaking upgrade between two of them, which changes the consensus configuration schema and the validator key-handling layout. A named height-activated consensus upgrade, aquila, is specified in the chain's own node configuration with an activation height, an epoch length, a committee-handoff window and an on-chain committee contract; that contract is deployed on both networks as an upgradeable proxy, the upgrade is already active on testnet, and its mainnet activation height sits ahead of the current mainnet head. The execution layer has tracked upstream through Cancun-era and Prague-era changes, visible in the header fields of mainnet blocks. What is missing is the thing the sub-score measures: no completed mainnet consensus fork is on the public record, no activation record or post-mortem is published for any upgrade, and no dated release notes accompany the client series. The consequence for migration is direct: the chain has shown it can version and roll a client and has scheduled a coordinated consensus change, but has not yet carried one through on mainnet, and a signature-scheme migration is a harder coordination problem than a committee-rotation change.

Shipping a hybrid classical-plus-post-quantum signature is not architecturally available today at either layer. At the account layer an account authenticates under exactly one scheme, ECDSA over secp256k1, with no second authenticator slot to hold an ML-DSA or SLH-DSA public key alongside it and no verification policy to require both. At the consensus layer the published committee format carries one BLS12-381 key per member and no scheme identifier or second key field, so a composition against it cannot be expressed in the configuration the chain actually ships. The credit is for two architectural facts independent of the account-abstraction infrastructure scored in 4b: the execution environment can express a contract-level verifier at all, which a fixed-format chain cannot, and the deployed precompile set already includes EIP-2537 BLS12-381 arithmetic, so a contract-level aggregate-signature verifier is within reach of the existing gas model. Neither fact is post-quantum. No post-quantum verifier contract is documented for this chain, no precompile supports lattice or hash-based verification, no gas cost is published for one, and no source states that the required lattice or hash operations are available at a workable cost.

Full credit by the stateless default, which the rubric grants to chains deploying no stateful scheme. Plasma 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 and not a NIST approval), no LMS or HSS per RFC 8554, and no Winternitz one-time construction at any layer. No state-tracking protocol, backup-restoration procedure or multi-device index partitioning is therefore required, and the ninety-day operational record that a stateful scheme at the consensus layer would demand for Stage 5 does not arise. This full score records the absence of a specific hazard and should not be read as migration readiness; every other sub-score in this dimension reflects the actual state of preparation.

In scope and undeclared, which scores zero. PlasmaBFT aggregates validator vote signatures into quorum certificates and aggregates the certificates themselves into an aggregated quorum certificate to establish the highest known block during leader failover, and the chain's own consensus documentation states that this aggregation is what the design uses in place of threshold-signature or timeout-certificate schemes, so signature aggregation is load-bearing for consensus by the chain's own account of it. The scheme is BLS over BLS12-381, which is the hardest case in this sub-score rather than an incidental detail: the aggregation property the design depends on is a consequence of the pairing, and no standardised post-quantum signature aggregates that way, so a migration here is a redesign of the certificate structure and not a primitive swap. No path to post-quantum aggregation is declared by any of the three acceptable routes: 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 under a post-quantum scheme. There is no merged specification, no testnet prototype and no benchmarked mainnet pilot. The consensus standing-exposure flag applies with force here, because the exposure is not merely epoch-public but fully published: all ten mainnet committee public keys are carried in the chain's own node configuration, and the sub-second-scale finality credited in Dimension 2 is no defence at this layer, since a capable adversary forges an attestation or fabricates a quorum certificate without racing any confirmation window. The cap attaching to a zero here, that a chain in 4f scope cannot reach Stage 5, is recorded although Stage is 0 for other reasons.

Zero percent. No post-quantum signature scheme is live on Plasma mainnet, live on a Plasma testnet, or under a formal proposal. All mainnet account signing is ECDSA over secp256k1 and all consensus vote aggregation is BLS over BLS12-381. No ML-DSA or HashML-DSA per FIPS 204, no SLH-DSA or HashSLH-DSA per FIPS 205, no Falcon-512 or Falcon-1024 per the round-3 submission, no XMSS per RFC 8391 and no LMS per RFC 8554 appears in the chain's documentation, its published node configuration, its container releases, the technology press covering it, or the independent explainers surveyed. The hybrid key exchange observable on the chain's endpoints is a key encapsulation mechanism protecting transport, not a signature, and is scored in sub-score 2d rather than counted as post-quantum signing traffic here. This sets Migration Stage at 0 and triggers the Mainnet-Traffic Cap.

Zero, and the reason is worth stating precisely. The execution client is upstream Reth pinned at v1.11.3, a public codebase that carries no post-quantum signature implementation. The consensus client is distributed only as a container image and its source is not published, so the count of merged post-quantum bytes in the most-used consensus client cannot be taken from the code at all; no release note, changelog entry or technical writeup describes a post-quantum primitive being merged, benchmarked or gated behind a flag in it. That opacity is scored as a real zero rather than as not-applicable, because the thing being measured exists and the chain simply does not publish it. There is no testnet-only post-quantum branch to deduct from either: the public record contains no post-quantum signature code at any maturity.

Zero percent of the validator set holds or uses a post-quantum key, and this is directly checkable rather than inferred. The mainnet committee published in the chain's own node configuration is ten BLS12-381 public keys and nothing else, and the documented procedure for generating a validator key produces a BLS12-381 keystore on the standard derivation path. No source describes any validator registering, let alone actively using, a lattice or hash-based key. The set is still in the first of three declared rollout phases, a trusted launch group, with enrolment requiring direct coordination with the chain's operators and no date published for expansion or for permissionless participation, so there is not even an open onboarding process into which a post-quantum key requirement could have been written. This is validator-key adoption only; user-transaction signing is measured in 5a and is not re-credited here.

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, and 5a is zero. Independently, there are no post-quantum milestones to void: no dated post-quantum milestone is published for Plasma at all, protocol-enforced or otherwise. The commitments that do exist in the chain's public record are not cryptographic-migration milestones: the three-phase validator rollout carries no dates for its transitions, the confidential-payments module carries no delivery date, and the one scheduled consensus upgrade is specified by activation height and concerns committee rotation rather than any cryptographic scheme. No post-quantum milestone-delivery track record can be computed for the same reason: there is no prior published date to score as hit, slipped or missed. This triggers the Milestone-Discipline Cap.

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 passage, standards submission or exchange announcement claims a post-quantum primitive for this chain. Shipped post-quantum signature bytes are likewise zero. An announced-to-shipped ratio of zero sits below the 1.5 threshold that would deduct ten points from this dimension, below the 2.0 threshold that would cap the index at 65, and far below the 5.0 threshold that would attach a narrative-only tag. Silence scores well on this specific measure and badly on every other measure in this dimension; the full credit here records the absence of marketing, not the presence of engineering.

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: no source states an expected bytes-per-block figure under ML-DSA-44 at 2,420 bytes per signature per FIPS 204, under SLH-DSA-SHA2-128s at 7,856 bytes per FIPS 205, or under Falcon-512 at roughly 666 bytes compressed per the round-3 submission. The consensus case is the sharper one and is equally unaddressed: quorum certificates today carry a single aggregate BLS12-381 signature regardless of committee size, and no source states what a certificate would cost under any post-quantum scheme, where no aggregation of that kind exists. No SNARK-batching or aggregation design is published that would bring an effective multiplier below one, and no data-availability offloading plan is described for signature data. The economic de-penalization credit also cannot be earned: no source states that transaction-weight or fee accounting has been recalibrated so that a post-quantum-secured transfer would not be fee-penalised against a classical one, and the chain's published mainnet fee table currently lists a single fee token with multi-token fee payment described as forthcoming, so the fee model itself is still moving. The optional user-laggard decay rate is not reportable either, since there is no post-quantum-safe output for accounts to migrate toward.

The tile is fully legible and entirely classical. The chain's own documentation names MetaMask, WalletConnect, Trust Wallet and Rabby as working out of the box through standard EVM network configuration, and names eight further account-abstraction wallet and infrastructure vendors serving Plasma Mainnet, covering smart-account factories, bundlers, paymasters, embedded wallets and multi-signature accounts. Every one of them is a secp256k1 ECDSA signer for the keys that authorise value on this chain, and none attaches a dated post-quantum roadmap to its Plasma support or to its signing stack. One vendor advertises passkey onboarding, which is a secp256r1 WebAuthn credential rather than a post-quantum one, and the chain deploys no secp256r1 verification precompile, so that credential cannot authorise a transaction at the protocol layer in any case. No hardware-wallet vendor with a published post-quantum device roadmap is named anywhere in the tile. The credit is for a reader being able to identify exactly which wallet software holds the keys and therefore where a migration would have to land. Nothing is credited for roadmap, for key-material protection or for concentration among post-quantum-committed vendors, because none of those is documented.

The tile is well documented and carries no post-quantum commitment anywhere in it. The chain's own tooling documentation names twelve cross-chain providers serving mainnet, and the contract addresses for the principal ones are published and inspectable: a native-stablecoin burn-and-mint transfer protocol with its Plasma token contract, a general omnichain messaging protocol with its endpoint, executor and send and receive verification-library contracts, and a unified-liquidity bridge layered on it. That is a real and unusually legible inventory of where value crosses into the chain, which is why the tile is not zero. Nothing post-quantum attaches to any of it: no dated post-quantum roadmap is published in connection with any of the twelve in any source covering this chain, and no source states which curve or signature scheme any of their verification paths uses. The native Bitcoin bridge that the chain's launch-era architecture pages described, signing redemptions under threshold Schnorr over secp256k1 with Bitcoin's Taproot upgrade, is not deployed and no corresponding contract appears in the published mainnet lists, so it contributes no live custody surface and no live credit.

The chain's own documentation names Fireblocks as the custody and operations layer for teams settling stablecoins on Plasma, in a page dated February 2026, and goes further than most vendor tiles by naming the protection mechanism: MPC-CMP, with the private key split into shares held on separate devices or services, alongside role, limit, approval-threshold and destination-allowlist policy controls. A named threshold protocol is a real disclosure and is what lifts this tile above the floor. It is also entirely classical: MPC-CMP is a threshold ECDSA construction, so the custody layer inherits the same Shor exposure as the accounts it protects, distributed across shares rather than reduced. Nothing else the tile measures is documented: no key-generation parameters, no hardware-security-module vendor, no attestation posture and no post-quantum roadmap with dates. The multi-party-computation compatibility question is now concrete rather than hypothetical: a custody layer built on threshold ECDSA would need a new threshold protocol for any post-quantum signature Plasma might mandate, and SLH-DSA in particular is unlikely ever to have an efficient threshold construction. No exchange venue is documented by the chain as a named settlement surface, so the highest-concentration retail component of this tile cannot be scored from the public record.

Endpoint provider component: the chain's documentation lists seven managed providers serving mainnet, QuickNode, Tenderly, Alchemy, dRPC, thirdweb RPC Edge, Chainstack and BoltRPC, several of them also serving testnet, alongside its own rate-limited public endpoint which it explicitly tells production users not to rely on. None of the seven listings mentions post-quantum readiness, hybrid post-quantum transport or key-protection specifics; one listing carries an ISO/IEC 27001:2022 certification claim, which is an information-security management certification and says nothing about algorithm choice. The transport posture that can actually be observed across those providers is uneven, and that finding is scored in sub-score 2d rather than re-credited here. Node-operator component: the chain publishes a configuration template that pins every container image by sha256 digest rather than by mutable tag and documents verifying the build attestation of its validator-key tooling before running it, which is a genuine software supply-chain control and is the bulk of the credit in this tile. Hardware-security-module component: zero. No module vendor is named anywhere in connection with validator committee keys, custody keys or endpoint keys, and the published validator configuration holds the signing key in a password-protected file keystore on the node's own filesystem, with no hardware-backed option documented. Trusted-execution component: zero. No source documents a trusted execution environment in block building, sequencing or oracle operation for this chain, so there is no attestation chain whose transition from RSA-based to post-quantum attestation could be scored.

The validator set is permissioned at mainnet launch by the chain's own design, and unusually, it is also fully identified. Its documentation describes a three-phase rollout, a trusted launch group of known operators, then expansion to test larger-committee throughput, then permissionless participation, and states no date for either transition. The current shape is concrete: the mainnet committee published in the chain's own node configuration is ten members, each a BLS12-381 public key mapped to a peer identifier and a host under a single operator domain, with validator nodes configured trusted-peers-only and discovery disabled, and enrolment as an active validator requiring direct coordination with the chain's operators. Running a non-validator node, by contrast, is permissionless with a published template. A scheduled consensus upgrade would move committee selection from this static list to an on-chain contract with twenty-thousand-block epochs and a ten-thousand-block handoff window, which is a specified rotation mechanism rather than an aspiration. No Nakamoto coefficient or stake-distribution figure is published, no client diversity exists to publish, one consensus implementation and one execution client lineage are described, and misbehaviour is answered by withholding rewards rather than slashing stake. For migration coordination this cuts both ways and the score reflects the balance. A committee of ten known operators whose keys are already public is about as movable through a cryptographic change as a validator set can be, which is worth real credit. It also concentrates the decision entirely, removes any independent check on it, and leaves a reader unable to verify who controls the ten keys that authorise every block.

Partial credit for a demonstrated routine cadence, nothing for cadence under pressure. The consensus client has a public release series spanning five versions, the chain publishes a written migration procedure for the breaking change between two of them, and a height-activated consensus upgrade is already running on testnet with a mainnet activation height set ahead of the current head. That is more coordination machinery than an unversioned chain shows, and it is checkable. What the sub-score actually asks for is absent. No upgrade has been performed under time pressure, no security incident requiring a coordinated response is documented, no emergency client release appears on the record, and no dated release notes or activation post-mortems accompany any version in the series. A signature-scheme migration is the hardest coordination a chain performs, and Plasma has demonstrated only the routine end of the range.

There is an identifiable publishing entity: a foundation operates the chain's documentation, its technical pages and its social account, a named engineering organisation publishes the node configuration templates and the consensus container releases, and technology press quotes the chain's chief executive on the record, so a reader knows which organisation speaks for the protocol and which one ships its software. That is the whole of the credit. What the sub-score asks for is absent. No working group, core team or individual is named as holding the cryptography or migration mandate, no published mandate describes who would decide a signature-scheme change or on what process, and no improvement-proposal process is documented through which such a change would be raised, reviewed or ratified. No public issue tracker, forum or specification repository carries cryptographic discussion for this chain.

No precedent exists. Nothing in the public record shows Plasma coordinating a cryptographic change, or any protocol change, while an attacker was actively threatening the network. The chain is about a year into mainnet beta, no security incident requiring coordinated response is documented, and no emergency upgrade has been performed. The sub-score measures demonstrated behaviour under adversarial timeline, and there is no instance to measure.

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 that would throttle withdrawals from addresses whose public key is already exposed, 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 user wallets on detection. The monitoring stack the chain publishes for node operators covers sync status, resource usage and RPC error rates, and carries no cryptographic signal of any kind. No commitment to monitor for cryptanalytic developments on a fixed schedule is published either, and no cryptographic-upgrade cadence is documented. A chain built for payment throughput, with ten permanently published committee keys authorising every block, has more to detect than most and detects nothing.