Mantle MNT

Claim: No public cryptographic inventory or quantum threat model has been published by Mantle.

Coverage basis: Absence of any such document across all official Mantle sources (docs.mantle.xyz, mantle.xyz, GitHub, blog).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory exists. Mantle has not identified, documented, or threat-modeled its quantum-vulnerable cryptographic primitives.

Assurance: The cryptographic primitives used by Mantle are identifiable from public source code and documentation (secp256k1, secp256r1, BN254 pairings, BLS12-381 KZG), but Mantle itself has not assembled or published an inventory. LayerQu independently confirms Mantle at Migration Stage 0 (Unaware).

• https://docs.mantle.xyz/network
• https://github.com/mantlenetworkio/mantle-v2
• https://www.mantle.xyz/

Claim: No quantum-specific evidence record has been assembled or published by Mantle.

Coverage basis: Absence across all official sources. Public code and documentation exist but are not organized as a quantum-readiness evidence record.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Public code, documentation, explorer data, and third-party analysis provide sufficient evidence for external QRI evaluation even though Mantle has not prepared its own evidence record.

Claim: Mantle uses ECDSA secp256k1 for standard EVM transaction signatures and additionally supports secp256r1 (P256) via RIP-7212 precompile for Passkeys. Neither is post-quantum.

Coverage basis: Standard EVM account model inherited from Ethereum/OP Stack. Confirmed by source code, documentation, and mainnet explorer.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All production spend authorization is ECC-only. Both secp256k1 and secp256r1 are vulnerable to Shor's algorithm on a CRQC. No PQ or hybrid signature alternative exists.

RIP-7212 (secp256r1) support was added for Passkeys and Account Abstraction. This expands the ECC footprint rather than reducing it. P256 is not quantum-resistant.

• https://github.com/mantlenetworkio/mantle-v2
• https://docs.mantle.xyz/network
• https://mantlescan.xyz/
• https://www.mantle.xyz/blog/announcements/rip-7212-unlocking-new-potential-for-mantle-and-ethereum-ecosystem

Claim: Standard Ethereum account model: public keys are exposed on every transaction broadcast. Addresses are Keccak-256 hashes of public keys. No PQ address formats or key-derivation protections exist.

Coverage basis: EVM account model inherited from Ethereum. Confirmed by explorer behavior showing standard EOA transactions.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Long-exposure quantum-vulnerable public keys exist for every EOA that has ever sent a transaction on Mantle. These keys can be harvested now and broken later (harvest-now-decrypt-later).

Accounts that have only received funds (never sent) have not exposed their full public key on-chain, providing marginal additional protection through address hashing. This is not a designed quantum protection.

• https://mantlescan.xyz/
• https://github.com/mantlenetworkio/mantle-v2

Claim: Mantle uses a centralized sequencer for block production. The critical consensus-security path is the ZK validity proof submitted to the MantleSuccinctL2OutputOracle on Ethereum L1. This proof uses Groth16 or PLONK over BN254, which relies on quantum-vulnerable elliptic curve pairings.

Coverage basis: SP1 documentation confirms Groth16/PLONK over BN254 for on-chain verification. Mantle blog confirms aggregated Groth16 proof submission.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: L1 ZK proof verification uses Groth16/PLONK over BN254. A quantum computer can forge validity proofs, enabling fraudulent state transitions and theft from L1 bridge/escrow contracts.

Assurance: SP1's internal STARK prover is hash-based and quantum-resistant, but the SNARK wrapper required for practical on-chain verification reintroduces quantum-vulnerable pairings. The STARK-internal quantum resistance does not protect the production verification path.

• https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types
• https://docs.succinct.xyz/docs/sp1/security/security-model
• https://www.mantle.xyz/blog/announcements/op-succinct-mantle-network-testnet
• https://docs.mantle.xyz/network/system-information/off-chain-system/sp1-zkvm/sp1-workflow

Claim: Mantle uses Ethereum blob commitments (KZG over BLS12-381) for data availability following the Arsia upgrade (April 2026). Previously used EigenDA KZG commitments. Both are quantum-vulnerable pairing-based schemes.

