Ink publishes no consolidated primitive inventory and its own documentation names no cryptographic primitive at all: the chain's About page describes sub-second ambitions, low gas, EVM compatibility, account abstraction support and Superchain interoperability, and says nothing about signatures, curves or hashes. Every primitive has to be read out of the upstream clients and the settlement layer rather than from an Ink specification. Ink runs op-node for derivation and op-geth for execution, op-geth being a go-ethereum fork, which supplies ECDSA secp256k1 for externally-owned-account transaction signing and for the sequencer and batch-submitter keys, and Keccak-256 for address derivation, transaction hashing and the Merkle-Patricia state trie. The settlement path adds two more: KZG polynomial commitments for EIP-4844 blob data availability and BLS signatures over BLS12-381 for the Ethereum L1 attestations that finalize Ink's state. The only naming credited here is stack-level rather than chain-level: the post-quantum roadmap published for the OP Stack identifies the sequencer and batch-submitter keys as ECDSA. Zero of five surfaces are named by the chain itself.

No per-primitive quantum classification is published for Ink. The roadmap published for the OP Stack on 2026-01-14 identifies ECDSA as the scheme its sequencer and batch-submitter keys must move off, which classifies one primitive as Shor-breakable, and Ink's account path uses the same ECDSA secp256k1. Nothing classifies the rest. Keccak-256 is 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. KZG polynomial commitments on EIP-4844 blobs are Shor-breakable via pairings but commit to data pruned after the roughly 18-day blob retention window, so that surface is a Forge-class threat with near-zero long-term shelf life rather than a permanent exposure. Ink publishes none of this and no third party publishes it for Ink specifically.

Zero post-quantum algorithm families are deployed or selected. The roadmap covering Ink's stack states that the specific post-quantum scheme is not yet decided, so there is no lattice family in place (ML-DSA per FIPS 204, ML-KEM per FIPS 203, Falcon per the round-3 submission), no hash-based family (SLH-DSA per FIPS 205, XMSS per RFC 8391 with approval status per NIST SP 800-208, LMS per RFC 8554), and no code-based family. Classic McEliece, BIKE and HQC are key-encapsulation mechanisms in any case and none of them is a signature scheme, so none could serve as the second signature family. Zero families scores zero, and the lattice-monoculture condition does not arise because there is no lattice deployment either.

No NIST security category is mapped to any primitive in Ink's path, because no post-quantum primitive has been selected. Nothing in Ink's documentation or in the roadmap covering its stack distinguishes a category-2 target such as ML-DSA-44 per FIPS 204 from a category-5 target such as ML-DSA-87, or states which category the chain intends to land on for account signing, sequencer keys or transport key establishment. 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.

Ink runs op-geth and op-node without cryptographic modification, so its deployed cryptography is go-ethereum's ECDSA secp256k1 and Keccak-256 implementations, both at high cryptanalytic maturity in a widely reviewed client. That is what the score credits. There is no post-quantum implementation to assess, so every post-quantum criterion returns nothing: no formally verified post-quantum library in the client stack, 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.

Ink 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's recovery data, which puts it in the exposed-from-first-spend state and makes it forgeable by any CRQC without the attacker needing to race a confirmation. Ink has produced blocks with ordinary account activity since December 2024, so the exposed set is the active set. No public source publishes the value held at exposed Ink addresses. No mitigation is deployed at this surface: no key rotation, no post-quantum spend destination, no enforced single-use-address rule.

An Ink account that has only received funds has revealed its address, which is a Keccak-256-derived hash of the public key, and has not revealed the ECDSA secp256k1 public key itself. That is the mitigated-until-spend state, and it is a genuine structural mitigation rather than a chosen control. Two things hold the score down. Ink launched in December 2024, so there is no deep dormant cohort whose keys have stayed hidden for many years and whose value would sit behind the hash indefinitely. And no public source publishes the never-revealed share of Ink balances, 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 Ink spend 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, 7 of 12 available: the window factor scores 5 of 6, because Ink's block interval is one second, set as block_time in its Superchain registry entry, so the gap between a spend appearing in the mempool and its first confirmation is short and a forger would need a fast-clock CRQC to break the curve inside it. No preconfirmation or flashblock layer shortening that interval below one second is documented for Ink. The exposure-discipline factor scores 2 of 6, taking the maximum applicable rather than summing: single-use addresses are not enforced, there is no post-quantum spend path such as a script-path destination, and mempool privacy exists only as an opt-in third-party private RPC product offered by the vendors Ink documents, not as a default for ordinary users.

