Post-quantum PoW chain

Mochimo MCM

Mochimo is a PQ-native proof-of-work chain whose native asset has used mandatory WOTS+ authorization since genesis. Its specification, public production code, and mainnet explorer support complete-by-design native ownership coverage, with no evidenced classical native ownership namespace or legacy native migration pool. No current quantum-vulnerable native spend path was identified. The production assessment remains Medium confidence because no usable canonical independent audit was supplied and the evidence does not comprehensively verify every state-integrity, supply-binding, signing-control, and external-dependency property.

PQ-NativePQ-ResistantPoWWOTS+
Stage Migration Complete / Quantum-Ready
Confidence Medium
Urgency [Monitor for Updates]
Review Status Draft
Evaluated 2026-08-20
Scope Native MCM asset and base protocol on Mochimo proof-of-work mainnet as of 2026-08-20, including spend authorization, account and public-key exposure, consensus, state integrity, P2P, and native wallet paths. Excludes the v4.0 proof-of-stake testnet and any third-party wrapped or bridged MCM representations not established by canonical evidence.
AI-generated report. This report was produced by the evaluator and synthesis pipeline. Review status: draft.

Category breakdown

QRI Factors

Algorithm & Implementation Assurance 12.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination 13.5 / 15
Migration Status & Value-at-Risk 25 / 25
Production Cryptographic Protection 30.96 / 35
Security Assessment & Evidence Preparedness 5 / 5

Critical Quantum Blockers

  • The canonical record does not fully verify all current production state-integrity and supply-binding properties sufficiently to exclude every quantum-relevant critical-state failure mode.

Key Risks

  • Incomplete canonical documentation of production state-integrity and supply-binding mechanisms prevents exclusion of every quantum-relevant critical-state failure mode.
  • WOTS+ safety depends on correct one-time signing-state discipline; anti-reuse, serialization, randomness, side-channel, fault-injection, HSM, and custody controls are not comprehensively verified in the supplied record.
  • Any external wrapped or bridged MCM representation could introduce classical ownership or bridge-signing risk and is outside this native-mainnet assessment.
  • The future proof-of-stake transition would introduce new consensus-authentication requirements and must be reassessed if deployed to mainnet.

Assurance Notes

  • Canonical specification, production source code, and mainnet explorer evidence support mandatory WOTS+ authorization since genesis and the absence of a classical native ownership namespace.
  • The dossier mentions a 2018 independent review, but its primary artifact was excluded during evidence ingestion. Audit existence, scope, findings, and remediation therefore cannot be treated as canonically verified; overall audit freshness is reported as absent.
  • The current production state-integrity and supply-binding mechanisms are not comprehensively documented in the supplied evidence beyond transaction validation and neogenesis snapshots, leaving a bounded quantum-critical verification gap.
  • The implementation status of historically reported recommendations concerning serialization and pseudorandom-value handling is not verifiable from the canonical record.
  • No formal performance/resource study, reproducible-build attestation, or comprehensive analysis of WOTS+ signing-state, side-channel, fault-injection, HSM, and hardware-wallet controls was supplied. These are assurance gaps, not identified quantum-vulnerable paths.
  • The future v4.0 proof-of-stake transition is outside the evaluated production scope and does not reduce current readiness; it requires reassessment if activated.
  • No canonical evidence establishes an external bridge or wrapped MCM representation. Such systems, if any, require separate evaluation.

Non-Scoring Caveats

  • No usable canonical independent-audit artifact covers the current production implementation.
  • The reported 2018 review and remediation status cannot be cited or verified from the supplied canonical sources.
  • Formal WOTS+ performance, resource, side-channel, fault-injection, reproducible-build, HSM, and hardware-wallet analyses were not supplied.
  • No formal quantum-specific emergency disclosure or incident-response process was supplied.
  • P2P transport details are thinly documented; this is non-scoring so long as peer identity cannot authorize spending, certify consensus, or alter accepted state.
  • The v4.0 proof-of-stake transition is outside this production assessment.
  • External bridges or wrapped representations were not established and are excluded from scope.

Evidence record

Claims and Caveats

Security Assessment & Evidence Preparedness

Public cryptographic inventory and quantum threat model

Claim: The production design identifies WOTS+ transaction authorization, hash-based native ownership, proof-of-work consensus, and the quantum threat motivating a PQ-native launch.

Coverage basis: The current whitepaper and public production code document the principal ownership and consensus mechanisms, with no classical native ownership namespace evidenced.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Coverage is strongest for ownership and signatures and less complete for ancillary state and transport primitives.

No separate exhaustive cryptographic bill of materials was supplied.

Security Assessment & Evidence Preparedness

Public evidence record supporting the assessment

Claim: Public specification, production source code, official documentation, and mainnet explorer evidence support the PQ-native transaction-signature claim.

Coverage basis: Canonical artifacts cover protocol design, implementation, and observed mainnet operation.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: No usable independent-audit artifact is included in the canonical record.

