Pepe PEPE

Claim: PEPE has no published cryptographic inventory or quantum threat model. All cryptographic dependencies are standard ERC-20 / Ethereum L1 primitives, publicly verifiable on Etherscan.

Coverage basis: Publicly verifiable contract code; no project-published quantum assessment

Implementation score: 0 · Evidence confidence: None

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

Assurance: Contract source is verified and audited; cryptographic surface is trivially simple (standard ERC-20). No formal quantum threat model exists, but the attack surface is fully knowable from public artifacts.

The project has not published a quantum-specific assessment. The Fairyproof audit (2023) covers general smart-contract security only.

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933

Claim: Evidence includes verified contract source on Etherscan, Fairyproof audit report, and third-party reporting on the multisig incident. No quantum-curated evidence record exists.

Coverage basis: Public block explorer, audit PDF, news article

Implementation score: 0 · Evidence confidence: None

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

Assurance: Audit is from 2023 (stale but relevant for renounced-ownership claim). Multisig incident reporting is from 2023. Evidence is sufficient to assess quantum risk posture but not organized as a quantum evidence record.

Evidence record exists but is not quantum-curated. The contract is simple enough that the existing evidence supports a complete understanding of the token's cryptographic surface.

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933
• https://fairyproof.com/doc/Pepe-Audit-Report.pdf
• https://www.theblock.co/post/247555/pepe-multisig-transfers

Claim: PEPE token transfers are authorized via standard Ethereum transactions using ECDSA (secp256k1). No PQC or hybrid-PQC spend authorization exists on Ethereum mainnet.

Coverage basis: Inherited from Ethereum L1; token has no independent spend-authorization mechanism

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECDSA-only spend authorization on Ethereum L1; no production PQC path exists

Assurance: Ethereum's ECDSA dependency is well-documented. Ethereum Foundation acknowledges this vulnerability and has active PQC devnets (10+ client teams, weekly interop) but no mainnet deployment.

Per QRI §7.2, PEPE inherits Ethereum's spend-authorization posture. Ethereum's structured fork milestones target ~2029 for core PQC infrastructure. EIP-8141 (native account abstraction) is being considered for Hegotá fork (H2 2026).

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933
• https://pq.ethereum.org/
• https://ethereum.org/roadmap/future-proofing/

Claim: PEPE tokens are held in standard Ethereum EOAs. Public keys are exposed on-chain after the first outgoing transaction, creating long-exposure (at-rest) quantum vulnerability.

Coverage basis: Inherited from Ethereum L1 account model

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Ethereum EOAs expose public keys after first transaction, enabling offline quantum key-recovery (long-exposure attack surface)

Assurance: Well-understood property of Ethereum's account model. No PQC account type exists on mainnet.

PEPE inherits this vulnerability from Ethereum. Any PEPE held in an EOA that has sent a transaction has an exposed public key vulnerable to offline Shor's algorithm attacks.

• https://ethereum.org/roadmap/future-proofing/
• https://pq.ethereum.org/

Claim: Ethereum consensus uses BLS signatures for validator attestations and block certification. BLS is quantum-vulnerable (pairing-based, ECDLP).

Coverage basis: Inherited from Ethereum L1 consensus layer

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Ethereum consensus (BLS) is quantum-vulnerable; PQ Public Key Registry design published June 2026, no production deployment

Assurance: EF Post-Quantum team published validator PQ key registry design on ethresear.ch (June 1, 2026). leanXMSS + leanVM aggregation under active development. No production deployment.

A quantum attacker who can forge BLS validator signatures could disrupt Ethereum finality, indirectly affecting PEPE token security. This is an inherited risk from Ethereum L1.

• https://pq.ethereum.org/
• https://ethresear.ch/t/exploring-the-design-space-for-a-post-quantum-public-key-registry-for-ethereum-validators/25040

Claim: Ethereum's data availability uses KZG commitments (elliptic-curve-pairing-based), which are quantum-vulnerable. PEPE token state integrity inherits this dependency.

Coverage basis: Inherited from Ethereum L1 data layer

