The L1 signing inventory is measured off the wire: ML-DSA-87 and ECDSA secp256k1 in one envelope, Keccak-256 for hashing, all three confirmed by independent recomputation from public RPC data. The deductions are precise: the validator-transport KEM is undocumented and no parameter set is fixed for chain use (the ML-KEM-1024 naming attaches to a product, not the chain); the consensus/validator sealing signature scheme is unnamed and, because the block header carries no signature field, not observable at all; and the semantics of the one-byte scheme identifier (item 9, constant 0x02) are undocumented, so the inventory of schemes the client can accept is unknown.

The signing surface is tagged as hybrid rather than pure post-quantum, and the block hash is identified as Keccak-256 with an acceptable Grover margin. Remaining deductions: (a) the consensus sealing scheme is untaggable because it is not observable, which is the single largest unclosed exposure on this dimension; (b) a classical-only transaction path remains open for unregistered accounts; (c) the economic layer is unmitigated Shor-breakable ECDSA secp256k1; (d) the lattice-confidence discount applies; (e) the post-quantum half is a single lattice family with no Shor-diverse fallback; (f) an unnamed zero-knowledge component remains unclassifiable.

Exactly ONE post-quantum family is deployed: lattice (ML-DSA-87). Per the 1c rubric, '1 lattice-only = 5 (hard cap)'. The classical secp256k1 half of the hybrid is not a second post-quantum family and earns no diversity credit - it is the component the migration exists to retire. No hash-based (SLH-DSA per FIPS 205, XMSS per RFC 8391, LMS) or code-based (Classic McEliece, BIKE, HQC) signature family is deployed or documented as planned; a 2026-06-09 partnership release name-drops FIPS 205 in a marketing bundle but documents no deployment, and the one-byte scheme identifier in the transaction envelope has been observed at a single constant value. Lattice monoculture is the single-point-of-failure posture the diversity cap targets. Hard-capped at 5.

The deployed post-quantum scheme is ML-DSA-87, NIST security Category 5, and this is now established by measurement rather than by executive attestation: the 2,592-byte public key and 4,627-byte signature match the FIPS 204 ML-DSA-87 parameter set exactly and are unambiguously distinct from ML-DSA-65 (1,952 / 3,309) and ML-DSA-44 (1,312 / 2,420). No deduction for an unconfirmed parameter set applies. Residual deductions: the category of any transport KEM is unknown because no chain-level KEM is documented; the consensus sealing scheme has no category because it is undisclosed; and the classical half of the hybrid, plus the entire economic layer, is ECDSA secp256k1 at roughly 128-bit classical security and no NIST post-quantum category at all.

The ceiling is low and stays low. Positive evidence: the deployed encoder produces FIPS 204-conformant output. The 83-byte hint segment of every sampled signature has 8 trailing cut positions that are non-decreasing and bounded by omega = 75, per-polynomial hint indices in strictly increasing order, and every unused hint byte zero - a condition the FIPS 204 hint-unpacking algorithm rejects if violated, and one that random or padded bytes would fail. That is meaningful evidence of a conformant implementation of the encoding. Negative evidence: no independent audit of any kind exists (the public security-listing service reports no first-party and no third-party audit, and its coverage is the ERC-20/BEP-20 token contract, not the L1); the GitHub organisation reports zero public repositories, so the client and the ML-DSA verifier cannot be reviewed for constant-time behaviour, KyberSlash-class timing-leak resistance, library provenance (no liboqs or comparable attribution is available), or formal-verification status; and the signing pre-image is undocumented, so neither signature can be cryptographically verified by a third party - we attempted to reproduce both the ML-DSA-87 verification and the ECDSA recovery across candidate pre-images and could not derive the construction. ML-DSA itself is cryptanalytic tier 3a (finalized FIPS); the deployed verifier remains unauditable.

Forge. 16, on two offsetting factors. In favour: L1 accounts registered in the post-quantum registry sign with ML-DSA-87 alongside ECDSA, so revealing the secp256k1 public key on spend does not by itself enable a Shor-based takeover of the account; a forger would also need to defeat ML-DSA-87. Each sender's ML-DSA-87 public key is stable across its transactions, consistent with a genuine per-account binding. Against: the secp256k1 key is in the signing path and is revealed on every spend, and unregistered accounts can transact under plain type-0x2 ECDSA-only envelopes, so the chain is not uniformly protected. The material deduction is the economic layer: $NAORIS on Ethereum and BNB Smart Chain, 5.76K reported holders, ECDSA secp256k1 only, public keys revealed on spend and fully Shor-recoverable, with no migration path published.