Coverage basis: Mantle documentation confirms transition to Ethereum blobs. Ethereum specification confirms KZG commitments over BLS12-381 for EIP-4844 blobs.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Ethereum blob KZG commitments over BLS12-381 are vulnerable to quantum pairings attacks. Binding property can be broken, enabling data withholding or state forgery.

Assurance: The DA migration from EigenDA to Ethereum blobs represents a security improvement against classical trust assumptions but preserves quantum vulnerability at the KZG commitment layer. Ethereum's post-quantum roadmap identifies KZG replacement as a required migration item (targeting STARK-based or lattice-based commitments).

• https://docs.mantle.xyz/network/introduction/updated-notices/migration-of-data-availability-to-ethereum-blobs
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/
• https://messari.io/report/state-of-mantle-q1-2026

Claim: Mantle's ZK validity proof system uses SP1 internally (STARKs over Poseidon2, quantum-resistant at the STARK layer) but wraps proofs in Groth16/PLONK over BN254 for L1 verification, which is quantum-vulnerable. Mantle has no privacy layer.

Coverage basis: SP1 documentation confirms STARK internals with Groth16/PLONK SNARK wrapper. The production-critical L1 verification path is what matters for quantum readiness.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The STARK-internal quantum resistance is real but irrelevant to production security because the Groth16/PLONK SNARK wrapper (required for practical on-chain verification costs) reintroduces quantum-vulnerable BN254 pairings. Succinct's VEIL project (May 2026) aims to add zero-knowledge to hash-based proof systems without SNARK wrappers, but this is not production-ready.

Mantle is not a privacy chain. The privacy/proof subfactor is applicable only for the ZK proof layer.

• https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types
• https://docs.succinct.xyz/docs/sp1/security/security-model
• https://docs.succinct.xyz/docs/sp1/what-is-a-zkvm

Claim: Standard OP Stack/geth P2P networking. Node identity likely uses secp256k1-based node keys (standard Ethereum devp2p).

Coverage basis: Mantle v2 is an OP Stack/geth fork. Standard Ethereum P2P stack uses ECDSA for node identity.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity is not directly spend-critical for users. A compromise of P2P identity could enable eclipse attacks or transaction censorship but does not directly enable asset theft. This is a lower-severity quantum vulnerability in the Mantle context.

As a rollup with a centralized sequencer, P2P node identity compromise would primarily affect non-sequencer nodes and RPC providers.

• https://github.com/mantlenetworkio/mantle-v2

Claim: No PQ wallet, custody, HSM, or hardware-wallet workflows exist for Mantle. All wallet interactions use standard ECDSA secp256k1 or secp256r1 (Passkeys).

Coverage basis: Standard EVM wallet ecosystem. No PQ wallet support identified in any Mantle documentation or partner announcements.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Bybit is Mantle's primary exchange partner and structural anchor. No evidence of PQ custody or HSM support from Bybit or any other Mantle-integrated custodian.

• https://www.mantle.xyz/blog/announcements/rip-7212-unlocking-new-potential-for-mantle-and-ethereum-ecosystem

Claim: 0% of Mantle value-at-risk is protected from quantum key-recovery attacks. All ~$1.7B TVS and multi-billion-dollar MNT market cap is held in quantum-vulnerable ECDSA accounts with exposed public keys.

Coverage basis: Messari Q1 2026 report: $1.7B TVS. All value held in standard EVM accounts.

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: <25% value-at-risk coverage. All economic value on Mantle is quantum-vulnerable with no protection, migration path, freeze mechanism, or recovery design.

Assurance: Coverage is 0%, earning the minimum <25% threshold score of 1 out of 20 subfactor points (Implementation Score 0.05). Value-at-risk figures represent a lower bound; actual vulnerable value likely exceeds reported TVS when accounting for dormant accounts, bridge escrow, and protocol-controlled value.

• https://messari.io/report/state-of-mantle-q1-2026
• https://mantlescan.xyz/

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, protocols) are PQ-migrated or PQ-protected.

Coverage basis: Absence of any PQ wallet announcements or migrations from Mantle Foundation, Bybit, or any Mantle ecosystem partner.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Mantle canonical bridge contracts, foundation treasury (~$2.4B), and Bybit-integrated custody all remain quantum-vulnerable with no migration path.

