Gnosis Chain publishes no consolidated cryptographic inventory of its own. The deployed primitives are fully determined by the Ethereum execution- and consensus-layer specifications its clients implement, run against a Gnosis Chain network flag and the chain's own published network configuration: Nethermind, Erigon, Geth and Reth on the execution side, Lodestar, Nimbus, Teku and Lighthouse on the consensus side. That makes the inventory complete and specific for the base chain and is the basis of the credit here. Three surfaces carry no named construction in any public document and hold the score down: the threshold-encryption scheme behind the Shutterized Gnosis Chain, the attestation scheme used by validators of the Arbitrary Message Bridge that the OmniBridge is built on, and the eventual proof system of the ZK rollup that GIP-153 approved, for which the proposal names only an interim proving setup described as likely TEE-based behind a configurable M-of-N verification threshold across multiple provers.

Every primitive on the base chain classifies cleanly, and the classification is uniformly bad: three independent Shor-break surfaces (secp256k1 discrete log at the account and transport layers, secp256r1 discrete log at the contract-verification precompile, BLS12-381 pairings at consensus and at blob data availability) plus Grover-weakened symmetric primitives. The sharpest Grover case is AES-128-CTR inside the ECIES handshake, falling to roughly a 64-bit search; the framed session is keyed with a 32-byte secret and runs AES-256-CTR, which retains roughly 128 bits. Signing is over a digest throughout: account transactions are ECDSA secp256k1 over the Keccak-256 hash of the RLP-encoded transaction, and consensus signatures are BLS12-381 over hash-tree-root digests. The pure-versus-pre-hash distinction that separates ML-DSA-65 from HashML-DSA-65 under FIPS 204, or SLH-DSA from HashSLH-DSA under FIPS 205, does not yet arise here because no post-quantum signature scheme is specified for this chain; any future specification would have to state that choice and its domain separator explicitly. Three layered or future surfaces cannot be classified at all because no public source names their construction, and that incompleteness is what the lost points measure.

Zero post-quantum algorithm families. No lattice scheme (no ML-DSA-44/65/87 per FIPS 204, no ML-KEM-512/768/1024 per FIPS 203, no Falcon-512/1024 per the round-3 submission), no hash-based scheme (no SLH-DSA per FIPS 205, no XMSS or XMSS^MT per RFC 8391, no LMS/HSS per RFC 8554, no Winternitz construction), no code-based KEM (no Classic McEliece, BIKE or HQC), no isogeny scheme. The rubric scores zero families at 0. The Cryptographic-Diversity Cap does not apply, because that cap addresses lattice-monoculture and this chain has deployed no lattice scheme to be monocultural about.

No primitive carrying a NIST post-quantum security-category assignment is deployed or named for Gnosis Chain, so there is no category 1-to-5 mapping to publish and no parameter-set choice to defend - nothing at category 2 like ML-DSA-44, nothing at category 5 like ML-DSA-87. ECDSA secp256k1, ECDSA secp256r1 and BLS12-381 carry no post-quantum category at all: Shor recovers the private scalar on any of those curves. This is a gap the chain has not closed rather than a property of its architecture, so it scores a real 0.

Gnosis Chain runs four independent execution-client implementations (Nethermind, Erigon, Geth, Reth) and four independent consensus clients (Lodestar, Nimbus, Teku, Lighthouse), which is genuine implementation diversity on the classical path. The classical primitives it depends on sit at the upper cryptanalytic tiers: ECDSA over secp256k1 and secp256r1 and SHA-2 at tier 1, Keccak-256 at tier 2. That is the whole of the credit. Every post-quantum component of this sub-score scores nothing because none exists: no formally verified post-quantum library is in the stack (no Libjade or EasyCrypt-verified ML-KEM, ML-DSA, SLH-DSA or XMSS implementation), there is no post-quantum constant-time posture to assess against the dudect methodology or the KyberSlash timing-leak class, the stateful-versus-stateless distinction has no subject, and there is no deployed post-quantum verifier and therefore no reproducible-build or independent-audit evidence tying a compiled artifact to audited source.