Forge. Dormant L1 balances sit behind ML-DSA-87 as well as secp256k1 for registered accounts, so L1 cold funds are not forgeable at the signature layer by a future quantum computer that breaks only the curve. Two qualifications now measurable rather than assumed: there is essentially nothing dormant on the L1 to protect - of 594 lifetime transactions exactly one moved a non-zero value, and the token supply lives entirely on Ethereum and BNB Smart Chain - and the protection depends on an unaudited closed-source verifier. Deduction: dormant $NAORIS held in Ethereum and BNB Smart Chain wallets is ECDSA secp256k1 and IS cold-key-exposed, with no migration policy published.

Forge. Historical L1 transactions from registered accounts carry an ML-DSA-87 signature recorded permanently alongside the ECDSA one, and the transaction id is Keccak-256 over both, so a future quantum adversary that breaks secp256k1 cannot retroactively produce a valid-looking historical transaction for a bound account without also breaking ML-DSA-87. Deductions: (a) lattice carries the long-horizon confidence discount for very-long-lived signatures; (b) historical type-0x2 ECDSA-only transactions from unregistered accounts are forgeable post-Shor; (c) the consensus-layer seal over every block is of unknown scheme, so the long-term validity of the chain's own history - as distinct from individual transactions - cannot be assessed; (d) the EVM-token economic-layer signatures on Ethereum and BNB Smart Chain are ECDSA secp256k1 and forgeable post-Shor.

Decrypt (harvest-now-decrypt-later). Validator-to-validator transport encryption between dPoSec nodes is not described in any public document, and no hybrid post-quantum KEM (for example X25519 with ML-KEM per the IETF hybrid key-exchange work) is documented at the chain's transport layer. The operator does name ML-KEM-1024 with AES-256-GCM at exact parameter-set level, but for a Confidential File Sharing product, not for chain transport, and that product is announced rather than shown. The public JSON-RPC endpoint is reachable over ordinary TLS terminated at a commercial edge, which is not validator-to-validator transport and earns no credit here. The documentation hosts are unreachable. Harvested transport ciphertexts under a classical key exchange would be decryptable once Shor breaks the classical component. Low score: no documented hybrid post-quantum KEM at chain transport.

Anonymity. Now measured rather than inferred, and the measurement confirms the low score. The chain publishes an open JSON-RPC endpoint and an unauthenticated explorer API that expose from, to, value, nonce, status and block for every transaction, plus the sender's full 2,592-byte ML-DSA-87 public key in the clear on every type-0x6 transaction, and again in the registration calldata. That is a second permanent, high-entropy linkable identifier per account on top of the address, and it is published by the wire format itself rather than by any user action. The architecture is a continuous device-attestation mesh in which every device 'independently proves its security posture' to the network, a design that produces a dense metadata trail by intent. No native shielding, confidential transactions, or stealth addresses are described anywhere public, and none is observable. Low score: the architecture maximizes metadata visibility by design and the wire format adds to it.

Anonymity. Now measured. Exactly one public RPC endpoint is published; the node it fronts reports 7 peers; exactly two addresses sealed every block we sampled across the last ~300 blocks; the network has 9 distinct sending accounts in its entire history. Validator identity distribution, RPC topology beyond that single endpoint, mempool and gossip observability, and any validator metadata-retention policy are all unpublished. Per the rubric the metadata-retention component scores zero when the policy is undeclared, and concentration cannot be assessed favourably for a set this small. Low score, resting on measurement rather than on the absence of disclosure.

Anonymity. The 'Cross-Chain Trust Relay' description this sub-score previously rested on is no longer served anywhere public. What remains reconstructible: the $NAORIS token contract deployed at the identical address on both Ethereum and BNB Smart Chain, which implies a bridge or a deterministic cross-chain deployment that no public source explains, and whose bookkeeping is fully visible on both chains; and an announced product that generates a post-quantum key in the holder's browser, verifies classical ownership of a Bitcoin address, and anchors a commitment on Bitcoin mainnet - a deliberate cross-chain linkage between a post-quantum key and a classical address, announced with no ship date and no specification. Low: the L1's own cross-chain posture is undocumented, the one observable cross-chain surface is unexplained, and the announced one is correlation-increasing by design.