Ink's documented public RPC endpoints are standard HTTPS and WSS, and transport is all the protection there is: no mempool-level or end-to-end transaction confidentiality exists on the public path. Part of that transport is already post-quantum. Three of the four public RPC hosts Ink documents, rpc-qnd.inkonchain.com, rpc-ten.inkonchain.com and ink.drpc.org, negotiate X25519MLKEM768, pairing X25519 with ML-KEM-768 per FIPS 203, 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 network fronting those hosts, which has offered the group to every TLS 1.3 site it serves since October 2022, not from anything Ink specifies, so nothing binds it. rpc-gel.inkonchain.com, the host Ink's Superchain registry entry names as both public_rpc and sequencer_rpc, does not negotiate it, and neither does its Sepolia counterpart. The protection ends at the edge and no public source documents the key establishment from there to the origin node. And the bridge and oracle channels Ink depends on have no documented hybrid key establishment at all.

Anonymity. Ink's transaction graph is fully public and pseudonymous. Transaction batches, state roots and withdrawal data are published to Ethereum L1 so that anyone can construct a proof, and Ink's own feature documentation lists low gas, EVM compatibility, account abstraction support and Superchain interoperability, and one-second blocks with sub-second blocks described as forthcoming, with no shielded, confidential or private transaction type of any kind. Quantum arrival changes nothing at this surface because nothing is hidden to begin with. Ink 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: Ink documents seven independent RPC vendors, namely Alchemy, Gelato, QuickNode, Tenderly, dRPC, Uniblock and BoltRPC, so plural entry points exist, but no public source publishes the share of Ink transactions each carries. An undisclosed share scores as an unmanaged one rather than as a structural absence. Mempool and gossip observability, 2 of 7: ordering runs through a single Kraken-operated sequencer, so one operator sees every transaction before inclusion regardless of which RPC vendor submitted it. Validator metadata retention policy, 0 of 5: no policy for IP address, timing or client fingerprint retention is published, and the rubric scores an undeclared policy zero.

Anonymity. Bridge flows in and out of Ink are linkable by a passive observer. Across Protocol advertises routes into Ink from 23 or more chains with roughly two-second fills, and the canonical OP Stack deposit and withdrawal path settles on Ethereum L1. Both sides of both routes are public on-chain bookkeeping with matching amounts and correlated timing. No correlation-resistance mechanism, batching scheme or delay construction is documented on either route. Ink publishes no structural-impossibility statement, so this sub-score is capped at half of maximum in any case.

Confidentiality. Nothing on Ink is encrypted on chain. There is no shielded pool, no note ciphertext under ElGamal or ECIES, 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. The absence of a retroactive-de-anonymization surface earns real credit and the score would be higher, but Ink 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. Ink 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. The third-party private RPC endpoints Ink lists are transaction-routing products that hide a transaction from competing searchers before inclusion; they are not a mixing layer and do not reach the five-point bar for off-chain wallet coin-mixing.

EIP-7702 is live on the OP Stack through the Isthmus upgrade, the stack's Prague-equivalent hardfork, which Ink activated at 2025-05-09 16:00:01 UTC per the isthmus_time value in its Superchain registry entry. That is the versioned account-abstraction mechanism the rubric asks for and it is in production rather than proposed: an externally-owned account can delegate signature verification to contract code, which is the socket a post-quantum verifier would plug into, and the post-quantum roadmap published for the OP Stack names exactly that delegation as the migration on-ramp. Two things hold the score back. EIP-7932, the secondary-signature-algorithm framework that would register a verifier for ML-DSA per FIPS 204, Falcon per the round-3 submission or SLH-DSA per FIPS 205 behind a precompile and a standard interface, is a Draft standards-track proposal and is not adopted on Ink. And the mechanism named for changing the signature scheme is a coordinated hardfork, not a hardfork-free algorithm switch, so the credit here rests on EIP-7702 alone.

Account abstraction is present on two paths. The ERC-4337 EntryPoint contracts are deployed and carry code on Ink mainnet at the canonical v0.6 address 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 and the canonical v0.7 address 0x0000000071727De22E5E9d8BAf0edAc6f37da032, on chain ID 57073, and EIP-7702 delegation is live through the Isthmus activation of 2025-05-09. The post-quantum roadmap published for the OP Stack names EIP-7702 smart-account delegation as the on-ramp a future post-quantum migration would use. That is account-abstraction support, which the rubric scores 15, and it is not more than that: no client-layer migration path specific to Ink or to the OP Stack is documented, no wallet or signing device offers an Ink user a post-quantum-protected key today, and the ephemeral-key-plus-account-abstraction design under discussion in Ethereum research is a proposal rather than a deployed path. The Ed25519 seed-rebind floor does not apply, because Ink accounts 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 an Ink-specific rebind.