Gnosis Chain uses the Ethereum account model: an address is derived from the Keccak-256 hash of the ECDSA secp256k1 public key, and that public key becomes permanently recoverable from the signature of the account's first outgoing transaction. Every account that has ever spent is therefore exposed-after-spend, and still-funded if it holds a balance, with no expiry and no protocol-enforced rotation. There is no post-quantum-safe destination to spend into, single-use addresses are not available because the account model reuses one address indefinitely, and no public source publishes a census of how much value sits at exposed keys on this chain. The single point reflects only that the exposed set is bounded to accounts that have transacted rather than the entire address space.

An account that has received value on Gnosis Chain but never signed an outgoing transaction exposes only the Keccak-256 hash of its public key. It is mitigated-until-spend: Shor has nothing to operate on until the key is revealed. That is a real structural mitigation inherited from the account model and it is the basis of the score here. It is also the entirety of the protection. No figure for never-spent balances on Gnosis Chain is published, the chain enforces nothing that keeps cold value cold, and the first spend from any such account moves its value into the exposed bucket with no post-quantum-safe destination available to receive it.

2c-LR, long-range and at-rest, 1 of 13: validator public keys on the Gnosis beacon chain are BLS12-381 G1 points registered in chain state and public for the whole life of the validator, and historical attestations retain validity in the weak-subjectivity record, so long-range forgery needs no timing advantage of any kind. The attestation scheme used by Arbitrary Message Bridge validators is not named in the chain's own bridge documentation, which publishes only the 4-of-7 validator multisig threshold, so the shelf life of a bridge approval cannot be characterised from the public record. Nothing mitigates either surface. 2c-SR, short-range and on-spend, 6 of 12: window factor 4 of 6, since Gnosis Chain produces a block every 5 seconds and its beacon chain runs 16-slot epochs, so an epoch is 80 seconds and finality after two epochs lands on the order of 160 seconds; the interval between a transaction's public-key reveal in the mempool and its finality is short and an on-spend forgery would need a fast-clock CRQC that breaks secp256k1 inside that window. Exposure-discipline factor 2 of 6, taken as the maximum applicable rather than a sum: the Shutterized Gnosis Chain gives mainnet users a threshold-encrypted mempool, which is genuine broadcast privacy, but it is reached through a separate RPC endpoint rather than the base protocol, no figure for the share of traffic using it is published, and its cryptographic construction is specified nowhere, so its own quantum posture cannot be characterised. Single-use addresses are structurally unavailable and there is no post-quantum-safe spend path.

The devp2p/RLPx transport between Gnosis Chain nodes agrees keys with ECIES over secp256k1 using the NIST SP 800-56 concatenation KDF, with AES-128-CTR and HMAC-SHA-256 protecting the handshake payload, then encrypts the framed session with AES-256-CTR under a Keccak-256-derived secret and authenticates it with Keccak-256 MAC accumulators. Each node holds a static secp256k1 identity key. The asymmetric half is the harvest-now-decrypt-later exposure: Shor recovers the ephemeral secp256k1 key from a recorded handshake and returns the session key, at which point the symmetric strength of the frame cipher is irrelevant. No hybrid KEM combiner is anywhere in the stack, so there is no ML-KEM-768 alongside X25519 in the manner of the IETF hybrid TLS design, and no public RPC endpoint for this chain documents post-quantum or hybrid key agreement. The single point credits the per-session ephemeral handshake, which confines each decryption to one recorded session instead of yielding a long-term master key; it does not survive Shor.

The ledger is pseudonymous and fully transparent: sender address, recipient address, value and calldata of every executed transaction are public on any block explorer for the chain. The Shutterized Gnosis Chain conceals transaction content only until the transaction's position in the block is fixed, after which it is decrypted and executed in the clear, so it changes nothing about graph visibility. Gnosis Chain publishes no structural-impossibility statement naming what its architecture can reveal, to whom and under what conditions, which under the rubric independently holds this sub-score to at most half of maximum.

Component (i), 4 of 8: the chain documents thirteen independent third-party RPC providers, among them Ankr, Chainstack, dRPC, QuickNode, POKT and OnFinality, alongside public endpoints and full instructions for running a node, so entry is not structurally single-vendor; no measurement of the share of transactions originating through the top three providers is published, so the concentration figure the rubric asks for does not exist in the public record and the 70%-concentration zero-out cannot be tested. Component (ii), 4 of 7: the base devp2p/RLPx mempool is observable to any connected peer, which is the standard exposure of this client stack, but independent entry points are plentiful (four execution-client implementations, four consensus-client implementations, documented self-hosting) and the Shutterized threshold-encrypted mempool is a live alternative entry point on mainnet at chain ID 100. Component (iii), 0 of 5: no validator metadata retention policy covering IP addresses, timing or client fingerprints is published for Gnosis Chain, and the rubric scores an undeclared policy at zero.