Confidentiality. 8. The zero-knowledge claim originates in a 2025-10-08 item that is explicitly labelled a press release from the project, describing how an independent third party's SEC submission characterises it; it is not independent technical reporting. It names no proof system - not Groth16, not a KZG-committed PLONK, not a STARK - so the component cannot be classified for Shor exposure: pairing- or discrete-log-based systems would put proofs and associated payloads at retroactive risk once Shor breaks the curve, while FRI or hash-based systems would not. Nothing resembling a proof verifier is observable in the chain surface we can read. What holds: the ledger design is transparency-first, so most on-chain content is already public and its visibility is not Shor-dependent, and the EVM-token economic layer remains Shor-exposed. The deduction for an unclassifiable zero-knowledge component stands, and the claim is company copy.

Anonymity. No on-chain mixer, no commit-reveal shuffle, no mixnet infrastructure, no batch-ordering and no cover traffic is documented or observable. Block production is a steady ~12-second cadence with almost every block empty, which provides no anonymity set. Naoris offers no structural anonymity-set mechanism, and its transparency-first design is the opposite intent.

There is now one observable agility artifact: the type-0x6 transaction envelope carries a dedicated one-byte field (RLP item 9) immediately before the post-quantum public key and signature, observed at the constant value 0x02 across every sampled transaction. Its position is exactly where a scheme identifier belongs, which is structural evidence of a versioned signature-type framework at the transaction layer - the mechanism a chain would need to add SLH-DSA per FIPS 205 or FN-DSA/Falcon (which has no published draft standard; no FIPS 206 draft appears in the NIST publication listing) without redefining the envelope. What is missing keeps the score low: the field's semantics are undocumented, no specification describes how a second scheme would be registered or activated, no versioned-signature standard is adopted, only one value has ever been observed, and no in-production switch instance exists. The token-governance 'Flash Votes' language is no longer served anywhere and is not counted.

An on-chain post-quantum key registry exists and is directly observable: transactions to system precompiles 0x...2000 (selector 0xd6b522a4) and 0x...2001 (selector 0x318c58c1) carry ABI-encoded dynamic bytes of length exactly 2,592 - the ML-DSA-87 public-key size - and every sender we sampled presents the same ML-DSA-87 public key across all of its subsequent transactions, which is what a stable per-account binding looks like on the wire. Registration itself is bootstrapped by an ordinary type-0x2 ECDSA-only transaction, a coherent design: classical signature to enrol the post-quantum key, hybrid thereafter. This matches the enforcement rule the operator's chief growth officer described on the record: bound accounts must carry a valid ML-DSA inner signature and ECDSA-only transactions from them are rejected. Deductions: no account-abstraction standard is adopted (no ERC-4337, no EIP-7702, no native AA), no key-rotation primitive is specified anywhere public, the registry's semantics and revocation behaviour are undocumented, enforcement cannot be verified without client source, and the migrating population is 9 accounts.

Unchanged. The observable chain has produced blocks continuously since a genesis timestamped 2026-07-22T10:49:03Z and reports a single client build (Naoris/v1.16.7-stable-577dc160, go1.24.11, linux-amd64) with no fork history to inspect. No formal upgrade mechanism, cadence, quorum, timelock or coordinated-upgrade record is published, and with zero public repositories development cadence cannot be independently measured. Low score reflects absence of a track record, not a contested fork. Note that the genesis date is itself part of the unresolved network-identity question recorded in source_disagreement: if the observable chain was re-genesised after the announced launch, that would be a coordination event of exactly the kind this sub-score exists to assess, and it is undisclosed.

Under the v3.1 'hybrid mandatory' framing this dimension rewards a deployed classical+post-quantum co-signing composition on the chain being scored, and Naoris has one running: 585 of 594 indexed transactions are type-0x6 envelopes carrying both a 4,627-byte ML-DSA-87 signature (with its 2,592-byte public key) and a secp256k1 ECDSA r/s/yParity triple, with the transaction id committing to both. The premise that the chain is pure post-quantum and 'by design does not do' hybrid on its own L1 is refuted by the wire format. Deductions holding the score below full: the composition is undocumented, so its security argument cannot be assessed and Gate 1a-Sig still fails on non-malleability; the hybrid covers the transaction layer only, with consensus/validator sealing of unknown scheme; a classical-only path remains open for unregistered accounts; and the whole deployment sits behind a closed-source, unaudited verifier at a scale of 9 accounts.