Implementation score: 0 · Evidence confidence: High

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

Assurance: KZG commitment vulnerability is acknowledged by Ethereum Foundation. Post-quantum data availability is on the roadmap but not deployed.

Inherited risk. PEPE does not add independent state-integrity mechanisms beyond Ethereum L1.

• https://pq.ethereum.org/
• https://ethereum.org/roadmap/future-proofing/

Claim: PEPE has no privacy layer, shielded transactions, or ZK proof systems.

Coverage basis: Token design

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933

Claim: P2P networking is an Ethereum L1 function. PEPE as a token has no independent P2P layer.

Coverage basis: Token architecture

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: The PEPE project multisig wallet uses standard Ethereum ECDSA for signer authorization. No PQC wallet, custody, or HSM workflow exists for the multisig.

Coverage basis: Project multisig wallet (ECDSA-based)

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: PEPE project multisig uses ECDSA signer keys; a CRQC could forge signatures to drain the treasury if signer public keys are exposed on-chain

Assurance: Current multisig address, signer threshold, and key exposure status are not independently verified for this evaluation. The 2023 incident confirms the multisig exists and holds material PEPE supply. The January 2025 transfer of 170B PEPE to a new wallet (per blockchainreporter.net) suggests ongoing multisig activity.

The token contract itself is renounced (owner = zero address), so there is no token-level admin key quantum risk. The quantum risk is concentrated in the off-chain multisig custody of treasury tokens.

• https://www.theblock.co/post/247555/pepe-multisig-transfers
• https://www.theblock.co/post/247576/pepe-team-members-stole-15-million-from-multisig

Claim: No PEPE value is protected from quantum key-recovery attacks. All PEPE tokens exist on Ethereum with ECDSA-based spend authorization.

Coverage basis: Token supply on Ethereum L1

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 0% of PEPE value-at-risk is quantum-protected; coverage is effectively zero

Assurance: PEPE is not PQ-native. All value exists on Ethereum which has no production PQC. Coverage is unambiguously <25%.

Per QRI §9.3.1 coverage thresholds: <25% → score 1 (the subfactor weight is 20, so earned = 20 × 0.05 = 1.00).

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933
• https://coinmarketcap.com/currencies/pepe/

Claim: The PEPE project multisig is not migrated to any PQC-protected custody. No critical PEPE wallets are known to use PQC.

Coverage basis: Project multisig and known treasury wallets

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: PEPE project multisig remains on standard ECDSA with no PQC migration path

Assurance: No evidence of any PQC wallet or custody migration for PEPE treasury. The multisig's current address and configuration are not independently verified.

The token contract itself has no admin keys (renounced), which eliminates one class of critical-wallet risk. The remaining risk is in the off-chain multisig.

• https://www.theblock.co/post/247555/pepe-multisig-transfers
• https://www.theblock.co/post/247576/pepe-team-members-stole-15-million-from-multisig

Claim: No legacy vulnerable PEPE pools have been identified, measured, deprecated, or addressed by the project.

Coverage basis: Project-level migration tracking

Implementation score: 0 · Evidence confidence: None

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

Assurance: PEPE as a standard ERC-20 inherits Ethereum's account model. All EOAs with transacted PEPE have exposed public keys. No project-level effort to identify or address these exists.

This subfactor is inherently tied to Ethereum L1's account model. Until Ethereum provides account-level PQC migration, PEPE cannot independently address this.

Claim: No quantum migration roadmap has been published by the PEPE project.

Coverage basis: Project publications and communications

Implementation score: 0 · Evidence confidence: None

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

Assurance: No roadmap found in any public PEPE communication channel. This is unsurprising for a meme token with a renounced contract.

PEPE depends entirely on Ethereum's migration roadmap (targeting ~2029). The project has not articulated any token-specific migration steps.

Claim: No PQC account creation, wallet tooling, transaction paths, custody paths, or user-facing migration prompts exist for PEPE.

Coverage basis: Token ecosystem tooling

Implementation score: 0 · Evidence confidence: High

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

