Robinhood Chain publishes no consolidated primitive inventory. The overview page describes a permissionless EVM Layer-2 on Arbitrum Dedicated Blockchains with ETH as gas, a first-come-first-served sequencing model and first-class ERC-4337 support, and names no signature scheme, curve, hash function or commitment scheme. Across the whole documentation set the only cryptographic naming is incidental: the account-abstraction page's sample code constructs its validator with signerToEcdsaValidator from an ECDSA validator package, which names a signature scheme but no curve and appears as an import rather than as a specification, and the connection page names Ethereum blobs for data availability, which identifies the mechanism but not the KZG polynomial commitment behind it. Those two partial namings are the whole of the credit. Every other primitive above has to be read out of the upstream stack, the settlement layer, the compliance-filtering specification or the wire. Nine surfaces, none of them specified by the chain as a primitive.

No per-primitive quantum classification is published for Robinhood Chain by the chain or by any third party writing about it. The sole classification covering a primitive Robinhood Chain actually runs is the Ethereum quantum-resistance documentation, which classifies ECDSA on secp256k1 as broken by Shor's algorithm, states that for any account that has sent a transaction the public key is exposed on chain, and notes that accounts which have only received value have not exposed theirs. That is exactly the account model this chain replicates unmodified, and it is the credit. Nothing classifies the rest. Keccak-256 and the SHA-256 used for the compliance-filtering address hashes are Grover-weakened from 256-bit to roughly 128-bit preimage security. BLS signatures over BLS12-381 at the Ethereum validator layer are Shor-breakable via pairings, as are KZG polynomial commitments, which the same documentation lists among Ethereum's four quantum-vulnerable surfaces. KZG commits to EIP-4844 blob data that the specification requires nodes to keep for only MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS of 4,096 epochs, around 18 days, so that surface carries a Forge-class threat with near-zero long-term shelf life rather than a permanent exposure. The one post-quantum component in the path, ML-KEM-768 under FIPS 203, is likewise unclassified by any chain document, and it is a key encapsulation mechanism protecting key establishment rather than a signature.

Zero post-quantum algorithm families are deployed or selected by the chain. There is no lattice signature family in place (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 with approval status per NIST SP 800-208, LMS or HSS per RFC 8554), and no code-based family. Classic McEliece, BIKE and HQC are key-encapsulation mechanisms in any case, so none of them could serve as a second signature family. The ML-KEM-768 component of the X25519MLKEM768 hybrid observed in transport is a lattice key-encapsulation mechanism, but it is negotiated by the content delivery network fronting several of the chain's hosts rather than selected, specified or deployed by the chain, and it is credited at 2d where the harvest-now-decrypt-later reduction it produces is measured. Counting it as a selected family here would credit the same fact twice and would misdescribe an infrastructure default as a cryptographic decision. Zero families scores zero, and the lattice-monoculture condition therefore does not arise.

No NIST security category is mapped to any primitive in Robinhood Chain's path, because the chain has selected no post-quantum primitive for any signing or key-establishment surface it controls. Nothing in its documentation states which category it intends to land on for account signing, for the sequencer and batch-poster keys, or for transport key establishment, and nothing distinguishes a category-1 target such as ML-DSA-44 per FIPS 204 from a category-5 target such as ML-DSA-87. A target-category mapping is publishable today against a chosen parameter set and none is published, so this is a real zero rather than an absence of anything to measure. The one identifiable post-quantum parameter set in the path, ML-KEM-768 under FIPS 203, is the content delivery network's choice rather than the chain's, and is credited at 2d.