Naoris deploys no stateful hash-based signature scheme - no XMSS, LMS or HORS is referenced or observable, and the deployed post-quantum scheme is ML-DSA-87, which is stateless. Per the rubric, chains using only stateless schemes score the full 15 by default. The Stage-5 90-day state-management record requirement does not apply.

N/A, and the rationale is now positive rather than merely absent. We enumerated every field of a raw block header and recomputed its Keccak-256 hash to confirm the enumeration is complete: the header carries parentHash, sha3Uncles, miner, stateRoot, transactionsRoot, receiptsRoot, logsBloom, difficulty (0), number, gasLimit, gasUsed, timestamp, extraData (28 bytes, the client version string only), mixHash, nonce (0), baseFeePerGas, withdrawalsRoot, blobGasUsed, excessBlobGas, parentBeaconBlockRoot and requestsHash - a post-Prague go-ethereum header shape - and NO validator signature, seal, or aggregate-signature field of any kind. Block sealing therefore happens outside the header the public RPC exposes, and there is no public statement that validator voting uses Shor-vulnerable BLS aggregation nor that it uses a post-quantum-safe equivalent. Because Shor-vulnerable aggregation cannot be CONFIRMED to be in scope, 4f is marked N/A and its 20 points redistribute across 4a-4e. Dimension score = (5+12+4+11+15)/80 * 100 = 58.75 -> 59. Flagged as the dominant Dim-4 evidence gap: the transaction layer is hybrid and measurable, the consensus layer is opaque. If a disclosure shows BLS aggregation in dPoSec, 4f becomes in-scope and undeclared (score 0), lowering the dimension materially.

The post-quantum share of traffic is now measured, not estimated: we paginated the operator's explorer API through its complete transaction history and found 585 of 594 transactions carrying a 4,627-byte ML-DSA-87 signature and a 2,592-byte ML-DSA-87 public key, about 98.5%; the other 9 are type-0x2 ECDSA-only, of which 4 register post-quantum public keys. The network is live and moving: blocks at roughly 12-second intervals, height 174,700+ advancing in real time on 2026-08-19/20, node reporting eth_syncing false and 7 peers. Three discounts hold the score well below the share it would otherwise earn. First, network identity is unresolved: the explorer titles itself a mainnet explorer, but its host resolves through a load balancer named for a testnet, chainId 46512 is absent from the public chain registry, and the genesis block is timestamped 2026-07-22T10:49:03Z against an announced 2026-04-01 launch. Second, scale is negligible: 594 transactions in the chain's entire history, 9 distinct sending accounts, 585 of the transactions repeat calls to a single system precompile, exactly one non-zero-value transfer, and the overwhelming majority of the 174,700+ blocks are empty. Third, the share is measured against what the operator's own indexer exposes, and no independent archival node exists to cross-check it. The mainnet-traffic cap does not fire: the measured share is far above 20%.

Scored for behaviour only, never for code. No consensus-client source is inspectable: the GitHub organisation reports zero public repositories (public_repos = 0 via the API), so the chain client and the ML-DSA-87 verifier are closed and no commit or merged pull request can be examined. What is now observable is the deployed client's behaviour: it self-identifies as Naoris/v1.16.7-stable-577dc160/linux-amd64/go1.24.11 and stamps 'naoris' plus its Go version into every block's extraData; it implements a custom EIP-2718 transaction type outside the standard 0x00-0x04 range that carries ML-DSA-87 material; it exposes that material through standard RPC methods; and it operates system precompiles that accept 2,592-byte post-quantum public keys. That is real evidence that post-quantum code runs in the client, and it is worth more than zero. It is not code review: constant-time behaviour, verifier provenance, and whether the ML-DSA signature is actually checked rather than merely carried all remain unverifiable. Scored 4 for behavioural evidence under a Gate 2 that passes with caveats.

Marginal credit only. The validator set is countable rather than merely undisclosed: exactly two addresses sealed every block across a ~300-block sample, and the node reports 7 peers. What cannot be established is the thing this sub-score measures. The block header carries no signature field, so the scheme validators use to seal blocks is invisible; nothing public states whether validator identity keys are post-quantum, classical, or hybrid; and the on-chain post-quantum registry we can observe binds ordinary sending accounts, not demonstrably the block producers. Of the 9 sending accounts, at least 4 carry stable registered ML-DSA-87 public keys, but that is user-account adoption, not validator adoption. Scored 3: the set is measurable and tiny; its key scheme is unverifiable.

