What it is. Mochimo is a small cryptocurrency that, unlike Bitcoin and almost every other coin, was designed from its very first day to stay safe once powerful quantum computers exist.
What we found. Coins held on Mochimo cannot be stolen by a future quantum computer, but two practical gaps remain: the computers running the network talk to each other in the open where anyone can read the traffic, and the whole system leans on a single protection method with no spare to fall back on if that one method is ever cracked.
Why it matters. Mochimo has already done the hard part that most chains have not even begun, yet it stays a niche project because hardly any wallets, exchanges, or bridges support it, so a holder gets strong protection with very little of the everyday infrastructure people expect.
Mochimo mainnet signs roughly all transactions under standalone WOTS+ (the Winternitz one-time building block of RFC 8391; SHA-256 core hash; n=32, w=16, 67-element chains; 2,144-byte signatures), a hash-based scheme Shor does not break, but this is standalone RFC 8391 WOTS+, not FIPS 205 SLH-DSA, which embeds WOTS+ only as an internal one-time component inside a stateless FORS-plus-hypertree that Mochimo does not ship, so one-time-key discipline (a spend-index counter) runs in wallet and SDK software, not at consensus. Migration Stage is held at 3 by the supply-chain cap (bridge, custodian, hardware-wallet, and RPC vendor tiles near-absent), and the chain ships no classical-plus-PQ hybrid signature (Gate 1a-Sig fails) and no post-quantum key exchange at its plaintext-TCP node transport (Gate 1a-KEM fails).
Summary
Mochimo scores QRI 46, Band 5, Migration Stage 3 (capped). Its live mainnet has signed roughly all transactions under standalone WOTS+ since the 2018 genesis block (RFC 8391 one-time building block; SHA-256 core hash; n=32, w=16, 67-element chains; 2,144-byte signatures), a hash-based primitive Shor does not break, so the mainnet-traffic cap does not fire. HNDL exposure is the strongest dimension: revealed public keys, cold balances, and historical signatures are all Shor-resistant, with no ECDSA or other elliptic-curve key in the account path. Three facts set the ceiling. It is pure post-quantum with no classical-plus-PQ hybrid signature, so Gate 1a-Sig fails. Node transport is plaintext TCP with no post-quantum key exchange, so Gate 1a-KEM fails. Bridge, custodian, hardware-wallet, and RPC tiles carry no post-quantum roadmap and several do not exist, firing the binding supply-chain cap that holds Stage at 3. The deployment cost is signature size: 2,144 bytes is 33.5x the 64-byte ECDSA or Ed25519 baseline, with no SNARK aggregation. Community content mislabels the scheme as FIPS 205 SLH-DSA, which only embeds WOTS+ as an internal component. The whitepaper reserves ML-DSA, SLH-DSA, and FN-DSA (FIPS 206, not finalized) as future slots, none implemented, so no second family and no hybrid.
What the gates say
- Gate 1a, Hybrid signature: FAIL , Mochimo is pure post-quantum by design: standalone WOTS+ (RFC 8391 one-time building block, SHA-256) is the sole deployed DSA on mainnet. No classical+PQ AND-composition (2-of-2) or OR-composition (1-of-2) exists - there is no classical scheme to compose with. The whitepaper names ML-DSA/SLH-DSA/FN-DSA as reserved future slots, but those are additional PQ schemes, not classical+PQ hybrids, and none is deployed or dated; no hybrid roadmap item was located. This is the canonical pure-PQ replacement that Gate 1a-Sig disqualifies, even though Mochimo arrives there via a PQ-native architecture from genesis rather than a plug-and-play swap. The TXDSA_TYPE byte (TXDSA_WOTS=0x00 only active value) is the technical enabler that could host a hybrid in future, but none is deployed. Consequence: QRI cap 60, Stage cap 4.
- Gate 1a, Hybrid KEM: FAIL , node-to-node P2P transport is plaintext TCP - PORT1 2095 is the default mainnet network port and PORT2 2096 is the secondary/testnet port per types.h - with no TLS/QUIC wrapper and no key-encapsulation in the node layer; block propagation, transaction relay and peer-list exchange (OP_HELLO/OP_TX/OP_FOUND/OP_GET_BLOCK/OP_SEND_IPL) are unencrypted. The Mochimo Mesh REST API optionally supports HTTPS (classical TLS via cert/key flags) but that is the API-facing layer, not node P2P. Either reading fails Gate 1a-KEM: no PQ KEM is deployed anywhere, and the optional API TLS is pure-classical with no PQ component or hybrid combiner.
- Gate 1b, Commit-to-hash: COND , no OR-composition / 1-of-2 hybrid declared; Mochimo is single-scheme PQ - WOTS+ only - at any layer
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts in 48h: mochimodev/mochimo source - wots.h, wots.c, types.h, network.h; mochimo.org whitepaper; GitHub CHANGELOG/releases; adequatesystems/mochimo-sdk README; NickP005/mochimo-mesh; mochiscan.org explorer; CoinMarketCap; RFC 8391; FIPS 205; NIST SP 800-208. Dims 6 and 7 are evidence-thin - exactly 3 artifacts each, with gaps - but still meet the >=3 threshold; the thinness widens the chain-level CI.
- Gate 3, Primitive naming: PASS , every primitive named exactly: WOTS+ per RFC 8391 (also RFC 8554-recognized per the whitepaper), SHA-256 core hash, n=32/w=16/WOTSLEN=67-chain parameters; Peach PoW (multi-hash memory-hard, eight rotating hash functions, haiku-encoded nonce - NOT single-SHA-256); explicit absence of BLS, ECDSA, Ed25519, lattice; FIPS 205 SLH-DSA and NIST SP 800-208 named in the conflict note; no abstract category used
Burn-vs-rescue policy on file
Declared option f, Undeclared (structurally low-relevance: no quantum-vulnerable legacy keys to freeze). Mochimo publishes no forward-looking quantum-defence freeze/rescue policy for legacy addresses - but the question is largely moot because there are no Shor-vulnerable (ECDSA/ECC) keys anywhere in its history: every address since the 2018-06-25 genesis block uses WOTS+ (hash-based, Shor-resistant), and the protocol moves residual funds to a fresh WOTS+ address on every spend. The one documented forced migration was the v3.0 hard fork (block 0xa0700, 2025-02-02), which moved holders from the legacy Mojo wallet / old address format to the new 40-byte Hash-based Ledger format ([20-byte account tag][20-byte SHA-256 hash of the WOTS+ public key]) via user-initiated import into the Chromium extension wallet - a format migration, not a quantum-defence policy. No equivalent forward-looking sunset, rate-limit, or canary for any address class has been published; on the framework's 5-option scale the chain is therefore Undeclared (f), with the caveat that the underlying threat the policy would address (forgeable legacy keys) does not exist on this chain.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 64 / 100
Mochimo publishes a precise, code-confirmed primitive inventory: standalone WOTS+ per RFC 8391 with SHA-256, parameters n=32 (PARAMSN) and w=16 (WOTSW), with the source-defined constants WOTSLEN1 = (8*PARAMSN/WOTSLOGW) = 64, WOTSLEN2 = 3, WOTSLEN = 67, WOTSSIGBYTES = WOTSLEN*PARAMSN = 2,144 (wots.h), and the matching types.h byte lengths WOTS_SIG_LEN and WOTS_PK_LEN each 2,144 bytes (= 67 SHA-256 chains x 32 bytes, the canonical len for n=32/w=16) and WOTS_ADDR_LEN 2,208 bytes, all verifiable in wots.h/wots.c/types.h, plus the Peach PoW (multi-hash memory-hard, see 1a entry) and the v3.0 SHA-256-based address-hash (DSA hash = SHA-256 of the WOTS+ public key). No elliptic-curve or lattice primitive exists anywhere in consensus or the account path. Small deduction (2): no second/successor DSA is implemented (the whitepaper names ML-DSA/SLH-DSA/FN-DSA only as reserved future slots), and community content mislabels the scheme as FIPS 205 (handled in 1e and PQC-washing).
WOTS+ (Winternitz One-Time Signature Plus, RFC 8391 one-time building block; SHA-256 core hash; PARAMSN=32 / n=32, WOTSW=16 / w=16; WOTS_SIG_LEN and WOTS_PK_LEN each 2,144 bytes and WOTS_ADDR_LEN 2,208 bytes as defined in types.h) - sole deployed DSA on Mochimo mainnet since 2018-06-25 · SHA-256 (core_hash inside every WOTS+ chain call; also the v3.0 address-hash function) · Peach PoW (custom 1 GiB memory-hard algorithm; per the whitepaper each of eight hashing rounds per map-tile uses a different hash function chosen from a set of eight, so it is NOT a single SHA-256 construction; GPU-oriented, ASIC/FPGA-resistant; the winning nonce is encoded as a tokenized 'haiku'; also referenced as 'Trigg's Algorithm' in third-party sources only) - consensus hashing, not a signing primitive · v3.0 address format = [20-byte account tag][20-byte DSA hash], where DSA hash = SHA-256 of the WOTS+ public key · TXDSA_TYPE byte with TXDSA_WOTS=0x00 the only active value (DSA-pluggable architecture, no second DSA deployed) The entire signing surface on mainnet is PQ-safe: WOTS+ is hash-based, so there is no Shor-breakable signature primitive at consensus or transaction layer. This is among the strongest 1b postures in the set. Deduction (3) reflects Grover-weakening of SHA-256 (down to ~128-bit, still adequate at deployed parameters) and the absence of any second PQ-safe family to hedge a future WOTS+/SHA-2 line cryptanalysis.
WOTS+ (RFC 8391)→ PQ-safe with Grover-caveat (hash-based one-time; security rests on SHA-256 preimage/2nd-preimage resistance; Shor does not break it)SHA-256 (WOTS+ core hash and address hash)→ Grover-weaken (256-bit -> ~128-bit preimage security)Peach PoW (multi-hash memory-hard, eight rotating hash functions per the whitepaper; not single-SHA-256)→ Grover-weaken (hash-based PoW; effective work halved under Grover; not a signing primitive)
Exactly one PQ family is DEPLOYED on mainnet: hash-based (standalone WOTS+ over SHA-256). Per the 1c rubric, '1 hash-only = 10'. No second family is deployed or scheduled: the whitepaper (section 2.3) names ML-DSA, SLH-DSA and FN-DSA as reserved future slots the architecture leaves room for, but none is implemented, dated, or registered behind the TXDSA_TYPE byte (TXDSA_WOTS=0x00 remains the only active value). Naming three reserved lattice/hash successors is a stated intention, not a diversity roadmap with a deployment path, so 1c credits only the single deployed family. The Diversity Cap targets LATTICE-monoculture specifically (hard-capped at 5); Mochimo's single deployed family is HASH-based, which the rubric treats as less fragile (10), so the literal cap does not fire - but the single-point-of-failure concern (no second family actually shipped) is real and noted in source-disagreement.
WOTS+ as deployed (SHA-256, n=32) targets a ~256-bit classical / ~128-bit post-Grover security level, aligned with NIST Category 1-2 equivalence for hash-based constructions, but standalone RFC 8391 WOTS+ is NOT itself a NIST-categorized PQC signature standard (FIPS 205 SLH-DSA is the NIST-standardized scheme that embeds WOTS+; NIST SP 800-208 covers XMSS/LMS, not standalone WOTS+). No NIST-PQC-categorized signature (ML-DSA, SLH-DSA, FN-DSA) is deployed. Mid-range score: the deployed primitive is a sound, well-parameterized hash-based scheme with a clear security level, but its NIST status is 'building block standardized inside FIPS 205', not 'this exact scheme is a finalized FIPS standard'.
Library provenance: the WOTS+ implementation derives from the published XMSS reference implementation, in production C since 2018 (wots.h/wots.c, mochimodev/mochimo). An external 'F-series' audit (auditor not named publicly) produced 21 correctness fixes (variability-induced failures, data races, error handling, locale/platform determinism in consensus-critical and network paths) merged into v3.1.0-beta (2026-04-18). Deductions: (a) the audit firm is unnamed in official release notes, weakening third-party verifiability; (b) a 2018-03-05 WOTS+ review attributed to an XMSS/WOTS+ co-author is cited only in community marketing content, predates RFC 8391 publication, and is not in official documentation - so it is not credited as a current formal verification; (c) no machine-checked formal verification (Formosa/EasyCrypt-class) or independent public constant-time validation is cited for Mochimo's specific implementation; (d) standalone WOTS+ requires external one-time-key state discipline, with no stateless-hypertree (SLH-DSA) management - cross-referenced to 4e; (e) cryptanalytic maturity is Tier 1-2 for SHA-256 but the standalone-WOTS+ deployment pattern is less battle-tested than a NIST-standardized full scheme.
2 Quantum Recovery Exposure weight 10% 67 / 100
Forge. Mochimo addresses are WOTS+ (hash-based). Spending an address reveals its WOTS+ public key, but revealing a hash-based public key does NOT enable Shor-based key recovery, so the active-key forge risk that dominates ECDSA/Ed25519 chains is structurally absent. The protocol enforces one-time use by automatically moving residual funds to a fresh WOTS+ change address on every spend. Deduction (4): WOTS+ is a one-time scheme, so reuse of a spend index (the wallet/SDK counter) lets the same key sign twice and degrades security to existential-forgery risk; the mochimo-sdk explicitly warns 'Never reuse a spend index', confirming this is a managed wallet-side risk rather than a protocol-enforced impossibility.
Forge. Dormant/cold MCM balances sit on WOTS+ addresses, which are Shor-resistant by construction; there is no Bitcoin-style lost-P2PK or dormant-Ed25519 exposure because every address since the 2018-06-25 genesis uses WOTS+ and zero ECDSA/ECC keys exist in the account path. This is among the strongest cold-key postures in the set. Minor deduction (3) for the theoretical reuse-degradation path on any cold address whose WOTS+ key was already revealed by a prior spend.
Forge. Historical Mochimo transaction signatures are WOTS+ (hash-based) and remain unforgeable post-Shor; signed transactions retain validity without exposing forgeable elliptic-curve keys. Deduction (5): the SHA-256 internal hash is Grover-weakened (to ~128-bit), trimming very-long-horizon margins, and there is no second family to fall back on if the WOTS+/SHA-2 line is ever cryptanalyzed; the one-time model also means a mismanaged/re-signed key is the residual long-term-validity surface.
Decrypt (HNDL). Node-to-node P2P transport is plaintext TCP (PORT1 2095 mainnet; PORT2 2096 secondary/testnet, per types.h) with no key-encapsulation at all; the optional Mesh REST API HTTPS is classical TLS. Harvested transport is therefore readable today (no encryption to decrypt later on the P2P layer) and harvested API-TLS would be decryptable once Shor breaks the classical key exchange. The mitigating factor is that on-chain transactions carry WOTS+ signatures, not private-key or encrypted-payload material, so transport HNDL exposes only metadata (sender/receiver tags, amounts, timestamps) that is already public on-chain. No hybrid PQ KEM is documented anywhere. Score near the set floor: there is essentially no confidentiality posture, partially offset because there is little confidential content to harvest.
3 Metadata, Anonymity & Confidentiality weight 13% 20 / 100
Anonymity. Mochimo is a transparent, pseudonymous ledger: the MochimoScan explorer (mochiscan.org) shows all transaction data - source account tag (20 bytes), up to 256 destination tags per v3.0, amounts, references, block linkage. No native shielding, ring signatures, zk-proofs, or Pedersen commitments are described in any official documentation. Comparable to Bitcoin/Ethereum transparency.
Anonymity. Mochimo does not depend on Infura/Alchemy-class oligopoly RPC providers; it is a small independent PoW network with a randomized peer list (RPLISTLEN=64, TPLISTLEN=32 trusted peers) and peer discovery via OP_GET_IPL/OP_SEND_IPL. Top-3 RPC concentration is structurally low by isolation, but exact node shares are unpublished (no public dashboard; MAXNODES=37 is a per-node connection limit, not a network count), and there is no declared validator/node metadata-retention policy (zero credit on that component, per the rubric's 'zero if policy undeclared'). The single official Mesh API endpoint (api.mochimo.org) is a concentration point for REST consumers. Mempool/transaction gossip is openly observable.
Anonymity. Mochimo is a standalone L1 with its own native coin (not an ERC-20) and no documented cross-chain bridge or interoperability layer; it is absent from LayerZero/Wormhole/Axelar/CCIP. The cross-chain correlation surface is therefore small (low bridge-linkability exposure), scored moderately as low-exposure-by-isolation rather than deliberate privacy engineering. Liquidity reaches other chains only via centralized exchanges (CoinMarketCap presence implies at least one listing; no specific exchange verified from primary sources), which are fully correlating.
Confidentiality. Mochimo has no discrete-log/EC privacy primitives (no ElGamal ring signatures, no EC zk-SNARKs, no shielded notes), so Shor does NOT retroactively de-anonymize Mochimo history at the cryptographic layer - but this is because there is no confidentiality layer to break in the first place, not because content is protected. The ledger is fully transparent and the persistent 20-byte account tag (a stable deposit identifier exchanges are told to reuse) is a long-lived linkable identifier that enables straightforward chain-analysis correlation of all inbound transactions to one entity. Low score: no positive confidentiality, and the persistent tag actively aids correlation; the partial credit reflects only the absence of Shor-breakable privacy crypto to retroactively unwind. No structural-impossibility statement (single validator / RPC provider / observer capabilities) is published, capping 3a-3d credit.
Anonymity. No on-chain mixer, no commit-reveal, no cMix/mixnet infrastructure, no batch-ordering, no dandelion++/onion routing (the codebase and docs describe none). The automatic change-address mechanism sends residual funds to a fresh WOTS+ key, a minor output-side unlinkability benefit, but it is not a mixing mechanism and is counteracted on the receive side by the persistent account tag. No structural anonymity-set mechanism exists.
4 Migration Architecture weight 10% 49 / 100
The architecture carries a TXDSA_TYPE byte in transaction options (TXDSA_WOTS=0x00 the only active value), and the v3.0.0 CHANGELOG (2025-02-02) states the upgrade enables 'easy implementation of additional Digital Signature Algorithms'. The v3.1.0-beta F-13 fix hardened this: tx__init now rejects unsupported TXDAT_TYPE/TXDSA_TYPE values rather than leaving buffer offsets uninitialized. So a second DSA could in principle be registered behind the type byte. Deductions (6): no second DSA has actually been added through this mechanism (no verifiable in-production instance of an algorithm switch via the type byte), and adding one in practice has required protocol-breaking hard forks historically, so the agility is architectural-intent plus a type-byte hook rather than a demonstrated hot-swap.
Mochimo has no smart-contract / account-abstraction framework (no ERC-4337, no EIP-7702, no native AA VM) - it is a UTXO-style PoW value-transfer chain. 'Key rotation' is effectively automatic at the protocol level: WOTS+ is one-time, so every spend rotates funds to a fresh WOTS+ change address, and the v3.0 persistent account tag provides a stable receive identity decoupled from the rotating signing keys. There is no deployed client-layer PQC-migration path of the Solana-Winternitz-Vault / EIP-7702 kind because there is no classical scheme to migrate FROM - the chain is PQ-native. Score below AA-only baseline because the dimension rewards AA + documented/deployed client-layer migration primitives that Mochimo's minimal architecture does not provide; partial credit for protocol-level one-time-key rotation and tag-based receive stability.
Strong, demonstrated hard-fork capability: documented protocol-breaking forks at v2.0 (block 0x4321), v2.0.1 (0x4521), v2.3 (0xd431, pseudoblocks), v2.4 (0x12851, FPGA-Tough PoW), and v3.0 (block 0xa0700 = V30TRIGGER, 2025-02-02, 'NEOGEN ONLY' reboot introducing the Hash-based Ledger format, Base58 addresses, variable-length PDUs). At least five protocol-level hard forks executed since 2018, with no contested-fork/chain-split documented. Deduction (3): forks are coordinated by Adequate Systems LLC via hardcoded trigger blocks with node-operator opt-in, not via a formal multi-stakeholder governance process, so coordination is centralized.
Mochimo is explicitly PURE post-quantum and cannot ship a classical+PQ hybrid composition because it has no classical scheme to compose with, and no hybrid (AND- or OR-composition) is deployed or publicly proposed. Under the v3.1 'hybrid mandatory' framing this scores low - not because Mochimo is unprepared, but because the dimension rewards classical+PQ co-signing, which Mochimo by design does not do. The TXDSA_TYPE byte is the only technical enabler that could host a hybrid in future. Tension noted: Mochimo is penalized here precisely for being PQ-native rather than mid-hybrid-transition.
Mochimo deploys a hash-based one-time scheme (standalone WOTS+) at the transaction layer, so this sub-score is in scope. One-time-key discipline is managed by a wallet/SDK-side 'spend index' counter that must increment after each withdrawal to derive a fresh key from the master seed; the mochimo-sdk README explicitly warns 'Never reuse a spend index'. The protocol moves residual funds to a fresh change address on each spend. Deductions: there is NO protocol-/consensus-level state-reuse rejection (unlike a chain whose nodes reject any transaction reusing a one-time-signature index during block validation) - exhaustion/reuse discipline is delegated entirely to wallet software, with no on-chain exhaustion tracker, no documented backup-restore-without-state-rewind procedure, and no multi-device state-sync protocol. Standalone WOTS+ (vs a stateless hypertree like SLH-DSA) makes this discipline mandatory, so the wallet-only enforcement is a genuine weakness. Scored at the rubric's 'spec exists but enforcement application-level' tier (8) and trimmed to 7 because the spec is an exchange-integration warning rather than a formal state-management specification. This also blocks the Stage-5 90-day-state-record prerequisite.
N/A. Mochimo uses Nakamoto-style Proof-of-Work (Peach, a multi-hash memory-hard algorithm; haiku-encoded nonce) - block production is hashing, not signature aggregation, and there is no BLS/threshold signature aggregation at consensus (no PoS/BFT validator set). The 4f concern (a Shor-breakable signature-aggregation path at consensus) does not apply, so the 20-point 4f weight redistributes across 4a-4e. Dimension score = (9+8+12+3+7)/80 * 100 = 48.75 -> 49 (rounded to the nearest integer after redistribution).
5 Deployment Execution weight 22% 73 / 100
Mochimo mainnet (live since the 2018-06-25 genesis block) signs ~100% of transactions under WOTS+, a PQ-safe hash-based primitive; TXDSA_WOTS (0x00) is the only active transaction DSA type and no classical (ECDSA/Ed25519) transactions exist anywhere in the state. The 5a rubric measures '% of mainnet signing traffic on PQC primitives (hybrid or pure)' - Mochimo is ~100% pure-PQ. The Mainnet-Traffic cap therefore does NOT fire. One-point deduction: throughput is modest and network-size data is unpublished, but the signing-primitive coverage on the live chain is effectively complete.
WOTS+ signature verification is fully merged and in production in the Mochimo core node (mochimodev/mochimo, C/CUDA; wots.h/wots.c), running on live mainnet - this is shipped consensus-client PQC code, not testnet-only. The same WOTS+ implementation ships in the Chromium extension wallet and the adequatesystems/mochimo-sdk Node.js library. Near-full credit because PQC signing code runs in a LIVE mainnet node today; one-point deduction because the headline correctness hardening (the F-series fixes) currently sits in a v3.1.0-beta pre-release explicitly 'not for mainnet without testing', so the latest patched build is not yet the production mainnet build (mainnet runs v3.0.3).
Mochimo consensus is PoW (Peach, multi-hash memory-hard), so block production is hashing, not validator signing - there are no 'validator PQC signing keys' to adopt at consensus. However ~100% of USER transaction signing on the live chain uses WOTS+ (PQ), which is the relevant adoption surface for a PoW value-transfer chain. Scored above mid-range: full user-signing-key PQ adoption on the live mainnet, with the deduction reflecting that there is no validator-signing layer where PQ keys could be further demonstrated and that exact wallet/SDK adoption shares are unpublished.
NOT voided (5a > 0, so the v3.1 5a-zero void does not apply). Mochimo publishes named, dated, verifiable milestones backed by shipped artifacts: v3.0.0 hard fork (block 0xa0700, 2025-02-02), v3.0.1 (2025-02-10), v3.0.2 (2025-02-11), v3.0.3 mainnet stable (2025-03-06), and v3.1.0-beta with the F-series audit remediations (2026-04-18). Deductions (4): the milestones are release/patch dates and a past hard fork rather than protocol-enforced FORWARD-looking flag-day commitments (e.g. a dated consensus sunset or a dated next-DSA activation), there is no improvement-proposal system binding future milestones, and no dated roadmap item for hybrid composition, a PQ KEM at transport, or a second cryptographic family was located - the discipline is real but backward-looking.
Announced ~= shipped on the core claim: Mochimo has signed real on-chain transactions under a PQ-safe primitive (WOTS+) continuously since 2018, so its quantum-resistance claim is backed by deployed, block-explorer-verifiable signatures (mochiscan.org) - the inverse of narrative-only chains; ratio ~1.25, below the 1.5 deduction threshold. Deduction (3) for two precision/overclaim issues: (a) community content (Medium/LinkedIn) mislabels standalone WOTS+ as 'standardized as FIPS 205', when FIPS 205 (SLH-DSA) only embeds WOTS+ as an internal component; (b) the '100% quantum-resistant' framing ignores the plaintext-TCP transport and classical API-TLS. These are overclaims in marketing surfaces, not fabricated deployment, so no QRI cap or narrative-only tag is triggered.
Deployment weakness. WOTS+ signatures are 2,144 bytes (WOTS_SIG_LEN = WOTS_PK_LEN = 2,144 per types.h; full address WOTS_ADDR_LEN 2,208 bytes), roughly 33.5x the 64-byte ECDSA/Ed25519 baseline - which places it squarely in the rubric's 10-38x band (= 5 points) - and Mochimo deploys NO SNARK aggregation, data-availability offloading, or batching to bring the effective per-block multiplier down. The ChainCrunch snapshot/pruning mechanism reduces stored historical block data (full node ~50-100 MB) but does not shrink per-signature size. No user-laggard / per-quarter migration-decay reporting (not applicable to a PQ-native chain). Scored 5/20 at the 10-38x band value: the footprint is fully disclosed in source and is the honest cost of strong hash-based PQ security, but the raw bytes-per-signature sit at the heavy end of the multiplier scale with no aggregation mitigation.
6 Supply Chain Vendor Readiness weight 22% 14 / 100
Mochimo's first-party wallets are PQ-native by construction: the official Chromium extension wallet (Chrome Web Store, extension ID fkogefgjocnflhankmffnibdofdiiiho, live since February 2025) and the adequatesystems/mochimo-sdk Node.js library both sign with WOTS+ today, and the deprecated legacy Mojo wallet was migrated into the extension at the v3.0 fork. Scored above the set norm because the primary wallet IS quantum-safe rather than carrying a 'PQC roadmap'. Deductions: NO hardware-wallet (Ledger/Trezor) support is documented - the ~2,208-byte WOTS+ address size creates real hardware-integration friction - the third-party wallet ecosystem is thin (no MetaMask/Phantom-class support, which is expected since MCM is not EVM), and there is no published vendor PQC-roadmap document.
No cross-chain bridge for Mochimo was found in any official or third-party source - it is a standalone L1 with its own native coin and no documented interoperability layer, and it is absent from LayerZero/Wormhole/Axelar/CCIP. Consequently no bridge vendor publishes a Mochimo-specific PQC roadmap (there is no bridge to have one). Near-zero score, recorded as low-by-absence; this is one of the tiles that fires the Supply-Chain cap. (Cross-chain movement happens only via centralized exchanges, which are classical.)
No institutional custodian for Mochimo was found in primary sources - it is not documented as supported by Fireblocks/BitGo/Anchorage/and none publish a Mochimo-specific PQ custody roadmap. The mochimo-sdk provides an exchange-integration kit (EXCHANGE_INTEGRATION.md: master-seed storage, spend-index management, deposit-address generation, withdrawal processing) and CoinMarketCap presence implies at least one exchange listing, but no specific exchange name was verified from primary sources in this evaluation and no custodian-MPC path for WOTS+ is documented. Note: standalone WOTS+ (one-time, large signatures) is poorly suited to threshold-MPC custody. Near-zero score; another tile firing the Supply-Chain cap.
RPC/API is served by community/first-party nodes plus the single official Mochimo Mesh API endpoint (api.mochimo.org, NickP005/mochimo-mesh v1.5.1, Rosetta-standard REST); none publishes a PQC roadmap (the node signing layer is already WOTS+, but transport is plaintext TCP and the optional API TLS is classical). No HSM support is documented and no hardware-wallet integration exists (the ~2,208-byte WOTS+ address size is a known obstacle). No TEE attestation chains are in Mochimo's path (PoW, no enclave-based sequencing/MEV). Near-zero score: the infra runs PQ signing but the third-party infra vendors carry no Mochimo-specific PQC roadmap commitments and the transport layer is unencrypted. Cross-tile weak-link: with bridge, custodian and infra all near-zero, the dimension is capped by its weakest tiles - this is what fires the Supply-Chain cap (>=3 of 4 tiles lack top-3 vendor PQC roadmaps -> Migration Stage <= 3). Evidence for this dimension is thin (3 artifacts, with gaps: no named exchange from a primary source, no HSM), widening the chain-level CI.
7 Governance & Coordination weight 8% 38 / 100
Mochimo uses Peach PoW (multi-hash memory-hard, GPU-oriented, ASIC-resistant, FPGA-Tough since v2.4; haiku-encoded nonce), so there is no validator/stake set - decentralization is a function of independent mining nodes. The number of independent mainnet nodes is NOT publicly quantified (MAXNODES=37 is a per-node peer-connection limit, not a network-wide count, and there is no bitnodes.io-style monitoring dashboard). Modest, undocumented decentralization: a small network with no published Nakamoto coefficient or hashrate-distribution data. Low-to-mid score reflecting unquantified concentration.
Demonstrated upgrade cadence: at least five coordinated protocol hard forks since 2018 (v2.0/v2.0.1/v2.3/v2.4/v3.0) plus rapid post-fork patching (v3.0.1, v3.0.2, v3.0.3 within weeks of the v3.0 reboot), with no contested fork/chain-split documented. Deduction: forks are activated by hardcoded trigger blocks with node-operator opt-in coordinated by a single entity (Adequate Systems LLC) rather than a multi-stakeholder process, and none of these upgrades was executed under live adversarial/time pressure - they were planned protocol upgrades, so cadence-under-pressure is partly unproven.
Clear named coordination entity: Adequate Systems LLC (copyright holder on all source files 2018-2024; mochimo.org describes MCM as 'powered by the Mochimo Cryptocurrency Engine, the flagship product of Adequate Systems, LLC'), with the mochimodev GitHub organization and named active contributors visible in release signing keys (chrisdigity, adequatelimited); the Mochimo Mesh API is maintained by community contributor NickP005. Deductions: there is no named PQC working-group lead or published PQC migration mandate beyond the entity itself, and coordination is centralized to a single LLC with no published succession or multi-party governance - a concentration/key-person risk for a chain-wide crypto migration.
Mochimo's entire thesis is proactive PQ defence (PQ-native from genesis via WOTS+), a positive structural signal, and it has shipped multiple coordinated hard forks - but it has NOT executed a cryptographic migration under live adversarial pressure (no attack-driven emergency fork is documented), and the v2.4 'FPGA-Tough' PoW change is a mining-centralization response rather than a signature-scheme migration under threat. The proactive posture is credited modestly; a true adversarial-coordination test (migrating a primitive while an attacker is actively threatening) is absent.
No canary, honeypot, rate-limited-spending rule, or cryptographic tripwire is documented in Mochimo's consensus or governance, and no stated 'if quantum capability reaches X, we will do Y within Z' commitment was found. Scored 0 per rubric (no mechanism documented), with the note that the dimension is less relevant to a PQ-native chain whose signature layer is already Shor-resistant. Evidence for this dimension is thin (3 artifacts, with gaps: no governance-process document, no network-size data), widening the chain-level CI.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X + Y does NOT exceed Z for Mochimo's signature layer - it is among the rare chains already inside the risk window for value protection, because the forge threat is structurally mitigated by hash-based one-time signing from genesis. Residual risk concentrates on (a) plaintext P2P transport / no PQ KEM (HNDL on metadata only, since transactions carry WOTS+ signatures, not private-key material), (b) wallet-side-only enforcement of one-time-key discipline, and (c) the absence of any classical+PQ hybrid or second-family diversity.
Z-compliance
Inside the compliance window for the dominant value-protection (signature) threat: WOTS+ is a NIST-recognized hash-based construction (RFC 8391; the same WOTS+ building block standardized inside FIPS 205, and the XMSS/LMS family covered by NIST SP 800-208), so the signature layer is not exposed to the NIST IR 8547 2030/2035 disallowance of quantum-vulnerable public keys the way ECDSA/Ed25519 chains are. The open compliance items are the transport/KEM layer (plaintext P2P, classical-only API TLS, no hybrid PQ KEM) and the absence of the CNSA-2.0-style hybrid-transition posture.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Community content (a Mochimo-official Medium article by a community contributor, and other Medium/LinkedIn posts) asserts that Mochimo's WOTS+ is 'standardized as FIPS 205 by NIST'. That framing is technically adjacent (WOTS+ is indeed a building block of SLH-DSA) but imprecise, and invites the reading that Mochimo deploys FIPS 205. Primary sources (Mochimo source code wots.h/wots.c, the whitepaper, RFC 8391, and FIPS 205 itself) show what is actually deployed: FIPS 205 specifies SLH-DSA, which is stateless and uses WOTS+ only as an internal one-time-signature component inside a FORS-plus-hypertree structure. Mochimo implements standalone RFC 8391 WOTS+ without that Merkle/hypertree layer, so it is a correct post-quantum primitive but NOT the full SLH-DSA/FIPS 205 scheme. The Mochimo whitepaper itself correctly frames the scheme as RFC 8391-aligned, not FIPS 205. The security consequence is concrete: SLH-DSA is stateless (the tree manages key generation) whereas Mochimo's standalone WOTS+ requires external one-time-key discipline (spend-index management in wallet/SDK software). NIST SP 800-208 covers XMSS/LMS stateful hash-based signatures, not standalone WOTS+. This evaluation follows the primary code/spec evidence (standalone RFC 8391 WOTS+), and the mislabel is reflected in the Dim 5 PQC-washing sub-score and Dim 1e.
CoinMarketCap and community materials describe Mochimo as '100% quantum-resistant'. This is accurate for the on-chain signature scheme (WOTS+ is hash-based and Shor-resistant) but conflates signature-layer resistance with whole-stack resistance: node-to-node P2P transport is plaintext TCP with no PQ KEM, and the optional API-layer TLS is classical. The framework scores these separately - strong on Dim 1/Dim 2 signature posture, but Gate 1a-KEM fails and Dim 2 2d (transport HNDL) is low. The single-family concern (hash-only monoculture, no second cryptographic family deployed or announced) is also noted: unlike a chain that pairs hash-based with a lattice successor, Mochimo has one family, so a future cryptanalytic break of the WOTS+/SHA-256 line would have no in-protocol fallback. The Cryptographic-Diversity Cap targets lattice-monoculture specifically and does not fire on a hash-based monoculture, but the single-point-of-failure observation stands.
No public source quantifies the number of independent Mochimo mainnet nodes. MAXNODES=37 in types.h is a per-node maximum simultaneous peer-connection limit, not a network-wide node count, and there is no public monitoring dashboard analogous to bitnodes.io. Governance is centralized to Adequate Systems LLC (the copyright holder and core maintainer) with node-operator opt-in via hardcoded hard-fork trigger blocks (V20TRIGGER through V30TRIGGER); there is no improvement-proposal system or on-chain governance. These gaps drive the Dim 7 scores down and widen the CI, and they are honestly recorded rather than inferred.
Earlier evaluation drafts and some third-party descriptions call Peach a 'SHA-256-based' proof-of-work. The whitepaper (section 5.1) is more specific: Peach builds a fresh ~1 GiB memory map (1,048,576 tiles x 1,024 bytes) per block, and each tile is built with eight rounds of hashing where each round uses a different hash function chosen from a set of eight, interleaved with floating-point and memory-shuffle operations; the winning nonce is encoded as a tokenized 'haiku'. Peach is therefore a multi-hash memory-hard algorithm, not a single-SHA-256 construction. The block-difficulty target is still hash-based and Grover-weakened like any PoW, so this correction does not change the 1b tag (Grover-weaken) or any sub-score; it is a primitive-naming precision fix. 'Haiku' is the nonce-encoding format, not a separate hashing primitive, and 'Trigg's Algorithm' is a third-party label not used in primary Mochimo materials.
The whitepaper (section 2.3) explicitly reserves protocol space for three additional NIST PQC signature systems - ML-DSA (FIPS 204), SLH-DSA (FIPS 205) and FN-DSA (FIPS 206, NOT finalized as of mid-2026) - to be addable behind the TXDSA_TYPE byte 'when those standards are finalized'. This is a stated future intention, not a deployed or dated diversity plan: TXDSA_WOTS=0x00 remains the only active DSA type, no second scheme is implemented or scheduled, and adding one has historically required a protocol-breaking hard fork. The evaluation credits only the single deployed hash-based family in Dim 1c and treats the reserved slots as crypto-agility intent (Dim 4a), not as a shipped second family. The whitepaper also recognizes WOTS+ under both RFC 8391 and RFC 8554, and it dates itself 'Version 3.0 - April 2026'.
Delta-QRI under alternative weighting
Under an alternative weighting that down-weights Deployment (Dim 5) and up-weights Supply Chain (Dim 6) - the dimensions where Mochimo is respectively strongest and weakest - Mochimo's QRI would fall. For example Dim 5 at 12% and Dim 6 at 32%: QRI ~= 40 (Band 4-5). Conversely a weighting that credited shipped-mainnet-PQC more heavily (Dim 5 -> 30%, Dim 6 -> 14%) lifts QRI to ~52 (top of Band 5 / low Band 6). Like other PQ-native chains, Mochimo is unusually sensitive to the Deployment-vs-Supply-Chain weight split because it is an outlier on both axes: real shipped PQ signing, near-absent external vendor ecosystem.
Announcement-to-shipped ratio
Announced: 5. Shipped: 4. Ratio: 1.25.
Tag: none, ratio <= 1.5; Mochimo has signed real mainnet transactions under a PQ-safe primitive (WOTS+) continuously since 2018, so its core quantum-resistance claim is backed by deployed, on-chain-verifiable signatures. One precision issue is flagged: community content (a Mochimo-official Medium article, plus other Medium/LinkedIn posts) asserts that Mochimo's WOTS+ is 'standardized as FIPS 205 by NIST'. This is imprecise: FIPS 205 (SLH-DSA, finalized 2024-08-13) uses WOTS+ only as an internal one-time component inside a FORS-plus-hypertree, while Mochimo implements standalone RFC 8391 WOTS+ without that hypertree layer - a correct post-quantum primitive but not the full stateless SLH-DSA scheme. The Mochimo whitepaper itself frames the scheme as RFC 8391-aligned, not FIPS 205, so this is a marketing-surface overclaim rather than a protocol fabrication. The '100% quantum-resistant' framing (CoinMarketCap description) is likewise accurate for on-chain signatures but ignores the plaintext-TCP transport layer. These are precision/overclaim issues, not narrative-only fabrication; net announced-vs-shipped ratio stays at or below 1.5.
Peers in the L1 profile
9 chains closest to Mochimo by Stage then QRI.