The route the chain's own documentation calls canonical between Ethereum and Gnosis Chain is the OmniBridge, which mints the canonical representations of bridged assets, is built on the Arbitrary Message Bridge and relies on the same validator set and trust model, published as a 4-of-7 validator multisig, with governance split between bridge governors who set parameters and bridge validators who relay messages. Deposits on one side and releases on the other are matched public events with matched amounts, so a passive observer links source to destination without privileged access. No unlinkability mechanism is documented. The signature scheme those bridge validators use to attest messages is not named on the chain's own bridge pages, so the cryptography protecting the relay cannot be characterised from the public record. No structural-impossibility statement is published.

There is little retroactive de-anonymization to suffer at the base layer because there is no anonymity there to lose: transaction content on Gnosis Chain is public at execution, so Shor breaking secp256k1 reveals nothing about a past transaction that a block explorer does not already show. The residual surface is twofold. Harvested devp2p/RLPx sessions decrypt once secp256k1 falls, exposing historical broadcast timing and node-level origin. And the Shutter threshold-encryption layer protects content before execution under a construction that no public source specifies, so whether harvested pre-execution ciphertexts are retroactively readable is not answerable from the public record. The score records a small real exposure, not a privacy design that survives a CRQC. The half-of-maximum ceiling from the missing structural-impossibility statement applies and does not bind.

The Shutterized Gnosis Chain is live on mainnet at chain ID 100 and on the Chiado testnet at chain ID 10200, built by the teams of Shutter Network, Gnosis and Nethermind, and it splits a decryption key across a committee of keyholders so no single party can read a transaction and content stays sealed until the transaction's position in the block is fixed. Under the rubric this is commit-reveal and batch-ordering: computationally secure rather than information-theoretic, which caps this class at 10. Two further limits hold it below that cap. It is reached through a separate RPC endpoint rather than the base protocol, with no published figure for the share of traffic that uses it. And it hides content rather than the transaction graph, so sender and recipient are public the moment the transaction executes. No public source names the cryptographic construction behind the committee scheme, so it cannot be credited as a named mechanism with a cited specification.

EIP-7702 has been live on Gnosis Chain mainnet since the Pectra activation at 2025-04-30 14:03:40 UTC, and the chain's own documentation describes it as giving externally owned accounts the super powers of smart accounts, including batched and sponsored transactions. It is a real, cited, in-production mechanism that lets delegated contract code impose arbitrary verification logic on an account, which satisfies the rubric's requirement for a specification plus a production instance inside five years. It is not signature-algorithm agility at the protocol layer: the protocol still requires an ECDSA secp256k1 signature to authorize both the delegation and the account, there is no versioned signature-type registry, and adding ML-DSA-65, SLH-DSA-SHA2-128s or Falcon-512 to the account or consensus path would take a hard fork. The chain demonstrated exactly that constraint in April 2026, when adding a second verification curve, secp256r1 via EIP-7951, required the Fusaka hard fork rather than a configuration change. No EIP-8141-class generic-signature framework is activated here. The BIP-360-class key-path-disable pattern the rubric credits is a UTXO construction and has no analogue on an account-model chain.

Two account-abstraction mechanisms are live. EIP-7702 activated on mainnet on 2025-04-30 and gives externally owned accounts delegated contract code. Safe, the smart-account standard that originated in this ecosystem, offers ERC-4337 support through the Safe4337Module, which validates that the Safe owners signed the user-operation hash and requires Safe v1.4.1 or newer. Under the rubric that is account abstraction with no documented client-layer post-quantum migration path, which scores 15 and no higher: no Safe documentation page names a post-quantum signer type, and no wallet or signing-device route to post-quantum protection for Gnosis Chain users is documented anywhere, so the 17-point and 20-point bands do not open. The Ed25519 seed-rebind floor does not apply, because Gnosis Chain accounts commit to ECDSA secp256k1 keys and not to an RFC 8032 Ed25519 seed. The post-quantum rebind bonus is 0, since no public artifact specific to a rebind on this chain exists. This sub-score measures migration plumbing that exists, not post-quantum intent, of which the record shows none.