The official website is corroborative; the specification, code, and explorer carry the principal evidentiary weight.

Production Cryptographic Protection

Spend authorization / transaction signatures

Claim: Native MCM transactions use mandatory WOTS+ spend authorization on production mainnet.

Coverage basis: The whitepaper specifies WOTS+ from genesis, the public repository contains its production implementation, and the explorer evidences live transactions.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Specification, mainnet proof, and public code support full implementation despite absent canonical audit evidence.

No classical transaction-signature fallback is identified.

Production Cryptographic Protection

Account, address, public-key exposure, and key derivation

Claim: The native address design uses one-time WOTS+ authorization and exposes no ECC, BLS, Schnorr, or EdDSA native ownership path.

Coverage basis: Protocol documentation, implementation, and mainnet activity support a post-quantum native address and signing namespace.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Correct one-time-key handling remains an implementation-assurance concern rather than an identified classical fallback.

This finding does not extend to third-party wrapped representations.

Production Cryptographic Protection

Consensus-critical authentication

Claim: The evaluated proof-of-work mainnet has no validator-signature, VRF, threshold-finality, or block-certificate authentication layer.

Coverage basis: The supplied sources describe current production consensus as proof of work; the future proof-of-stake design is outside scope.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: This subfactor must be reassessed if proof of stake activates on mainnet.

N/A applies to validator-style consensus authentication, not transaction or state integrity.

Production Cryptographic Protection

State-integrity and data-availability mechanisms

Claim: Production transaction validation and neogenesis snapshots are evidenced, but the dossier does not comprehensively specify all state-binding, supply-integrity, and data-availability cryptographic dependencies.

Coverage basis: The whitepaper establishes neogenesis snapshots and the repository establishes an implemented chain, but the canonical record lacks a complete state-integrity inventory.

Implementation score: 0.5 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: cap-applying

Quantum blocker: Complete quantum-relevant verification of production state and supply binding is unavailable in the canonical dossier.

Assurance: This is an evidence limitation, not an identified state-integrity exploit.

Further specification or code-level evidence is needed for state-root construction, snapshot authorization, supply accounting, and any critical commitment mechanism.

Production Cryptographic Protection

Privacy and proof layers

Claim: No shielded pool, zero-knowledge proof system, stealth-address layer, or privacy-specific note-encryption mechanism is established for the evaluated production chain.

Coverage basis: Canonical protocol descriptions and explorer evidence concern a transparent WOTS+ transaction ledger.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: This classification does not imply transaction confidentiality.

Any undisclosed privacy extension would require separate assessment.

Production Cryptographic Protection

P2P transport, node identity, and peer authentication

Claim: P2P identity or transport is not evidenced as an authorization, finality, bridge, custody, or asset-ownership root in the current proof-of-work design.

Coverage basis: Mandatory WOTS+ transaction validation and proof-of-work consensus mean peer identity alone cannot authorize native spending.

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The precise transport and node-identity mechanisms are not comprehensively documented.

This treatment would change if peer authentication were shown to certify blocks, snapshots, or privileged state transitions.

Production Cryptographic Protection

Critical wallet, custody, HSM, signer, and hardware-wallet workflows

Claim: Native wallet and transaction tooling in the public implementation supports the mandatory WOTS+ path.

Coverage basis: Official documentation and production source code show WOTS+ wallet and transaction integration, making the PQ path intrinsic rather than optional.

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Exchange, HSM, hardware-wallet, backup, and institutional custody controls were not supplied.

Missing third-party custody attestations do not reduce native protocol coverage.

Migration Status & Value-at-Risk

Percentage of economically relevant value-at-risk protected

Claim: Native MCM value is protected by mandatory WOTS+ ownership with no evidenced classical native balance class.

Coverage basis: PQ-native coverage applies to native balances by protocol construction rather than opt-in migration statistics.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: This does not attest to external wrapped assets or off-chain custody systems.

No migration percentage is required for structural native coverage.

Migration Status & Value-at-Risk

Critical wallets migrated, protected, or inherently PQ-native

Claim: Native treasuries, exchanges, custodians, foundations, and large holders must use the same WOTS+ ownership path as other native balances.

Coverage basis: The protocol provides no evidenced classical native account type for high-value wallets.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Operational custody quality and off-chain account security were not assessed.

Separate bridge contracts or wrapped tokens, if any, remain outside this conclusion.

Migration Status & Value-at-Risk

Legacy vulnerable pools identified, measurable, deprecated, migrated, frozen, or absent by design

Claim: No legacy ECC-, BLS-, Schnorr-, or EdDSA-controlled native balance pool is evidenced from genesis onward.

Coverage basis: The whitepaper, production implementation, and explorer consistently support mandatory WOTS+ use since genesis.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Legacy-balance analytics are unnecessary where the vulnerable namespace never existed.

External representations are not native legacy pools and require separate evaluation.