Robinhood Chain runs the Arbitrum Nitro stack without cryptographic modification, which the ArbSys and ArbOwnerPublic precompiles confirm on chain, and at ArbOS 61 Elara, which the ArbSys version getter confirms. Its deployed cryptography is therefore the go-ethereum lineage implementation of ECDSA secp256k1 and Keccak-256, both at high cryptanalytic maturity in a widely reviewed client. That is what the score credits, together with the fact that the chain and its deployed contracts are under dated third-party scrutiny through a published technical security review and an independent public risk assessment. There is no post-quantum implementation to assess, so every post-quantum criterion returns nothing: the client's dependency set contains no post-quantum library, there is no provenance from the Open Quantum Safe liboqs project or the Post-Quantum Cryptography Alliance, no constant-time posture to audit for a lattice or hash-based scheme, no stateful-versus-stateless state-management specification, and no deployed verifier contract whose compiled artifact could be shown to match audited source through a reproducible build or an independent audit. The ML-KEM-768 implementation in the observed hybrid key agreement belongs to the content delivery networks in front of those hosts and no public source names the library or its audit status.

Robinhood Chain uses the Ethereum account model unmodified. Every externally-owned account that has broadcast a transaction has its ECDSA secp256k1 public key recoverable from the signature recovery data, which puts it in the exposed-after-spend state while the address is still funded and makes it forgeable by any CRQC without the attacker needing to race a confirmation window. The chain has produced ordinary account activity continuously since its first block, timestamped 2026-04-30, so the exposed set is the active set. No public source publishes the value held at exposed addresses on this chain. No mitigation is deployed at this surface: no key rotation is enforced, no post-quantum spend destination exists, and no single-use-address rule is applied. The exposure is sharper than on a general-purpose network because the balances the chain is designed to carry are tokenized equities, funds and private assets, so a forged spend moves a claim on a real instrument.

An account on this chain that has only received value has revealed its address, which is a Keccak-256-derived hash of the ECDSA secp256k1 public key, and has not revealed the public key itself. That is the mitigated-until-spend state, and it is a genuine structural mitigation inherited from the account model rather than a control the chain chose. Two things hold the score down. Public mainnet opened 2026-07-01 and the first block is timestamped 2026-04-30, so there is no deep dormant cohort whose keys have stayed hidden for years and whose value would sit behind the hash indefinitely; on a network this young almost every funded account with a purpose has already spent. And no public source publishes the never-revealed share of balances on this chain, so the size of the mitigated set cannot be read off the public record, only its existence.

Long-range, at-rest forgery, 2 of 13 available: an ECDSA secp256k1 public key revealed by a past spend on this chain remains a valid forgery target for as long as the address holds value. There is no signature expiry, no rotation requirement and no post-quantum destination to move to, and any CRQC suffices because the attacker faces no time budget. Short-range, on-spend forgery, 8 of 12 available: the window factor scores 5 of 6, because block timestamps sampled at 100,000, one million and ten million blocks below the head give mean intervals of 0.1006, 0.1007 and 0.1012 seconds, so the gap between a signed transaction reaching the sequencer and its first confirmation is on the order of a tenth of a second and a forger would need a fast-clock CRQC to break the curve inside it; the point withheld is because that confirmation is a single operator's soft commitment rather than a decentralized one, and because the chain publishes only a qualitative sub-second latency for soft confirmation and no block-time figure, so the interval is an observed average rather than a protocol commitment. The exposure-discipline factor scores 3 of 6, taking the maximum applicable rather than summing: ordering runs through a single sequencer on a strict arrival-time rule and the documented public endpoint exposes neither txpool_status nor txpool_content, so there is no open pending-transaction surface for a third party to watch, which is real privacy against everyone except the sequencer operator; against that, ERC-4337 UserOperations travel through the separate UserOperation mempool the standard specifies, where sender, target and call data are visible to bundlers before execution, single-use addresses are not enforced, and there is no post-quantum spend path of any kind.