Five scheduled protocol upgrades since the Merge, each preceded by a Chiado testnet activation: Shanghai/Capella, Dencun on mainnet 2024-03-11 18:30:20 UTC after Chiado on 2024-01-31 18:15:40 UTC (40 days), Pectra on mainnet 2025-04-30 14:03:40 UTC after Chiado on 2025-03-06 09:43:40 UTC (55 days), and Fusaka on mainnet 2026-04-14 12:06:20 UTC after Chiado on 2026-03-16 09:33:00 UTC (29 days). A sixth fork was unscheduled: in December 2025 the chain hard-forked to move funds frozen in the November 2025 Balancer exploit to a DAO-controlled recovery address, a state-rewriting fork that press coverage described as controversial in principle, and it pushed the Fusaka schedule later than Ethereum's. The cadence is repeatable and testnet-first, which is what this sub-score measures; the deduction from maximum reflects the contested character of the state-rewriting fork. None of these upgrades changed the account or consensus signature algorithm, though Fusaka did add a second verification curve as a precompile.

No public Gnosis Chain or GnosisDAO document addresses hybrid classical-plus-post-quantum readiness in any form. The consensus path is the hard constraint: BLS12-381 aggregation with public keys in G1 and signatures in G2 is fixed in the beacon-chain specification the chain's Lodestar, Nimbus, Teku and Lighthouse clients implement, and running a second signature scheme alongside it requires a consensus fork plus a new aggregation design, not a configuration change. At the account layer an EIP-7702 delegation could in principle host an ML-DSA-65 or SLH-DSA-SHA2-128s verifier in contract code, and EIP-7951 shows the chain will ship a new verification curve as a precompile when it forks, but the protocol would still require the account's ECDSA secp256k1 signature to authorize, making any such construction additive rather than a substitution, and no post-quantum verifier is deployed or specified. The credit is for that narrow architectural opening and nothing more.

Not scored, and excluded from both the numerator and the denominator of this dimension. Gnosis Chain deploys no hash-based signature scheme at either the account or the consensus layer, stateful or stateless: no XMSS or XMSS^MT per RFC 8391 (approved for use per NIST SP 800-208), no LMS or HSS per RFC 8554, no SLH-DSA per FIPS 205, no Winternitz one-time construction. There is no signing state to track, no restore procedure that could rewind a leaf index, and no multi-device index space to partition, so this sub-score has nothing to observe on this chain. The chain's absence of post-quantum signatures is scored where it belongs, in 1c, 1d and Dimension 5, and is not charged a second time here.

Gnosis Chain is squarely in scope for this sub-score: its consensus depends on aggregated BLS12-381 signatures over attestations, verified with FastAggregateVerify and AggregateVerify under the BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ ciphersuite, and the Pectra activation of 2025-04-30 both added the EIP-2537 precompile for BLS12-381 curve operations and adopted EIP-7549, which moves the committee index outside the attestation and is an aggregation-efficiency change. No public source declares any path to post-quantum aggregation for this chain: not hash-based signatures with SNARK or STARK aggregation, not authenticated-channel or MPC consensus replacing signatures with symmetric primitives, not staged checkpoint migration with post-quantum signatures every k-th block. The rubric scores an undeclared path at 0. The consensus standing-exposure clause applies: validator BLS12-381 public keys are registered in chain state and epoch-public, so a CRQC fabricates a quorum certificate without racing any confirmation window, and a 5-second block time is no defense at this layer. A 0 here independently bars Migration Stage 5.

Zero percent. No post-quantum signature primitive is live on Gnosis Chain mainnet or on the Chiado testnet, and none is named under any Gnosis Improvement Proposal number. Mainnet signing traffic is ECDSA secp256k1 at the account layer and BLS12-381 at the consensus layer. The three scheduled hard forks of the last three years - Dencun in March 2024, Pectra in April 2025, Fusaka in April 2026 - each applied chain-wide to 100% of traffic from their activation epoch and left the signature algorithms of both layers unchanged; Fusaka added ECDSA over a second classical curve, secp256r1, not a post-quantum scheme. Migration Stage 0 follows directly from this sub-score.

