--- title: Is Mochimo quantum-safe? chain: Mochimo ticker: MCM hardy_score: 90 rank: 2 of 31 tier: "1: Native" url: "https://hardyindex.com/chains/mochimo" updated: 2026-08-15 reviewed: 2026-10-02 methodology_version: 1.4 --- # Is Mochimo quantum-safe? **Hardy Score 90.0 / 100. Rank 2 of 31. Tier 1: Native. As of 2 October 2026.** Sources last verified 2 October 2026; last substantive change 15 August 2026. Yes, on the signature question that this index measures. Mochimo launched in June 2018 with WOTS+, the Winternitz one-time signature scheme, as its signing algorithm, and it has never carried a classical alternative. We verified this in the node source rather than taking it from project material: src/wots.h and src/wots.c implement WOTS+ with a 32-byte parameter n and Winternitz parameter w of 16, citing RFC 8391, the specification that defines XMSS and the WOTS+ construction inside it. They are the only signature implementation in the repository. There is no ECDSA, secp256k1, Ed25519 or Schnorr source anywhere in the tree, which means post-quantum signing is not an opt-in mode on Mochimo but the only way a transaction can be made. WOTS+ security rests on hash functions rather than the discrete logarithm problem, so Shor's algorithm does not apply to it. The qualifier is on standards rather than on security: Mochimo uses WOTS+ standalone, and the NIST-approved hash-based schemes are the fuller constructions built on top of it. > This is a security-readiness assessment, not investment advice. ## Summary Mochimo has signed every mainnet transaction with hash-based WOTS+ since launching in June 2018, and its node source contains no elliptic-curve signature implementation at all. ## Where we are making a judgement call Two things about this row are worth stating plainly. First, our signature and deployment scores rest on our own reading of the node source rather than on a specification we could check them against, because Mochimo's wiki documentation was unreachable while we were writing. Reading the code is the stronger evidence for what is deployed, but it means the account tag mechanism described here is inferred from protocol source and test files rather than from a published spec. Second, we found no named third-party audit of the WOTS+ implementation. Mochimo scores highly here because of what it deployed and when, not because its implementation has been independently reviewed to the standard a large chain would face. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 10/10 | 30% | 30.0 | | 2 | Deployment stage | 10/10 | 25% | 25.0 | | 3 | NIST alignment | 7/10 | 15% | 10.5 | | 4 | Migration path | 8/10 | 15% | 12.0 | | 5 | Exposure | 9/10 | 10% | 9.0 | | 6 | Verification | 7/10 | 5% | 3.5 | | | **Hardy Score** | | | **90.0** | ### 1. Signature scheme: 10/10 Anchor band 10: A post-quantum signature is the mandatory scheme for all accounts on mainnet. WOTS+ is the mandatory scheme for every account on Mochimo mainnet, verified in the node source rather than from project claims. src/wots.h defines PARAMSN 32 and WOTSW 16 with a verbatim reference to RFC 8391, and the repository contains no ECDSA, secp256k1, Ed25519 or Schnorr implementation, so there is no classical path a transaction could take. Source: https://github.com/mochimodev/mochimo/blob/master/src/wots.h ### 2. Deployment stage: 10/10 Anchor band 10: Tier 1: Native. Tier 1: Native. Hash-based signatures have protected every unit of supply since the mainnet launched in June 2018, so there is no migration to run and no legacy cohort left behind. Source: https://github.com/mochimodev/mochimo ### 3. NIST alignment: 7/10 Anchor band 6 to 8: The scheme is NIST-selected but the standard is not yet final, or a NIST-approved scheme is named but not yet deployed. This is the one place Mochimo's position is weaker than it first looks, and the distinction is worth stating precisely. Mochimo implements WOTS+ exactly as RFC 8391 specifies it, and that same document underpins NIST SP 800-208. But SP 800-208 approves the fuller constructions, XMSS and LMS with their multi-tree variants, not the bare WOTS+ one-time signature used on its own. Mochimo is therefore using a standardised primitive in a way the standard does not itself cover, which is a long way from bespoke unreviewed cryptography and still short of a chain running an approved scheme. Placement in the band: A 7 rather than an 8 or a 6: Mochimo implements a standardised primitive, RFC 8391 WOTS+, but uses it bare where SP 800-208 approves only the fuller XMSS and LMS constructions. That is well clear of bespoke cryptography and still short of running an approved scheme. Source: https://csrc.nist.gov/pubs/sp/800/208/final ### 4. Migration path: 8/10 Anchor band 6 to 8: A credible published plan exists with a mechanism identified, but key parts are unbuilt or undated. There is no classical legacy to migrate, which removes the hardest problem facing every chain in this index that did not launch post-quantum. What replaces it is an operational one: WOTS+ keys are one-time, so a key that signs twice leaks enough material to forge, and that is a classical weakness rather than a quantum one. Mochimo addresses this at the protocol level with account tags, resolved to public keys and validated in the node source, which lets an account identity persist across the key rotation the scheme requires. Placement in the band: The top of the band because there is no classical legacy to migrate at all. It is not a 9 because the one-time key constraint imposes a permanent operational migration on every holder, which account tags manage rather than remove. Source: https://github.com/mochimodev/mochimo/blob/master/src/wots.h ### 5. Exposure: 9/10 Anchor band 9 to 10: No quantum-vulnerable public keys are exposed on-chain, or the exposed keys protect nothing. No Mochimo public key is a quantum liability, because WOTS+ security rests on the preimage and collision resistance of hash functions rather than on the discrete logarithm problem. A published WOTS+ public key gives a quantum adversary nothing Shor's algorithm can use, so the harvest-now-decrypt-later question that drives this dimension for every classical chain does not arise. Placement in the band: Not a perfect ten: the one-time constraint means key reuse rather than key exposure is the failure mode a holder must avoid, so the dimension is clean on quantum grounds but not on operational ones. Source: https://www.rfc-editor.org/rfc/rfc8391 ### 6. Verification: 7/10 Anchor band 6 to 8: Open source with public review or a named third-party audit of the relevant component. The claim is checkable in the strongest way available: the signature implementation is open source, the mainnet has run since 2018, and the absence of any classical signature code can be confirmed by reading the repository, which is how we scored the signature dimension. Placement in the band: A 7 rather than an 8: the code is open and the absence of classical signature code is directly checkable, which is strong public review, but no named third-party audit was found and the project's own wiki was unreachable at the time of writing. Source: https://github.com/mochimodev/mochimo ## Nearest chains in the ranking The chains Mochimo sits among, out of 31 rated. The last column is the gap in Hardy points from Mochimo. | Rank | Chain | Tier | Hardy | vs MCM | |---:|---|---|---:|---:| | 1 | [Quantum Resistant Ledger](https://hardyindex.com/chains/qrl) | 1: Native | 92.0 | +2.0 | | 2 | **Mochimo** | 1: Native | 90.0 | this chain | | 3 | [Abelian](https://hardyindex.com/chains/abelian) | 1: Native | 84.5 | -5.5 | | 4 | [NEAR Protocol](https://hardyindex.com/chains/near) | 2: Shipping | 81.5 | -8.5 | | 5 | [Algorand](https://hardyindex.com/chains/algorand) | 2: Shipping | 77.5 | -12.5 | | 6 | [Nervos CKB](https://hardyindex.com/chains/nervos-ckb) | 2: Shipping | 75.5 | -14.5 | | 7 | [Bitcoin Cash](https://hardyindex.com/chains/bitcoin-cash) | 2: Shipping | 66.0 | -24.0 | | 8 | [Solana](https://hardyindex.com/chains/solana) | 2: Shipping | 54.5 | -35.5 | | 9 | [XRP Ledger](https://hardyindex.com/chains/xrp-ledger) | 3: Committed | 46.5 | -43.5 | ## Signature scheme - **On mainnet today:** WOTS+ (Winternitz one-time signature), hash-based, with PARAMSN 32 and WOTSW 16 per RFC 8391 - **Post-quantum scheme:** WOTS+ itself. Mochimo has been post-quantum since genesis rather than adding a scheme later. - **NIST standard:** None directly. RFC 8391 defines WOTS+ and underpins NIST SP 800-208, but SP 800-208 approves XMSS and LMS rather than standalone WOTS+. - **Readiness tier:** Tier 1: Native. Post-quantum secure at mainnet today, with quantum-resistant signatures built in from genesis. ## Roadmap - **25 June 2018** (shipped): Mochimo mainnet launches with WOTS+ hash-based signatures as the only signing algorithm, making it one of the earliest live post-quantum layer 1s. Source: https://github.com/mochimodev/mochimo - **11 December 2018** (shipped): RFC 8391, which specifies the WOTS+ construction Mochimo implements, moves from draft to published RFC. The node source records the change in its header comments. Source: https://www.rfc-editor.org/rfc/rfc8391 - **October 2020** (shipped): NIST publishes SP 800-208, approving the XMSS and LMS hash-based constructions. Mochimo's standalone WOTS+ is not itself covered, which is what holds its NIST alignment below the top band. Source: https://csrc.nist.gov/pubs/sp/800/208/final ## Exposure Mochimo has no harvest-now-decrypt-later exposure in the sense this index usually means. That risk exists because a classical public key sitting on a chain today can be turned into a private key by a quantum computer later, and it applies wherever security rests on the discrete logarithm problem. WOTS+ does not: its security reduces to the hash function, and a published WOTS+ public key is not a route to the private key for any adversary, quantum or classical. The failure mode a Mochimo holder has to avoid is a different one, and it is not quantum at all. A Winternitz key is one-time, so signing twice with the same key leaks enough of the private material for anyone to forge a third signature. That is why the protocol carries account tags: an identity that persists while the key underneath it rotates. ## Frequently asked questions ### Is Mochimo quantum-safe? Yes, on the signature question that this index measures. Mochimo launched in June 2018 with WOTS+, the Winternitz one-time signature scheme, as its signing algorithm, and it has never carried a classical alternative. We verified this in the node source rather than taking it from project material: src/wots.h and src/wots.c implement WOTS+ with a 32-byte parameter n and Winternitz parameter w of 16, citing RFC 8391, the specification that defines XMSS and the WOTS+ construction inside it. They are the only signature implementation in the repository. There is no ECDSA, secp256k1, Ed25519 or Schnorr source anywhere in the tree, which means post-quantum signing is not an opt-in mode on Mochimo but the only way a transaction can be made. WOTS+ security rests on hash functions rather than the discrete logarithm problem, so Shor's algorithm does not apply to it. The qualifier is on standards rather than on security: Mochimo uses WOTS+ standalone, and the NIST-approved hash-based schemes are the fuller constructions built on top of it. ### Is Mochimo quantum-safe? On the measure this index applies, yes. Every Mochimo transaction is signed with WOTS+, a hash-based scheme whose security rests on hash functions rather than elliptic curves, so Shor's algorithm does not break it. We confirmed this by reading the node source: WOTS+ is the only signature implementation in the repository and there is no classical alternative for a transaction to use. ### How do you know Mochimo actually uses WOTS+ rather than just claiming to? We checked the source rather than the marketing. The files src/wots.h and src/wots.c in the official repository implement WOTS+ with a 32-byte hash parameter and a Winternitz parameter of 16, citing RFC 8391 in their header comments. Just as importantly, we searched the whole repository for ECDSA, secp256k1, Ed25519 and Schnorr implementations and found none, which is what makes post-quantum signing mandatory rather than optional here. ### Why does Mochimo score 7 on NIST alignment rather than 9 or 10? Because standalone WOTS+ is not itself an approved scheme. NIST SP 800-208 approves XMSS and LMS, the fuller constructions that use WOTS+ as their one-time signature component. Mochimo implements that component faithfully to RFC 8391 but uses it on its own, so it is applying a standardised primitive in a way the standard does not cover. That is much stronger than unreviewed bespoke cryptography and still short of running an approved scheme, which is what the 7 records. ### What is the catch with one-time signatures? A Winternitz key can safely sign once. Signing twice with the same key reveals enough of the private material that anyone, with no quantum computer required, could forge a further signature. This is a classical constraint rather than a quantum one, and it is why hash-based chains need a way to keep an account identity stable while the underlying key rotates. Mochimo does this with account tags at the protocol level. ## What this rating means if you hold Mochimo Plain-language guidance from the same publication, with no product recommendation attached. - [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md) - [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md) - [All guides](https://hardyindex.com/guides.md) Nothing on this profile is sponsored and nothing on it is an affiliate link. See https://hardyindex.com/how-we-make-money.md. ## What we have published about Mochimo - [A stale chain count was corrected, and news posts came under the claims guard on 19 August 2026](https://hardyindex.com/news/stale-chain-count-corrected-and-news-posts-brought-under-the-claims-guard.md): A post published on 19 August 2026 carried a count that had been true six days earlier, and nothing was checking it. Published 13 September 2026. - [Correction: four claims comparing one chain to the whole index were wrong](https://hardyindex.com/news/four-comparative-claims-corrected-across-four-chains.md): An audit found four sentences that ranked one chain against the rest of the index and had quietly stopped being true. Published 2 September 2026. - [Monero and Mochimo joined the index on 13 August 2026](https://hardyindex.com/news/monero-and-mochimo-join-the-index.md): Two rows added on 13 August for opposite reasons: one was the biggest gap we had left, the other signs with no elliptic curve at all. Published 19 August 2026. ## Sources 1. [Mochimo node source: src/wots.h](https://github.com/mochimodev/mochimo/blob/master/src/wots.h): Mochimo (primary, checked 13 August 2026) 2. [Mochimo node repository](https://github.com/mochimodev/mochimo): Mochimo (primary, checked 13 August 2026) 3. [RFC 8391: XMSS, eXtended Merkle Signature Scheme](https://www.rfc-editor.org/rfc/rfc8391): IETF (primary, checked 13 August 2026) 4. [NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes](https://csrc.nist.gov/pubs/sp/800/208/final): NIST (primary, checked 13 August 2026) ## How to cite this rating A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too. The Hardy Index (2026). Mochimo: quantum readiness assessment. Hardy Score 90.0 of 100, Tier 1: Native. Methodology v1.4. Reviewed 2 October 2026. https://hardyindex.com/chains/mochimo ```bibtex @misc{hardyindex_mochimo_2026, author = {{The Hardy Index}}, title = {Mochimo: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/mochimo}}, note = {Hardy Score 90.0 of 100, Tier 1: Native. Methodology v1.4}, urldate = {2026-10-02} } ``` --- Methodology: https://hardyindex.com/methodology (v1.4). Cite as: The Hardy Index, "Mochimo", https://hardyindex.com/chains/mochimo, as of 2 October 2026.