Not auto-voided (5a > 0 on measured post-quantum traffic), so this zero is scored on merit. No protocol-enforced, dated, independently-verifiable next milestones are published: no consensus-enforced sunset or flag-day for the classical-only transaction path, no dated technical roadmap with shipped artifacts, no enforcement mechanism, an empty blog on the operator's site, and no roadmap served anywhere. The events that exist - a launch announcement, partnership announcements, a product catalogue with no ship dates - are announcements, not protocol-enforced future commitments. The milestone-delivery track record required for full credit is also absent: the one dated commitment we can test against, a mainnet explorer announced at launch as launching 'alongside the network', is only satisfiable by an explorer whose chain history begins sixteen weeks after that launch. Scored 0. This triggers the milestone-discipline cap (Migration Stage <= 2), which is the binding stage constraint.

Announced post-quantum claims exceed independently verifiable ones by roughly 3.3 to 1. Three announced claims are shipped and verifiable (a live network with a public RPC and explorer API; a deployed classical+post-quantum hybrid transaction type carrying measured ML-DSA-87 material on 98.5% of indexed traffic; an on-chain post-quantum public-key registry observable in precompile calldata), and a 'Quantum Fabric' architecture announcement is not counted, because it appears on no served page. The announced side carries four productised post-quantum claims on the operator's site with no ship date, no specification, and no observable artifact. Deductions holding the score at 7: the largest self-reported figures remain unverifiable testnet claims that the one independent outlet covering the launch explicitly declined to verify; no audit of any kind exists; no source is published; and the operator's own current site makes no mainnet claim at all, so the shipped items are discoverable only by going around the marketing to the chain. Ratio ~3.3 -> Dim 5 deduction (>1.5) and QRI cap 65 (>2.0, non-binding); the narrative-only tag (>5.0) does not apply.

Measured, and worse than the rubric's worst band. Per type-0x6 transaction the chain carries 4,627 bytes of ML-DSA-87 signature plus 2,592 bytes of ML-DSA-87 public key, 7,219 bytes of signature material against the 64-byte ECDSA/Ed25519 baseline, about 113x. A sampled raw envelope measured 7,634 bytes end to end against 118 bytes for an observed plain type-0x2 transfer on the same chain. The public key is re-transmitted in full on every transaction rather than referenced from the on-chain registry that already holds it, which is the avoidable half of the cost. No SNARK aggregation, data-availability offloading, batching, or post-quantum transaction-weight de-penalization is documented or observable, and the chain discloses no per-block signature footprint. Per the rubric ('>38x or undisclosed = 0'), a measured 113x with no mitigation scores 0. The cost is a known quantity, measured rather than assumed.

No named wallet (MetaMask, Ledger, Phantom, Trezor, Safe) has publicly confirmed integration with the Naoris L1, and none publishes a Naoris-specific PQC roadmap. Two wallet touchpoints exist and neither qualifies: a public security-listing service records exchange-wallet partnerships for the $NAORIS EVM token, which concerns an ECDSA secp256k1 ERC-20 and not the L1; and the operator's own site names no wallet vendor at all, its enterprise page offering only a technical-briefing request. Worth noting for a future cycle: an L1 whose transactions carry a 4,627-byte signature and a 2,592-byte public key needs wallet-side support that no third-party wallet is known to have, and all observable signing to date comes from 9 accounts that are plausibly the operator's own. Scored 2.

No bridge or cross-chain-messaging vendor (LayerZero, Wormhole, Axelar, CCIP) has announced integration with the Naoris L1, and none publishes a Naoris-specific PQC roadmap. The 'Cross-Chain Trust Relay' the project once described is no longer served anywhere public. The identical-address $NAORIS deployment on Ethereum and BNB Smart Chain implies some bridge or deterministic deployment with no public documentation, and an announced Bitcoin-anchoring product has no specification or ship date. There is no observable bridge between the EVM token layer and the L1 - the L1 carries one non-zero-value transaction in its entire history. Worst-tier alongside custodian and infra; contributes to the supply-chain cap.