Ink takes coordinated protocol upgrades through the Superchain's shared pipeline rather than running its own. Its entry in the Superchain registry carries superchain_time 1742396400, dated 2025-03-19, which auto-inherits Superchain-wide activation timestamps, and the same entry records four coordinated hardforks landing on schedule: Holocene at 2025-03-19, Isthmus at 2025-05-09, Jovian at 2025-12-02 and Karst at 2026-07-08. A merged superchain-ops pull request for the U20 upgrade-contracts-manager release, op-contracts v8.0.0-rc.3, shows OP Mainnet, Ink, Soneium and Unichain being upgraded together in a single coordinated on-chain action on 2026-09-14. Isthmus brought Prague-equivalent features, an L2-withdrawals-root change and a new operator-fee component to the whole stack. None of these was contested. The record is real and repeated but short against the rubric's three-year window, since Ink has been live only since December 2024.

The mechanism exists in outline. The roadmap published for the OP Stack on 2026-01-14 states that the stack is already architected to swap in new signature schemes via hardforks and describes the shipping method as specify the upgrade, schedule and coordinate a hardfork, then run overlapping support for ECDSA and post-quantum paths during the migration window. An overlap window is architecturally a hybrid state, and EIP-7702 delegation independently lets an account add a post-quantum verifier while the ECDSA secp256k1 path keeps working. What is missing is everything that turns a hybrid into a construction rather than an intention: no post-quantum scheme is selected, no combiner is specified as either AND-composition or OR-composition, no canonicalization or domain-separation design is published, and no security reduction exists. Architecturally possible, entirely unspecified.

Not scored. Ink 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 the roadmap covering Ink's stack states that the scheme is not yet decided. 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. Ink has no independent validator set and no BFT consensus of its own: a single Kraken-operated sequencer orders and executes transactions and settlement finality is inherited from Ethereum L1. There is no signature aggregation and no threshold primitive at Ink's own consensus layer, so there is no aggregating scheme for which a post-quantum aggregation path could be declared. The BLS-over-BLS12-381 aggregation question belongs to Ethereum L1, which Ink settles to and does not control. This sub-score leaves both the numerator and the denominator and is not a zero.

Zero percent. No post-quantum primitive signs any Ink mainnet transaction, none runs on Ink's Sepolia testnet, and no Ink-specific improvement proposal for a post-quantum signature scheme exists. Every account transaction, every sequencer signature and every batch-submitter signature is ECDSA secp256k1. The only post-quantum activity touching Ink is the Superchain-wide roadmap, which is a deprecation plan with no scheme chosen and therefore contributes no mainnet traffic.

No post-quantum code is merged into Ink's client stack. Ink runs op-node for consensus and derivation logic and op-geth for execution, op-geth being a go-ethereum fork, and neither released component implements a post-quantum signature or key-encapsulation primitive. 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, so there is nothing to deduct for testnet-only status either. Lattice-arithmetic precompiles for Falcon and ML-DSA parameters exist as a reference fork of op-geth published as an Ethereum improvement-proposal asset; that fork is not part of the ethereum-optimism releases Ink runs and contributes nothing here.

A real zero, not a not-applicable. Ink has no validator set, but it does have a key-holding block producer: a single sequencer operated by Kraken, together with the batch-submitter key that posts data to Ethereum L1. Both sign with ECDSA secp256k1 today, and the roadmap published for the OP Stack on 2026-01-14 states in the future tense that these keys will need to transition off ECDSA signatures, which is a statement that they have not. The key exists and could have been migrated, so the gap is real rather than architectural. This sub-score measures the producer key 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 Ink's 5a is zero. Independently of the void, the only dated commitment covering Ink's stack is the roadmap published on 2026-01-14, which sets January 2036 as the date ECDSA-signed externally-owned-account transactions are deprecated across the Superchain and makes that commitment subject to governance approval. It names no post-quantum scheme, sets no Ink-specific date, has no protocol-enforced trigger, and is Superchain governance rather than an Ink milestone. There is also no earlier Ink post-quantum milestone whose hit, slip or miss record could be scored.

No gap, because there is no claim. Ink has published no post-quantum press release, no primitive claim and no post-quantum technical document in the trailing twelve months. The roadmap published for the OP Stack on 2026-01-14 covers Ink's stack but names no primitive as in use or imminent, stating instead that the scheme is not yet decided, so it is not an announced-primitive claim under this sub-score. 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. This sub-score measures the distance between claim and delivery only; the absence of delivery is scored at 5a, 5b and 5c and is not counted twice.

Undisclosed, which the rubric scores zero. Ink publishes no per-block signature-data multiplier under any post-quantum deployment, because it has selected no scheme, so there is no figure to set against the 65-byte ECDSA secp256k1 baseline an Ethereum 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. Ink posts batch data to Ethereum blobs, which is the offloading lever a post-quantum footprint plan would use, but no public source documents a post-quantum batching, aggregation or data-availability plan for Ink. 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: Ink mainnet is supported natively by Kraken Wallet and by Rainbow, and by MetaMask through manual custom-network addition at chain ID 57073. Post-quantum coverage does not. None of these three 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 transaction or key volume to credit for concentration among roadmap-covered vendors. This tile measures whether the wallets holding Ink keys have a plan, and on the public record none of them has published one.