Transport is all the confidentiality there is: nothing on this chain is encrypted at the protocol level, and no mempool-level or end-to-end transaction confidentiality exists on the public path. Part of that transport is already post-quantum. A TLS 1.3 handshake negotiates X25519MLKEM768 at rpc.mainnet.chain.robinhood.com, feed.mainnet.chain.robinhood.com, rpc.testnet.chain.robinhood.com, explorer.testnet.chain.robinhood.com, robinhoodchain.blockscout.com and docs.robinhood.com, pairing X25519 with ML-KEM-768 per FIPS 203 under the RFC 10024 group definition and the RFC 9954 combiner, so session traffic harvested on those connections is not recoverable by a CRQC attacking the key exchange. That is a real reduction in the harvest-now-decrypt-later surface and it is what the score credits. Four things hold it to single figures. The hybrid comes from the content delivery networks fronting those hosts, two of them behind a Cloudflare-issued certificate, three behind Let's Encrypt certificates but answering with Cloudflare's server and ray headers, and the documentation host behind Amazon CloudFront with an Amazon-issued certificate, so it is three infrastructure defaults rather than anything the chain specifies, and nothing binds it. The endpoint the chain documents as its recommended production RPC and ERC-4337 bundler, robinhood-mainnet.g.alchemy.com, returns a handshake failure when that group is offered alone and negotiates no hybrid at all, while the host that does negotiate it is documented as rate-limited and not recommended for production, so the coverage is inverted relative to where the traffic is meant to go. The sequencer submission endpoint, sequencer.mainnet.chain.robinhood.com, is served from origin and negotiates no hybrid either, which leaves the path every transaction takes to the single sequencer on classical-only key establishment. And the protection that exists ends at the edge, with no public source documenting the key establishment from there to the origin node, nor any hybrid on the six documented bridge and messaging routes or the oracle channels.

Anonymity. The transaction graph is fully public and pseudonymous. Senders, recipients, contract call data and token transfers are recorded in the clear and queryable through a public block explorer, and batch data is posted to Ethereum blobs so that anyone can reconstruct state. No shielded, confidential or private transaction type of any kind is documented, and no stealth-address or confidential-transfer product is named anywhere in the chain's documentation. Quantum arrival changes nothing at this surface, because nothing is hidden to begin with. The chain publishes no structural-impossibility statement naming what a single sequencer operator, an RPC provider or a bridge relayer can see and under what conditions, which caps sub-scores 3a through 3d at half of maximum.

Anonymity, composite. Top-3 RPC concentration, 2 of 8: the chain documents Alchemy as its recommended infrastructure provider and lists Chainstack, QuickNode, Blockdaemon, dRPC and Validation Cloud as alternatives, plus a rate-limited public endpoint, so plural entry points exist. But one provider is named as recommended and also supplies the data API, the gasless-transaction infrastructure and the bundler, and separately operates one of the two dispute bonders, which concentrates observation in a single party across several roles at once. No public source publishes the share of transactions each provider carries, and an undisclosed share scores as an unmanaged one rather than as a structural absence. Mempool and gossip observability, 2 of 7: there is no public pending-transaction mempool, which removes the open gossip surface entirely, but ordering runs through a single Robinhood-operated sequencer on a strict arrival-time rule, so one operator sees every transaction before inclusion regardless of which provider submitted it, and ERC-4337 UserOperations sit in a separate public alternative mempool visible to bundlers. Validator metadata retention policy, 0 of 5: no policy for IP address, timing or client fingerprint retention is published, and an undeclared policy scores zero.

Anonymity. Flows in and out of this chain are linkable by a passive observer on every documented route. The chain publishes six: the canonical Arbitrum deposit and withdrawal path, which settles on Ethereum L1 with matching amounts and correlated timing on both legs; LayerZero OFT and Stargate; Chainlink CCIP and Transporter; Relay; Across; and the LiFi and 0x cross-chain swap aggregators. Each of the five non-canonical routes is public bookkeeping on each connected chain. No correlation-resistance mechanism, batching scheme or delay construction is documented on any of them. The chain publishes no structural-impossibility statement, so this sub-score is capped at half of maximum in any case.

Confidentiality. Nothing on this chain is encrypted on chain. There is no shielded pool, no note ciphertext under ElGamal or ECIES, no discrete-log ring signature and no elliptic-curve zk-SNARK protecting transaction content, so there is no historical private payload for a CRQC to retroactively decrypt. The transaction graph is already readable today, which is why this sub-score is a structural credit rather than a security claim. The absence of a retroactive-de-anonymization surface earns real credit and the score would be higher, but the chain publishes no structural-impossibility statement naming what its architecture can reveal and to whom, which caps sub-scores 3a through 3d at half of maximum. Scored at that cap.