Assurance: No PQC wallet, custody, or migration tooling exists for Ethereum generally as of the evaluation date. PEPE inherits this gap.

Standard Ethereum wallets (MetaMask, Trust Wallet, etc.) support PEPE but use ECDSA exclusively. No PEPE-specific tooling addresses quantum migration.

Claim: No deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration mechanisms exist for PEPE or its dependent infrastructure.

Coverage basis: Token governance and infrastructure

Implementation score: 0 · Evidence confidence: High

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

Assurance: The token contract is renounced with no governance mechanism. No enforcement is possible at the token level. All enforcement depends on Ethereum L1 and exchange/custody coordination.

The renounced contract means the PEPE project cannot enforce migration at the token level even if it wanted to. This is a structural limitation for any token-specific quantum migration.

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

Coverage basis: Project governance and security processes

Implementation score: 0 · Evidence confidence: None

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

Assurance: The PEPE project has no formal security contact, disclosure process, or governance structure. The August 2023 multisig incident response was conducted via social media. This is noted as an operational gap but does not independently create a quantum-attack path beyond what already exists.

Per QRI §8.2, the absence of a formal quantum-specific incident-response playbook does not create a Readiness & Risk Cap by itself. It is recorded here as an assurance note.

Claim: No PQC or hybrid-PQC algorithms are used in any PEPE-specific context. The token relies entirely on Ethereum's ECDSA and Keccak-256.

Coverage basis: Token contract and dependent infrastructure

Implementation score: 0 · Evidence confidence: High

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

Assurance: Contract source is verified and uses only standard Solidity/OpenZeppelin primitives (ERC-20, Ownable). No custom crypto.

PEPE has no independent PQC algorithm usage. This subfactor is scored at 0.00 because the token uses no PQC at all, not because it uses non-standard PQC.

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933

Claim: The Fairyproof audit (2023) covers general smart-contract security and confirms renounced ownership. It does not address quantum-critical cryptographic properties.

Coverage basis: Fairyproof audit report (2023-08-21)

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Audit is 2.8 years old (stale). It covers general security (owner renounced, no critical vulnerabilities in token issuance) but has no quantum-specific scope. The token has no PQC implementation to audit, so a quantum-scoped audit would have nothing to evaluate at the token level.

Per QRI §6.4, a scope-mismatched or stale audit does not reduce the QRI Score by itself when the quantum-critical property (no PQC deployed) is verifiable from other evidence. The audit supports the claim that the contract is renounced and standard.

• https://fairyproof.com/doc/Pepe-Audit-Report.pdf

Claim: PEPE token contract source code is verified on Etherscan and is a standard OpenZeppelin-derived ERC-20 implementation.

Coverage basis: Etherscan verified contract

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Source code is publicly verified and matches the deployed bytecode. The implementation is standard and reproducible.

Full credit for open-source availability. The contract uses standard, well-understood patterns.

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933

Claim: No PQC parameter agility or documented upgrade path exists. The token contract is renounced, making token-level upgrades impossible without a new contract deployment.

Coverage basis: Token contract architecture

Implementation score: 0 · Evidence confidence: High

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

Assurance: The renounced ownership means no token-level upgrade is possible. Any quantum migration would require users to move tokens to a new contract, which depends on Ethereum L1 providing PQC accounts.

Parameter agility is inapplicable at the token level since there are no token-specific cryptographic parameters. The upgrade path limitation is structural (renounced contract) and inherent to the token's design.

• https://etherscan.io/token/0x6982508145454ce325ddbe47a25d4ec3d2311933
• https://fairyproof.com/doc/Pepe-Audit-Report.pdf

Claim: No stateful PQC signatures (XMSS/LMS) are used by PEPE or its dependent infrastructure.

Coverage basis: Token architecture

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No performance or resource-impact analysis exists for PEPE, as no PQC deployment is planned or implemented.

Coverage basis: Project documentation

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Performance analysis is a deployment-readiness concern. Since PEPE has no PQC roadmap, this subfactor is not applicable to the current evaluation scope.