Zero. Two bridge routes carry value in and out of Ink: Across Protocol, which advertises routes into Ink from 23 or more chains, and the canonical OP Stack deposit and withdrawal bridge to Ethereum L1. Across settles through UMA's Optimistic Oracle and, in V4, zero-knowledge proofs generated by Succinct's SP1, while relayer and depositor authorization remain ECDSA secp256k1 signed messages on every EVM leg. Neither route publishes a dated post-quantum roadmap for the signature schemes or key-establishment schemes securing its relayer, attestation or message-passing paths. Bridge approvals are signed messages and therefore Forge-class exposure once a CRQC exists, and no roadmap covers them.

Zero. No public source names an institutional custody provider with an Ink-specific integration; the large multi-chain custody products list no Ink support. Kraken is both Ink's incubator and its sequencer operator and lists the chain, which makes it the concentration point for retail deposit and withdrawal signing and for TLS termination on that path, and no dated post-quantum roadmap is published for that surface. The MPC-compatibility clause is out of scope here: Ink mandates no post-quantum signature scheme, so there is no SLH-DSA threshold-signing problem to assess and no custodian-MPC alternative to require.

Zero across all three components. RPC-provider roadmaps, 0 of 8: Ink documents Alchemy, Gelato, QuickNode, Tenderly, dRPC, Uniblock and BoltRPC, and none of those listings states a post-quantum roadmap or a hybrid key-establishment plan for its Ink endpoints. Hybrid X25519MLKEM768 key agreement is in fact negotiated at three of the four documented public hosts as a content-delivery-network default; 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. HSM and key-management roadmaps, 0 of 8: no public source names the hardware security module or key-management service holding Ink's sequencer and batch-submitter ECDSA secp256k1 keys, so no vendor algorithm-support roadmap can be pointed to for the highest-value keys on the chain. TEE attestation, 0 of 9: no trusted execution environment is documented anywhere in Ink's sequencing, block-building or oracle path, so there is no attestation chain whose RSA-to-post-quantum transition would apply. That component has no in-scope surface and the tile total is unchanged by it, since the other two components are real zeros.

Ink has no validator set and no stake distribution. One sequencer, operated by Kraken, orders and executes every transaction, running a single client stack of op-node and op-geth with no client diversity. The small credit is for the one security-critical role that is genuinely distributed: permissionless fault proofs launched on mainnet with two independently operated challengers, Gelato and Kraken, with Kraken seeding its own challenger with about 49 ETH at launch and anyone able to stake ETH and run another, and L2BEAT records Ink as passing its walkaway test, meaning users can exit even if the Security Council disappears. That distributes the dispute role, not the signing role. A cryptographic migration has to move the signing role, and it sits with one operator.

Cadence is fast and demonstrated. Ink inherits Superchain-wide activation timestamps automatically through the superchain_time value of 1742396400, dated 2025-03-19, in its registry configuration, and coordinated upgrades reach it in the same on-chain action as OP Mainnet, Soneium and Unichain through the shared upgrade-contracts-manager. L2BEAT records that the Security Council holds instant upgrade power with no notice period and no user exit window, which is a governance cost and at the same time means an emergency cryptographic change could ship without waiting out a delay. What is absent is the demonstration: no upgrade in Ink's record was coordinated against a live deadline or an active threat.

No party owns a post-quantum migration for Ink. Upgrade authority itself is a named body with a published mandate: the Optimism Collective's Security Council, established 2024-02-09 through an on-chain transaction creating a two-of-two multisig with the Optimism Foundation, requiring a minimum of eight independent members and a signing threshold of at least 75 percent, and currently recorded by L2BEAT as a ten-of-thirteen multisig. Ink's registry entry sets governed_by_optimism true, so it is governed under that mechanism rather than an independent Ink governance body. That body governs Superchain protocol upgrades in general. No individual, team or working group anywhere in the public record holds an Ink post-quantum migration mandate, and no Ink-specific post-quantum coordination role has been created. The credit is for a mandated upgrade authority existing, not for post-quantum ownership.

Zero. No public record shows Ink coordinating a cryptographic change while an attacker was actively threatening it. Ink has been live since December 2024 and its upgrades to date have been scheduled Superchain-wide releases delivered through the shared pipeline, not responses to an adversary operating against it. This sub-score measures demonstrated behaviour under adversarial pressure and there is no instance in the record to read.

Zero. Ink documents no canary and no tripwire. 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 consensus with a published detection threshold, and no automated response such as pausing sequencer signing, switching to a hybrid scheme or alerting user wallets. A single-sequencer chain could stand up a monitored canary on one operator decision, and none is published.