Anonymity. No mixing, shuffling or ordering-privacy layer exists. The chain documents no on-chain commit-reveal or batch-ordering scheme, no cryptographic shuffle with independent mix nodes, and no mix network with precomputation or cover traffic. Its first-come-first-served arrival-time sequencing rule is an ordering-fairness property that prevents fee-based queue jumping; it hides nothing and is not a shuffle. No off-chain wallet coin-mixing product is named for this chain either, so the five-point floor is not reached.

The versioned account mechanism the rubric asks for is live rather than proposed. The chain documents ERC-4337 account-abstraction support and states that it also supports EIP-7702, which lets an existing externally-owned account delegate to smart contract code without moving to a new address, and the ERC-4337 EntryPoint contracts for v0.6.0, v0.7.0 and v0.8.0 all return non-empty bytecode on mainnet at their canonical addresses on chain ID 4663. That delegation is the socket a post-quantum verifier would plug into, and it is in production today. Two things hold the score back. No secondary-signature-algorithm framework that would register a verifier for ML-DSA per FIPS 204, SLH-DSA per FIPS 205 or Falcon per the round-3 submission behind a standard interface is adopted here; the proposal that would do that at the settlement layer is under consideration for a future Ethereum fork, is not final, is not deployed, and carries no commitment from this chain to adopt it. And changing the signature scheme at the protocol level on this stack means an ArbOS upgrade carried out by the chain owner, which is a coordinated fork rather than a fork-free algorithm switch, so the credit here rests on account-level delegation alone.

Account abstraction is present on two paths and is unusually complete for a network this young. The ERC-4337 EntryPoint contracts for v0.6.0 at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789, v0.7.0 at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 and v0.8.0 at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 all carry bytecode on mainnet, the matching SenderCreator contracts and the Safe 4337 Module v0.3.0 and Safe Module Setup v0.3.0 are deployed, and EIP-7702 delegation is documented as supported. That is account-abstraction support, which the rubric scores 15, and it is not more than that. No client-layer migration path is documented: the validator module the chain's own integration guidance constructs is signerToEcdsaValidator, an ECDSA secp256k1 module, and no wallet or signing device offers a user of this chain a post-quantum-protected key today. The Ed25519 seed-rebind floor does not apply, because accounts here commit to ECDSA secp256k1 keys and not to an RFC 8032 Ed25519 seed, and the post-quantum rebind bonus is zero because no public artifact describes a rebind specific to this chain.

The mechanism is published and the fork record is empty. Public mainnet opened 2026-07-01 and the first block is timestamped 2026-04-30. The chain maintains a first-party upgrade-notice channel and explains on it that Robinhood Chain runs Arbitrum Nitro and periodically upgrades its ArbOS version, that those upgrades activate on chain at a scheduled time, and that an un-upgraded node stops cleanly at the upgrade block and resumes once updated. What that channel has carried so far is operational rather than cryptographic: a Nitro v3.11.4 node software release on 2026-09-14, explicitly described as carrying no chain consensus changes, and a move of the websocket sequencer feed to compressed-only transmission under RFC 7692 effective 2026-09-17. The chain runs ArbOS 61 Elara, which the ArbSys version getter returns as 116 under the stack's documented offset of 55, and the ArbOwnerPublic scheduled-upgrade getter returns all zeros, so no ArbOS upgrade is pending. Upstream, the stack publishes a release line through ArbOS 11, 20 Atlas, 32 Bianca, 40 Callisto, 51 Dia and 61 Elara, states that an ArbOS upgrade is that stack's equivalent of a hard fork and is carried out by the chain owner, and has replaced its earlier allowlisted fraud-proof protocol with BoLD on its own public networks. This chain has a defined mechanism to execute such an upgrade, with two chain-owner addresses registered on chain and an eight-member Security Council whose routine actions require six signatures and a seven-day timelock and whose emergency actions require seven and bypass the delay. The mechanism and the notice channel are credited; the record is not, because no ArbOS upgrade of this chain has been announced on it.