No post-quantum code is merged into any client Gnosis Chain runs. The execution clients (Nethermind, Erigon, Geth, Reth) and the consensus clients (Lodestar, Nimbus, Teku, Lighthouse) are the standard Ethereum implementations run against a Gnosis Chain network flag and configuration; no ML-DSA, ML-KEM, SLH-DSA, XMSS or Falcon implementation appears in the signing or verification path of any of them for this chain. There is nothing to deduct as testnet-only, because no such code exists on the testnet either.

Not one Gnosis Chain validator holds or uses a post-quantum key. This is a real zero and not an absence of the thing measured: the validator keys exist, they are BLS12-381 keys registered in chain state, and no rotation to a post-quantum scheme has been proposed, specified or deployed for them. The transition GIP-153 approved would sunset this validator set rather than migrate it. Account-layer post-quantum signing is measured in 5a and is not re-credited here.

Voided at 0 by the rubric's own condition, which zeroes this sub-score whenever mainnet post-quantum traffic is zero. It would score 0 on its own terms in any case: no dated post-quantum milestone is published for Gnosis Chain, protocol-enforced or otherwise. GIP-153 carries a dated target of December 2026 or January 2027 for the validator sunset and the first rollup block, but it is the rollup transition and addresses no cryptographic migration. There is no prior post-quantum date for this chain whose hit, slip or miss could be scored as a delivery track record.

No post-quantum claim has been published for Gnosis Chain in the trailing twelve months: no foundation blog post, no keynote claim, no whitepaper, no NIST submission, no exchange press release naming a post-quantum primitive for this chain. Announced is 0 and shipped is 0, so there is no gap between what was claimed and what was delivered, no ratio above 1.5 to deduct against, and no narrative-only tag. This sub-score measures the distance between promise and delivery, and a chain that has promised nothing has no distance to answer for. It is not a credit for readiness, of which this dimension records none.

Undisclosed, which the rubric scores at 0. Gnosis Chain has no post-quantum deployment, so no per-block signature-data multiplier against the 64-byte compact ECDSA baseline can be stated: there is no ML-DSA-44 at 2,420 bytes per the FIPS 204 size table, no SLH-DSA-SHA2-128s at 7,856 bytes per the FIPS 205 parameter-set table, no Falcon-512 at 666 bytes per the round-3 submission, and no SNARK-aggregation design that would push an effective multiplier below one. No recalibration of transaction-weight accounting to stop post-quantum-secured transactions being fee-penalized against classical ones is documented, and no per-quarter migration rate for exposed accounts exists to report alongside a multiplier.

Safe, the smart-account standard that originated in this ecosystem, documents its Safe4337Module as validating that the Safe owners signed the user-operation hash; the owner signatures it wraps are ECDSA, or m-of-n ECDSA for multisig accounts. No Safe documentation page names a post-quantum signer option. No wallet serving Gnosis Chain publishes a post-quantum roadmap with dates, so no vendor earns the per-vendor roadmap credit and no transaction or key volume sits behind a roadmap vendor. This is an absence in the published record rather than a confirmed negative from any vendor.

The OmniBridge, which the chain's own documentation describes as minting the canonical representations of bridged assets, is built on the Arbitrary Message Bridge and relies on the same group of bridge validators and the same trust model, published as a 4-of-7 validator multisig, with governance split between bridge governors who set parameters and bridge validators who relay messages. The chain's own bridge documentation does not name the signature scheme those validators use to attest messages, let alone a post-quantum roadmap for it. No bridge serving Gnosis Chain publishes a post-quantum roadmap with dates for its top vendors.

Kraken lists GNO among the assets held in Kraken Custody, its qualified-custodian product, and publishes no post-quantum signature support, no algorithm roadmap for the accounts or assets it custodies, and no disclosure of the signing or HSM cryptography behind them on that page. No exchange or custodian holding GNO publishes a dated post-quantum roadmap. The MPC-compatibility question the rubric raises for chains mandating SLH-DSA does not arise, since this chain mandates no post-quantum scheme at all.

