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.
Category breakdown
QRI Factors
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