The mechanism exists and the intention does not. EIP-7702 delegation plus a deployed ERC-4337 validator-module architecture means an account can bind an additional verifier while the ECDSA secp256k1 path keeps working, which is architecturally a hybrid state at the account layer and is available today rather than announced. What is missing is everything that turns a hybrid into a construction: no post-quantum scheme is selected, no parameter set is named and no choice is stated between a pure and a pre-hash variant, which for a chain that signs digests means the difference between ML-DSA-65 and HashML-DSA-65 under FIPS 204, or between SLH-DSA and HashSLH-DSA under FIPS 205, is undecided; no combiner is specified as either AND-composition requiring both signatures or OR-composition accepting either; no canonicalization or domain-separation design is published; and no security reduction exists, so there is nothing to test against the SUF-CMA-preservation standard the gate applies where a signature is consensus- or transaction-identifier-relevant. Nor is there a stated plan: the stack this chain runs publishes no post-quantum roadmap for its Dedicated Blockchains, and the chain publishes none of its own, so unlike the account-level socket the overlap window has no owner and no date. Architecturally possible, entirely unspecified.

Not scored. This chain deploys and proposes no hash-based signature scheme, stateful or stateless: no XMSS or XMSS-MT per RFC 8391, no LMS or HSS per RFC 8554, no SLH-DSA per FIPS 205, and no post-quantum scheme of any family is selected. There is no signing state to track, to restore without rewinding, or to partition across devices, so there is no state-management surface to score. This sub-score leaves both the numerator and the denominator and is not a zero.

Not scored. This chain has no BFT consensus of its own and no signature aggregation at any layer it controls. A single Robinhood-operated sequencer orders and executes transactions on a strict arrival-time rule, and state is settled to Ethereum through BoLD, in which bonded parties post and challenge assertions resolved by interactive proof. BoLD is an assertion and dispute protocol, not an aggregating or threshold signature scheme, and the bonder keys sign individually with ECDSA secp256k1, so there is no aggregating primitive for which a post-quantum aggregation path could be declared. The BLS-over-BLS12-381 aggregation question belongs to Ethereum L1, which this chain settles to and does not control. This sub-score leaves both the numerator and the denominator and is not a zero; the exposure of the bonder keys themselves is scored at 5c.

Zero percent. No post-quantum primitive signs any transaction on this chain. Every externally-owned-account transaction, every sequencer signature, every batch-poster signature and every bonder assertion is ECDSA secp256k1. Nothing post-quantum runs on the chain ID 46630 testnet either, which answers on the same Nitro stack at the same ArbOS 61 version, and no chain-specific improvement proposal for a post-quantum signature scheme exists. The absence is corroborated from four independent directions: the chain's own documentation names no post-quantum primitive, a dated third-party technical security review of the chain names none, an independent public risk assessment of the chain names none, and an independent on-chain verification that queried the precompiles, the chain-owner registry and the canonical contract deployments found none. The only post-quantum cryptography anywhere in the documented surface is hybrid key agreement in transport, which is a key encapsulation mechanism, protects key establishment, signs nothing, and is scored at 2d.

No post-quantum code is present in this chain's client stack. It runs the Arbitrum Nitro stack, currently Nitro v3.11.4 per its own upgrade notice, whose execution layer is a go-ethereum fork. The client's published dependency set carries the elliptic-curve and commitment libraries the Ethereum model needs and no post-quantum library of any kind, so there are no ML-DSA per FIPS 204, SLH-DSA per FIPS 205 or ML-KEM per FIPS 203 code paths to count, either on the mainnet path or behind a testnet-only flag, and nothing to deduct for testnet-only status. Nor has the chain published a fork of the stack carrying such code. The ML-KEM-768 implementation that appears in the observed hybrid key agreement runs in the content delivery networks in front of several hosts, not in any client this chain ships or runs.