Claim: No legacy vulnerable pools have been identified, measured, or addressed by Mantle. No deprecation, freeze, migration, or burn policy exists.

Coverage basis: Complete absence of any such initiative in Mantle documentation, governance, or communications.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Mantle's EVM account model makes all transacted EOAs equally vulnerable. The distinction between 'legacy' and 'active' vulnerable accounts is less meaningful when no migration path exists for any account.

Claim: No quantum migration roadmap exists for Mantle.

Coverage basis: Complete absence across all Mantle official sources. LayerQu confirms Migration Stage 0 (Unaware).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No migration roadmap exists. Mantle has not acknowledged quantum risk in any official channel.

Assurance: Ethereum L1 has a published post-quantum roadmap (Lean Ethereum, targeting ~2029). As an L2, Mantle could theoretically benefit from Ethereum's PQ upgrades, but Mantle-specific L2 concerns (sequencer keys, L2 proof verification, bridge contracts) are not addressed by Ethereum's roadmap.

• https://docs.mantle.xyz/network
• https://www.mantle.xyz/

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, migration prompts, or user-facing quantum warnings exist on Mantle.

Coverage basis: Standard EVM tooling. No PQ features in any Mantle wallet, bridge, or dApp.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadlines) exist. No exchange, custody, bridge, wallet, or infrastructure coordination for quantum migration.

Coverage basis: Complete absence of any such mechanisms.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Claim: No quantum-specific emergency disclosure, incident-response, or governance process exists for Mantle.

Coverage basis: Absence of any such process in Mantle documentation or security disclosures.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Per Section 7.4 (Note-Only Caveat Rule), the absence of a quantum-specific IR playbook is treated as note-only because it does not create, preserve, or make unverifiable a current quantum-enabled attack path. General security disclosure processes exist.

Claim: No PQC or hybrid-PQC algorithms are used in any production capacity on Mantle.

Coverage basis: All production cryptographic primitives are classical (secp256k1, secp256r1, BN254, BLS12-381). No NIST PQC standards (FIPS 203/204/205) are implemented.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

• https://github.com/mantlenetworkio/mantle-v2
• https://docs.succinct.xyz/docs/sp1/security/security-model

Claim: No quantum-scoped audit exists. The OpenZeppelin op-geth audit (April 2024) is classical-only and predates the ZK validity rollup transition.

Coverage basis: OpenZeppelin audit covers op-geth component only, no quantum scope. SP1 contracts have a Veridise audit but this covers the SNARK verifier contracts, not quantum resistance.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The absence of a quantum-scoped audit does not reduce the QRI Score because there is no PQ implementation to audit. If PQ features were added, an in-scope audit would be required. Current audit coverage is scope-mismatched for quantum readiness.

• https://www.openzeppelin.com/news/mantle-op-geth-audit
• https://github.com/succinctlabs/sp1-contracts

Claim: Mantle's codebase is open-source (MIT license) and reproducible.

Coverage basis: GitHub repositories are public and buildable. The classical implementation is reproducible.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The codebase being open-source is a positive attribute for future auditability. Receives full implementation score for this subfactor.

• https://github.com/mantlenetworkio/mantle-v2
• https://github.com/mantlenetworkio

Claim: No documented parameter agility or PQ upgrade path exists for Mantle.

Coverage basis: Absence of any such documentation.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Mantle's modular architecture (OP Stack fork with swappable DA and proof systems) theoretically provides upgrade flexibility. The transition from EigenDA to Ethereum blobs and from Optimistic to ZK validity rollup demonstrates operational upgrade capability. However, no quantum-specific upgrade path is documented.

Claim: Not applicable as no stateful PQ signatures are used.

Coverage basis: No PQ signatures deployed.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No PQ performance or resource-impact analysis exists for Mantle.

Coverage basis: Absence of any such analysis.

Implementation score: 0 · Evidence confidence: High

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

Assurance: BNB Chain's published PQ migration report (May 2026) demonstrates the kind of performance analysis needed: single transaction size increase from ~110 bytes to ~2.5 KB, TPS drop of 40-50%, block size increase ~15x. Similar analysis would be needed for Mantle. The absence is treated as note-only because no PQ implementation exists to analyze.