Migration Mechanism, Governance & Ecosystem Coordination

Public migration or protection roadmap

Claim: A separate ECC-to-PQC migration roadmap is unnecessary for native MCM because post-quantum authorization has been mandatory since genesis.

Coverage basis: The production design constitutes complete native protection; reserved upgrade slots document a future PQ algorithm path.

Implementation score: 1 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: Future proof-of-stake planning is outside this production migration assessment.

Credit derives from complete-by-design protection, not testnet roadmap work.

Migration Mechanism, Governance & Ecosystem Coordination

Migration accessibility and defaults

Claim: Post-quantum native account creation and transaction signing are mandatory defaults rather than optional wallet features.

Coverage basis: WOTS+ is integrated into the native protocol, wallet design, transaction path, and production code.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Wallet usability, backup, hardware support, and exchange integration are outside the cryptographic-default finding.

Migration prompts are unnecessary because there is no legacy account type.

Migration Mechanism, Governance & Ecosystem Coordination

Migration enforcement and ecosystem coordination

Claim: Consensus transaction validation enforces WOTS+ and blocks classical native fallback without voluntary migration coordination.

Coverage basis: Mandatory protocol validation provides enforcement for all native participants.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: This does not establish controls for external wrappers or bridges.

Protocol enforcement substitutes for migration deadlines or legacy-address freezes.

Migration Mechanism, Governance & Ecosystem Coordination

Emergency disclosure, incident response, or quantum governance

Claim: No formal quantum-specific emergency disclosure, incident-response, or governance process is established by the canonical sources.

Coverage basis: The active repository and versioned protocol demonstrate development capability, but not a documented emergency process.

Implementation score: 0.5 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The absence of a formal playbook does not create a cap because no current vulnerable native fallback is identified.

A published security contact, disclosure policy, and emergency activation process would support fuller credit.

Algorithm & Implementation Assurance

Standardized, standards-track, or broadly reviewed PQC algorithm selection

Claim: Mochimo uses WOTS+, a standards-track hash-based signature construction referenced to RFC 8391/8554, for native spend authorization.

Coverage basis: The whitepaper identifies the construction and the public repository contains its implementation.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Algorithm selection is strongly supported despite absent canonical independent-audit evidence.

This assessment does not endorse the unverified future Dilithium deployment.

Algorithm & Implementation Assurance

Independent cryptographic and implementation audit

Claim: No usable canonical independent-audit artifact establishes review coverage for the current production implementation.

Coverage basis: Current assurance rests on public specification, code, and mainnet evidence; the dossier's historical review reference is not canonically verifiable.

Implementation score: 0 · Evidence confidence: None

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Audit absence limits overall confidence but does not reduce otherwise verifiable production protection through another subfactor or independently create a readiness cap.

A published, current, version-matched review would be the highest-value assurance improvement.

Algorithm & Implementation Assurance

Open-source, reproducible implementation

Claim: The production implementation, including WOTS+ source files and transaction handling, is publicly available for inspection.

Coverage basis: The canonical repository provides the production C implementation and associated node, wallet, transaction, and mining code.

Implementation score: 1 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: No documented clean-build, deterministic-build, or reproducible-binary exercise was supplied.

Source availability supports verification; binary provenance was not separately established.

Algorithm & Implementation Assurance

Parameter agility and future upgrade path

Claim: The protocol documentation reserves upgrade capacity for future standardized post-quantum algorithms.

Coverage basis: Reserved algorithm slots document a forward path, while activation governance and production use of an alternative scheme are not established.

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Activation criteria, compatibility, rollback, and governance procedures are not fully documented.

Future PQ-to-PQ upgrade uncertainty does not reduce current production protection.

Algorithm & Implementation Assurance

Stateful-signature, side-channel, fault-injection, HSM, and custody implementation risks

Claim: The one-time WOTS+ address design provides structural signing-state discipline, but anti-reuse, serialization, randomness, side-channel, fault-injection, HSM, and hardware-wallet controls are incompletely documented.

Coverage basis: The whitepaper and production code support one-time-signature integration and address rotation; broader operational hardening evidence is limited.

Implementation score: 0.75 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No canonical audit or dedicated control analysis verifies all stateful-signature safeguards, and reported historical recommendations cannot be checked.

No actual key-reuse fallback or quantum-enabled exploit is identified.

Algorithm & Implementation Assurance

Performance and resource-impact analysis

Claim: WOTS+ operates on mainnet, but no formal canonical performance or resource-impact analysis was supplied.

Coverage basis: Sustained production operation demonstrates practical deployment; formal analysis of signature size, verification cost, bandwidth, storage, and wallet overhead is absent.

Implementation score: 0.5 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Missing formal benchmarks do not create a cap without evidence that resource constraints prevent safe use of mandatory WOTS+.

A versioned benchmark and ledger-growth analysis would improve assurance.

Report metadata

Generation Details