A real zero, not a not-applicable. This chain has no validator set in the staking sense, but it has several key-holding production roles: the single sequencer key that orders and signs blocks, the batch-poster key that publishes data to Ethereum, the two BoLD bonder keys operated by Offchain Labs and Alchemy, the two chain-owner addresses registered in the ArbOwnerPublic precompile, the one authorized transaction-filterer address registered in the same precompile, and the eight-member Security Council multisig, whose seats the chain publishes as held by BitGo, Chainlink Labs, Fireblocks Trust Company, Offchain Labs, Paxos, Talos and Robinhood with two. Every one of these roles signs with ECDSA secp256k1, none has a post-quantum key registered or in use, and no plan to migrate any of them is published. The chain does publish a key-management requirement on its signers, that every Security Council signer maintain secure signing infrastructure, support key rotation and use institutional-grade key management, but that requirement names no algorithm and commits to no post-quantum scheme, so it is crypto-agility language without a target. These keys exist and could have been migrated, so the gap is real rather than architectural. This sub-score measures the producer and authority keys only; post-quantum user-transaction signing is measured at 5a and is not credited again here.

Zero. The rubric voids 5d whenever 5a is zero, on the principle that milestones without shipped mainnet code are publishing rather than engineering, and 5a here is zero. Independently of the void, there is nothing to void: no dated post-quantum milestone of any kind is published for this chain, no sunset date for ECDSA secp256k1 exists at either the chain or the stack level, and no protocol-enforced trigger is defined. That is a harder absence than a roadmap whose dates might slip, because there is no horizon at all against which slippage could be measured. There is likewise no earlier post-quantum milestone from this chain whose hit, slip or miss record could be scored.

No gap, because there is no claim. This chain has published no post-quantum press release, no primitive claim and no post-quantum technical document in the trailing twelve months, and its launch materials describe tokenized assets, throughput and ecosystem partners without mentioning quantum risk at all. An announced count of zero against a shipped count of zero gives a ratio of 0.0, below the 1.5 deduction threshold, so no Dimension 5 deduction applies, no QRI cap follows and no narrative-only tag is warranted. Silence is the honest outcome under this sub-score and it is scored as such: this sub-score measures the distance between claim and delivery only, and the absence of delivery is scored at 5a, 5b and 5c and is not counted twice.

Undisclosed, which the rubric scores zero. No per-block signature-data multiplier under any post-quantum deployment is published for this chain, because it has selected no scheme, so there is no figure to set against the 65-byte ECDSA secp256k1 baseline an Ethereum-model transaction carries, 32 bytes of r plus 32 of s plus a one-byte recovery parameter, whether the 2,420-byte ML-DSA-44 signature per FIPS 204, the 7,856-byte SLH-DSA-SHA2-128s signature per FIPS 205, or the roughly 666-byte compressed Falcon-512 signature per the round-3 submission. The chain posts batch data to Ethereum blobs, which is the offloading lever a post-quantum footprint plan would use, and at a measured tenth-of-a-second block interval the per-block signature budget is the constraint that plan would have to meet, but no post-quantum batching, aggregation or data-availability plan is documented. No recalibration of transaction-weight or fee accounting to stop post-quantum-secured transactions being fee-penalized against classical ones is documented either.

Zero. Wallet coverage exists: the chain documents a first-party mobile wallet for iOS and Android, names MetaMask for browser access and otherwise directs users to any EVM wallet, and its account-abstraction page names Privy and Dynamic as embedded-wallet providers alongside Alchemy and ZeroDev. Post-quantum coverage does not. None of these publishes a dated post-quantum roadmap for its signing stack or its key storage, so no vendor earns roadmap points, and with no roadmap-covered vendor there is no key volume to credit for concentration among roadmap-covered vendors. The concentration here is notable in its own right, since the operator of the chain is also the publisher of the first-party wallet most of its users will hold keys in, and that single surface has no published plan.