Component (i), 0 of 8: the chain's documentation directs users to thirteen third-party RPC providers, Ankr, Chainstack, dRPC, QuickNode, POKT and OnFinality among them, and none of them publishes a post-quantum TLS or hybrid-KEM roadmap for the endpoints serving this chain; RPC transport is standard TLS with no ML-KEM-768 with X25519 or equivalent hybrid named. Component (ii), 0 of 8: no HSM vendor algorithm-support roadmap is named for any Gnosis Chain infrastructure, and the secp256r1 precompile EIP-7951 added in April 2026 enables device-native signing through HSMs and FIDO2 authenticators at the contract layer without any vendor algorithm roadmap attached to it. Component (iii), 0 of 9: Gnosis Chain as a standalone layer 1 is not documented as using Intel TDX, Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves or Azure Confidential Computing in block building, sequencing or oracle attestation, so there is no RSA-to-post-quantum remote-attestation transition to credit. GIP-153 states that the first iteration of the rollup will use an interim proving setup, likely TEE-based, behind a configurable M-of-N verification threshold across multiple provers; it names no vendor, no attestation scheme and no post-quantum posture for it, and nothing is deployed.

GnosisDAO's own community summaries report the validator count falling from over 140,000 in the April 2026 summary to roughly 76,000 in June 2026 to roughly 52,000 by the July 2026 summary, with about 295,000 GNO staked at the July figure. Client diversity is genuine on both layers: four execution clients (Nethermind, Erigon, Geth, Reth) and four consensus clients (Lodestar, Nimbus, Teku, Lighthouse) are documented as supported implementations, so no single client governs either side of the stack. Against that, GIP-153 passed with 123,425 GNO cast by 54 voters against a 75,000 GNO quorum, so decision weight sits with a small number of addresses relative to the staking set, and what those voters approved is the sunset of the validator set. A validator population in steep decline under a decision to wind it down is not a distribution that supports a chain-wide cryptographic migration.

The upgrade record is the strongest governance evidence this chain has, and it covers both clocks this sub-score cares about. On the scheduled clock: five coordinated forks since the Merge, each with a Chiado testnet activation preceding mainnet by 29 to 55 days, running through Dencun (mainnet 2024-03-11), Pectra (mainnet 2025-04-30 14:03:40 UTC) and Fusaka (mainnet 2026-04-14 12:06:20 UTC). On an adversary's clock: after the Balancer exploit of 2025-11-03, validators coordinated an emergency response that blacklisted the attacker address and then, following governance approval, executed a hard fork in December 2025 that moved the frozen funds to a DAO-controlled recovery address. That is a protocol change shipped against a deadline set by an attacker rather than a roadmap, and it is the evidence this sub-score asks for. Two things hold it below maximum. The emergency fork rewrote state rather than changing any cryptographic algorithm, and absorbing it pushed the scheduled Fusaka activation months later than Ethereum's, which is a real measure of the chain's spare coordination capacity under load.

No public source names a person, team or working group holding a standing mandate for post-quantum cryptography on Gnosis Chain. What does exist is a functioning general governance body: GnosisDAO runs a numbered improvement-proposal process with a published 75,000 GNO quorum, and GIP-153 demonstrates it can carry a decision that reshapes the chain's security model. That machinery is real and is what the credit reflects. It has never been pointed at cryptographic migration, and no published mandate assigns anyone that work.

This sub-score asks for one specific thing: a cryptographic change coordinated while an attacker was actively threatening the chain. Gnosis Chain has coordinated under active attack - the December 2025 fork that recovered funds frozen in the November 2025 Balancer exploit - but that fork rewrote chain state and moved balances to a recovery address; it changed no signature scheme, no curve, no key format and no verification rule. The scheduled forks changed protocol behaviour on a roadmap clock, not under attack. So the precedent this sub-score measures is absent while the general capability is not, and the capability is credited in 7b rather than a second time here. This is a real zero rather than a category that does not apply to this architecture: the chain has a validator set, a working governance process and a fork history, so the precedent could exist, and none is recorded.

No quantum-risk tripwire, monitoring threshold or contingency trigger is documented for Gnosis Chain. There is no monitored honeypot account at a deliberately exposed ECDSA secp256k1 key, no rate-limiting rule on spends from exposed accounts, no cryptographic tripwire embedded in consensus with a published threshold, and no automated response that would pause signing, switch to a hybrid path or alert user wallets on detection. The rubric scores the absence of any canary at 0.