Custodian / exchange tile. No custodian (Anchorage, Fireblocks, Copper, BitGo, Komainu) has announced support for the NAORIS token or the Naoris L1, and none publishes a Naoris-specific post-quantum custody roadmap. The $NAORIS EVM token trades on centralized venues and carries an exchange-program listing, all of which is conventional ECDSA-secured EVM custody of an ERC-20 and none of which touches the L1. No custodian MPC path for ML-DSA is documented; ML-DSA is MPC-amenable in principle, but no custodian serving this asset has implemented one. Concentration on the token itself is extreme by the listing service's own indicator, with a large majority of supply in a few holders. Low score.

One RPC endpoint is published and it is operated by the project itself; no third-party RPC provider (Infura, Alchemy, QuickNode, Ankr) serves this chain, so there is no vendor to hold a post-quantum roadmap. No HSM vendor integration (Thales, YubiHSM, AWS KMS, Ledger Enterprise) and no TEE attestation chain (Intel TDX/SGX, AMD SEV-SNP, AWS Nitro) is documented for the L1, and the one infrastructure fact we can observe - the explorer fronted by a commercial cloud load balancer - is hosting, not a post-quantum supply-chain commitment. Cross-tile weak link: with wallet, bridge, custodian/exchange and infra all near-zero, 4 of 4 tiles lack a top-3 vendor post-quantum roadmap, firing the supply-chain cap (Migration Stage <= 3, non-binding because milestone discipline binds lower at 2).

The set is not merely undisclosed: it is measured, and it is very small. Exactly two addresses sealed every block across a ~300-block sample, giving an effective Nakamoto coefficient of 1, on a network with 9 distinct sending accounts in its entire history and a node reporting 7 peers. Validator identity, stake weighting, hardware configuration and onboarding criteria are unpublished; participation was announced as invite-only for strategic partners, investors and validator operators, and nothing indicates it has widened. Token-weighted influence over cryptographic parameters concentrates among large early holders per pre-launch funding coverage. Low score, evidence-backed rather than inferred from silence.

Unchanged. No coordinated protocol-upgrade record exists on the observable chain, which has run a single client build since its genesis, and no formal upgrade cadence, quorum, timelock or emergency mechanism is published. With zero public repositories, development cadence cannot be independently observed. Cadence under pressure is unproven. Low score reflects the absence of any track record, not a failure event.

The deduction rests on an attribution problem rather than on a gap in the people named. A full executive and advisory roster is published and verifiable - founder/CEO/chief scientist, chief strategy officer, CFO, co-founder/CBO, founding CTO, investor relations, plus a defence-weighted advisory board of retired senior officers and a family-office executive. Two qualifications. First, that roster is published by the entity whose own machine-readable site metadata states it has 'no affiliation, ownership, or relationship of any kind with Naoris Protocol, the Layer-1 blockchain', while a 2026-06-09 partnership release names the same founder as chief executive of that entity and every chain-related domain redirects to it. Until the corporate structure is disclosed, the named leadership cannot be cleanly attributed to the chain's governance, which is what this sub-score measures. Second, a cryptography figure is named: the chief strategy officer's published biography describes him as a cryptographer and former chief scientist at a major technology company. The substantive deduction stands on both counts: no officer is identified as the owner of the ML-DSA-87 implementation, no lattice-cryptography credential is stated for anyone, the founder holds both the CEO and chief-scientist titles with no separation of duties, and the advisory board is defence- and strategy-weighted with no stated post-quantum cryptography expertise - a governance gap for a chain whose whole thesis is one post-quantum primitive.

Unchanged. Building a hybrid signing path before any adversarial pressure exists is a positive structural signal and is credited modestly. But no cryptographic migration has been executed under live adversarial pressure, no incident-response plan is published for a post-quantum-algorithm-compromise scenario, and the one coordination event the evidence hints at - a genesis timestamped sixteen weeks after the announced launch - is undisclosed and therefore cannot be credited as demonstrated coordination. An actual adversarial-coordination test is absent and untested.

No canary, honeypot, rate-limited-spending rule, or cryptographic tripwire is documented in Naoris's consensus or governance materials, and none is observable in the chain surface. Scored 0 per rubric. Note that a tripwire would be most relevant precisely where none exists: on the classically-secured EVM token economic layer on Ethereum and BNB Smart Chain, which holds essentially all of the project's value, and on the classical-only transaction path that remains open on the L1 itself for accounts with no registered post-quantum key.