Zero. The chain documents six routes carrying value in and out: the canonical Arbitrum deposit and withdrawal bridge to Ethereum L1, LayerZero OFT and Stargate, Chainlink CCIP and Transporter, Relay, Across, and the LiFi and 0x cross-chain swap aggregators. No public source shows any of them publishing a dated post-quantum roadmap for the signature schemes or key-establishment schemes securing its relayer, attestation, verifier or message-passing paths. This matters more than a wallet gap, because bridge approvals and cross-chain attestations are signed messages and therefore Forge-class exposure the moment a CRQC exists: a forged attestation mints on the destination side without ever touching a user key, and no roadmap covers that surface on any of the five non-canonical routes.

The one tile with real post-quantum evidence, and it stops short of production. BitGo and Fireblocks are the two named institutional custody partners, and both also hold seats on this chain's Security Council. BitGo, with Silence Laboratories, announced on 2026-05-26 a completed post-quantum MPC transaction simulation by a regulated custodian, built on the partner's PQ-MPC protocol using ML-DSA per FIPS 204 and integrated with BitGo's existing institutional custody platform; that is a named algorithm family with executed engineering rather than a statement of intent, and it earns 3 of the 5 points available for a top-3 vendor. Two points are withheld: the announcement describes a simulation and gives no production date, saying only that the parties plan to continue developing and testing with select customers, and it names neither an ML-DSA parameter set among ML-DSA-44, ML-DSA-65 and ML-DSA-87 nor whether the pure or the pre-hash HashML-DSA variant is used, which for a custodian signing blockchain digests is the operative distinction. Fireblocks stated on 2026-04-01 that it is auditing its full internal cryptographic infrastructure, covering certificates, encrypted data at rest, authentication mechanisms, TLS and third-party integrations, against post-quantum readiness requirements, and that it will publish a full post-quantum strategy document later in 2026 covering the scope of its readiness roadmap; that is disclosed work plus a commitment to publish rather than a dated roadmap, and it earns 2. Robinhood itself is the third concentration point on this tile, as the operator running deposit, withdrawal and TLS termination for its own users, and it publishes nothing, earning 0. The concentration component earns 2 of 10: two of the three vendors on this tile have a public post-quantum posture, but neither confirms production coverage of assets held or signed for this chain specifically, and the split of key volume between them is not published. The MPC-compatibility clause does not bite, because this chain mandates no post-quantum signature scheme and therefore raises no SLH-DSA threshold-signing problem requiring a custodian alternative.

Zero across all three components. RPC-provider roadmaps, 0 of 8: the chain names Alchemy as recommended and lists Chainstack, QuickNode, Blockdaemon, dRPC and Validation Cloud, and no public source shows any of them publishing a post-quantum roadmap or a hybrid key-establishment plan for its endpoints on this chain. Hybrid X25519MLKEM768 key agreement is in fact negotiated at several documented hosts as a content-delivery-network default, and is absent from the endpoint documented as the production RPC and bundler; that transport fact is scored at 2d and is not credited again here, because this component measures published vendor commitments and no vendor has published one. Hardware-security-module and key-management roadmaps, 0 of 8: no public source names the module or service holding the sequencer, batch-poster, chain-owner, filterer or Security Council keys, so no vendor algorithm-support roadmap can be pointed to for the highest-value keys on the chain, and the chain's published requirement that Council signers use institutional-grade key management names no vendor and no algorithm. Trusted-execution-environment attestation, 0 of 9: no trusted execution environment is documented anywhere in the sequencing, block-building or oracle path, so there is no attestation chain whose transition from RSA to a post-quantum scheme would apply. That component has no in-scope surface and the tile total is unchanged by it, since the other two are real zeros. Chainlink, named on this chain for both oracles and a cross-chain route, has published general educational material on the NIST standards without committing its own signing infrastructure to a migration or a date, which is not a roadmap under this tile.

There is no validator set and no stake distribution. One Robinhood-operated sequencer orders and executes every transaction on a strict arrival-time rule, running a single client stack with no client diversity, and an independent public risk assessment classifies the chain below the first rollup maturity stage on the ground that its fraud-proof system, while fully deployed, is not permissionless. The dispute role is not open either: the chain's own governance page states that its BoLD deployment is secured by a permissioned set and names two validators, operated by Offchain Labs and Alchemy, one of which is also the recommended RPC provider and the bundler. The ArbOwnerPublic precompile returns two registered chain-owner addresses. And the property that would normally survive all of that is qualified: the same precompile returns one authorized transaction-filterer address, the ArbOS 61 compliance-filtering design lets that party register a transaction hash in the filtering precompile at 0x0000000000000000000000000000000000000074 which the state transition function then forcibly fails, including a transaction force-included through Ethereum L1, and that address has been used: its transaction count stands at 6,097, an independent on-chain review sampled its calls as addFilteredTransaction and found the earliest dated 2026-06-30, and an independent risk assessment records over six thousand transaction hashes currently filtered. No filtering criteria, volume disclosure or appeal path is published. The small credit is for the dispute role sitting with two independent operators rather than one. A cryptographic migration has to move the signing role, and that sits with a single party.

The mechanism is published, the delay is contested and the demonstration is missing. Governance runs through an eight-member Security Council: the chain states that routine actions require six signatures and a seven-day on-chain timelock, and that emergency actions require seven signatures and bypass that delay. That emergency path is what a cryptographic change under time pressure would need, and a seven-of-eight threshold on a single council is fast to assemble. The stack beneath it has a documented upgrade line through ArbOS 61 Elara and has replaced its own fraud-proof protocol on its public networks, so the tooling for a coordinated change exists and is exercised elsewhere. Two things hold the score down. An independent public risk assessment of this chain states that there is no window for users to exit an unwanted upgrade because the contracts are instantly upgradable and the primary governance multisig can upgrade with no delay, which is irreconcilable with the seven-day timelock the chain publishes and which matters directly here, because a signature-scheme change executed with no exit window is one users cannot decline. And this chain has not used any of it: public mainnet is months old, no ArbOS upgrade has been announced on its own notice channel, the scheduled-upgrade getter returns zero, and nothing in the record was coordinated against a live deadline or an active threat.

Upgrade authority is published and post-quantum ownership is not. The chain publishes a governance document of its own naming the Security Council as eight signers, stating that Robinhood holds two seats and that the other six are held by independent institutions, listing them as BitGo, Chainlink Labs, Fireblocks Trust Company, Offchain Labs, Paxos and Talos, giving the thresholds and the seven-day timelock, and requiring every signer to maintain secure signing infrastructure, support key rotation and use institutional-grade key management. Two chain-owner addresses are registered on chain and the same page names the two dispute-bonder operators. That is a real, first-party, named upgrade authority with a stated key-management expectation, and it is most of the credit. What is missing is the mandate: no public source names an individual, team or working group holding a cryptographic or post-quantum migration mandate for this chain, no Council seat is described as carrying one, the key-rotation requirement names no algorithm and no target, and no charter sets out how a change of signature scheme would be proposed, reviewed or ratified. Identifiable authority is credited; post-quantum ownership is not, because none is published.

Zero. No public record shows this chain coordinating a cryptographic change while an attacker was actively threatening it. Public mainnet opened 2026-07-01 and no upgrade of any kind has been executed since, so there is no instance in the record to read. This sub-score measures demonstrated behaviour under adversarial pressure, and a chain this young has had no opportunity to demonstrate it, which is a real absence of evidence rather than evidence of incapacity.

Zero. No canary and no tripwire is documented. There is no monitored honeypot at an exposed ECDSA secp256k1 address, no rate-limited spending rule on legacy-vulnerable outputs, no cryptographic tripwire embedded in the state transition function with a published detection threshold, and no automated response such as pausing sequencer signing, switching to a hybrid scheme or alerting user wallets. The chain does hold an unusual amount of the plumbing such a mechanism would need: an authorized filterer address can make the state transition function reject a named transaction hash and has been exercised several thousand times, the compliance engine already evaluates every transaction against a list before sequencing, and a single sequencer could stand up a monitored canary on one operator decision. None of that is connected to any quantum-detection threshold or published as a tripwire, and every band of this sub-score requires a detection mechanism, so response capability without detection earns nothing here.