Humanity H

Claim: The project has not published a cryptographic inventory or quantum threat model.

Coverage basis: Not published by project; evaluator identified ECDSA (EVM), pairing-based zkEVM proofs (Polygon CDK), DAC multi-sig, AES-GCM for VC encryption from public documentation.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: NO_PUBLIC_CRYPTOGRAPHIC_INVENTORY

Assurance: Architecture is publicly documented across multiple sources, enabling evaluator identification of vulnerable systems. However, the project itself has published zero quantum-specific documentation.

No quantum risk assessment, cryptographic inventory, or threat model has been published by the Humanity Protocol team. The evaluator identified critical cryptographic systems from public architectural documentation and third-party sources.

• https://docs.humanity.org/whitepaper
• https://humanity-protocol.gitbook.io/humanity-protocol/human-centric-blockchain
• https://www.animocabrands.com/announcement/humanity-protocol-emerges-from-stealth-human-institute-in-collaboration-with-animoca-brands-and-polygon-labs-pioneers-the-human-layer-for-web3
• https://www.mexc.com/learn/article/what-is-humanity-protocol

Claim: No public evidence record (code references, specs, transaction examples, reproducible analytics) supporting a quantum risk assessment exists.

Coverage basis: No assessment published by project.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The absence of any quantum-related evidence record from the project is well-established through exhaustive search of official documentation, gitbook, website, and third-party coverage.

The project's MiCA white paper (cdn.humanity.org) lists technology risks including 'bugs in upstream Ethereum infrastructure' and 'unauthorised access to private keys' but does not mention quantum computing as a threat.

Claim: All transaction signing uses standard ECDSA via EVM accounts. No PQC or hybrid-PQC support exists.

Coverage basis: Standard EVM ECDSA; no PQ/hybrid path.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECC_ONLY_SPEND_AUTH

Assurance: High confidence: ERC-20 tokens on Ethereum and EVM-compatible L2s use ECDSA for transaction authorization by default. This is a fundamental property of the EVM and requires no project-specific verification for standard tokens.

The H token (0xcf5104d094e3864cfcbda43b82e1cefd26a016eb) is a standard ERC-20. All spend authorization inherits Ethereum's ECDSA. The Humanity L2, as an EVM-compatible chain, also uses ECDSA for native transaction signing. Every EOA that has sent a transaction has an exposed public key (long-exposure, at-rest attack surface).

• https://www.coingecko.com/en/coins/humanity
• https://coinmarketcap.com/currencies/humanity-protocol/
• https://docs.humanity.org/whitepaper

Claim: Standard Ethereum address derivation (keccak256 of ECDSA public key). No PQ/hybrid address formats, no public-key hiding, no exposure controls.

Coverage basis: Standard EVM account model; no PQ controls.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: EVM account model is well-understood. Any EOA that has broadcast a transaction has an exposed public key creating a long-exposure attack surface.

No evidence of address-format migration planning, stealth addressing, or key-derivation changes to reduce public-key exposure. The project's identity layer (DIDs, VCs) uses separate key management (Lit Protocol key-share network) but this does not protect token-holding accounts.

• https://www.coingecko.com/en/coins/humanity
• https://docs.humanity.org/whitepaper

Claim: DAC (Decentralized Attestation Committee) members sign batch attestations with standard ECDSA. Sequencer uses standard EVM authentication. No PQC.

Coverage basis: Standard EVM signatures for DAC and sequencer.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: ECC_ONLY_CONSENSUS

Assurance: Medium confidence: the DAC mechanism is described in blog posts and secondary sources but not in a formal protocol specification. The exact signature scheme and threshold parameters are not publicly specified. The use of ECDSA for DAC signatures is inferred from standard Polygon CDK architecture.

The zkProofer blog describes DAC members generating 'unique signatures' to endorse batch integrity and a multi-signature smart contract on Ethereum verifying these signatures. Standard Polygon CDK architecture uses ECDSA for DAC signatures. No PQC alternative exists.

• https://www.humanity.org/blog/zkproofers-powering-the-future-of-decentralized-identity-on-humanity-protocol
• https://www.mexc.com/learn/article/what-is-humanity-protocol

Claim: zkEVM validity proofs (likely Groth16/PLONK with KZG commitments on BN254) are pairing-based and quantum-vulnerable. L1 settlement on Ethereum inherits Ethereum's ECC.

Coverage basis: Polygon CDK zkEVM with pairing-based proof system.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: PAIRING_BASED_ZK

Assurance: Medium confidence: the project is confirmed to use Polygon CDK zkEVM, which uses Groth16 or PLONK with KZG commitments. However, Humanity Protocol's specific proof system configuration and any customizations are not publicly documented. The quantum vulnerability of pairing-based proof systems is well-established.

Polygon CDK zkEVM uses BN254 (altbn128) curve for proof verification. Both Groth16 and PLONK-KZG rely on pairing-based cryptography broken by quantum computers. A quantum attacker could potentially forge validity proofs, enabling theft from the L1 bridge escrow. The VC metadata Merkle tree (stored on-chain) relies on keccak256, which is quantum-resistant for collision resistance but the state-binding depends on the underlying proof system.

• https://www.animocabrands.com/announcement/humanity-protocol-emerges-from-stealth-human-institute-in-collaboration-with-animoca-brands-and-polygon-labs-pioneers-the-human-layer-for-web3
• https://github.com/0xPolygon/cdk
• https://www.mexc.com/learn/article/what-is-humanity-protocol

Claim: ZK proofs for identity verification are of unspecified type. AES-GCM used for VC encryption. No evidence of quantum-safe ZK proof system.

Coverage basis: Unspecified ZK proof system; AES-GCM for symmetric encryption.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: Low confidence: the ZK proof system type is not specified in any public documentation. The gitbook mentions 'zero-knowledge proofs' and 'zero-knowledge verifiable presentations' without specifying Groth16, PLONK, STARK, or any other system. AES-GCM for symmetric encryption is quantum-resistant (Grover's algorithm), but this protects only encrypted VC data at rest.

The gitbook describes AES-GCM as 'quantum-resistant symmetric private key' for VC encryption—this is a reasonable claim for symmetric encryption. However, the ZK proof verification layer, which is critical for Sybil resistance (the protocol's core function), remains quantum-vulnerable if it uses pairing-based proofs. The zkTLS integration with Reclaim may use different proof systems but this is not documented.

• https://docs.humanity.org/whitepaper
• https://humanity-protocol.gitbook.io/humanity-protocol/human-centric-blockchain/key-players-and-components-of-the-hp-ecosystem/privacy-preserving-data-storage-and-use
• https://www.humanity.org/blog/zkproofers-powering-the-future-of-decentralized-identity-on-humanity-protocol

Claim: Standard Polygon CDK / EVM P2P networking. No PQC for node identity or peer authentication.

Coverage basis: Standard EVM networking stack.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Medium confidence: P2P networking details are not documented for Humanity Protocol specifically. Standard Polygon CDK uses libp2p with standard TLS/noise protocols. Node identity is not directly spend-critical but could enable eclipse attacks.

P2P node identity and peer authentication are generally not quantum-critical for asset security in rollup architectures where settlement occurs on L1. However, in the absence of any documentation, the subfactor is scored at 0.00 for completeness.

• https://github.com/0xPolygon/cdk

Claim: No PQ/hybrid wallet, custody, or HSM workflows exist. Standard Ethereum wallets used.

Coverage basis: Standard Ethereum wallet ecosystem.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: the H token is listed on standard exchanges (Binance, Bybit, MEXC, KuCoin, Bitstamp, Bitvavo) and uses standard Ethereum wallet infrastructure. No exchange or custody provider has attested to PQ-safe H token custody.

The Humanity Protocol mainnet blog post (July 2025) mentions Fireblocks integration for institutional treasury access, but this is standard ECDSA-based custody. No PQ/hybrid custody path exists.

• https://www.coingecko.com/en/coins/humanity
• https://coinmarketcap.com/currencies/humanity-protocol/

Claim: 0% of value-at-risk is protected. All H token value and L2 state rely on quantum-vulnerable ECC.

Coverage basis: No migration; 0% protected; <25% coverage.

Implementation score: 0.05 · Evidence confidence: High

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

Assurance: High confidence: 0% migration/protection coverage is trivially verifiable from the absence of any PQC implementation or migration mechanism.

Per 9.3.1 coverage thresholds: <25% = score 1 out of 20, implementation_score = 0.05. The H token has a fixed supply of 10 billion tokens. Circulating supply, treasury, foundation, and protocol-controlled value all remain fully exposed. No migration has occurred. All EOAs that have transacted have long-exposure vulnerable public keys.

• https://www.coingecko.com/en/coins/humanity
• https://coinmarketcap.com/currencies/humanity-protocol/

Claim: No critical wallets have been migrated or protected. No PQ-native path exists.

Coverage basis: No migration; all wallets vulnerable.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no evidence of any critical wallet migration exists. The project has not published any migration attestations for treasuries, exchanges, custodians, bridges, foundations, or major protocols.

The Humanity Foundation (treasury), Human Institute (protocol developer), and exchange-listed H tokens are all held in standard Ethereum EOAs or multisigs with ECDSA security. The Fireblocks institutional integration uses standard ECDSA-based MPC.

Claim: No identification, measurement, or deprecation of quantum-vulnerable value pools has been published.

Coverage basis: No legacy pool management.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no evidence of any work to identify, measure, or deprecate quantum-vulnerable value pools.

The project has not published any analysis of exposed public keys, unmigratable funds, dormant holdings, or lost coins. No freeze, burn, or salvage policy exists for quantum-vulnerable value.

Claim: No quantum migration or protection roadmap has been published.

Coverage basis: No roadmap.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: both the 2026 roadmap blog post and the product development roadmap in the gitbook contain zero mention of quantum computing, post-quantum cryptography, or cryptographic migration.

The project's roadmap focuses on verifier node rollout, zkKYC solutions, credential format expansion, and interoperability. Cryptographic migration is not on the published roadmap.

• https://www.humanity.org/blog/what-s-cooking-in-2026
• https://humanity-protocol.gitbook.io/humanity-protocol/human-centric-blockchain/key-players-and-components-of-the-hp-ecosystem/product-development-and-privacy-roadmap

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: No migration infrastructure.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: the absence of any PQ migration tooling is established through exhaustive search of the project's documentation, website, gitbook, and third-party coverage.

The project's user-facing infrastructure (dashboard, palm scan app, zkProofer node software) contains no quantum-related features, warnings, or migration paths.

Claim: No enforcement mechanisms, no exchange/custody/bridge/wallet coordination for quantum safety.

Coverage basis: No coordination.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no evidence of any migration enforcement or exchange coordination exists.

The project's governance framework (Snapshot voting, Human Institute 3-of-5 multisig execution) could theoretically be used to coordinate a quantum migration, but no such proposal or planning has occurred. The governance process itself relies on ECDSA for voting authentication.

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

Coverage basis: No quantum IR process.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: the MiCA white paper lists technology risks and mitigation measures without mentioning quantum computing. No quantum-specific security contact or disclosure process has been published.

The MiCA white paper's technology risk section mentions 'bugs in upstream Ethereum infrastructure' and 'unauthorised access to private keys' but does not address quantum threats. The governance framework (Snapshot + multisig execution) has no quantum-specific emergency provisions.

• https://cdn.humanity.org/Humanity_Reserve_white_Paper.html

Claim: No PQC algorithms are used in any layer of the protocol.

Coverage basis: No PQC usage.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no PQC algorithms (CRYSTALS-Kyber/ML-KEM, CRYSTALS-Dilithium/ML-DSA, Falcon, SPHINCS+, LMS, XMSS) are documented, implemented, or deployed in any protocol layer.

AES-256-GCM (used for VC encryption) is NIST-standardized symmetric cryptography and is considered quantum-resistant, but this is not a PQC algorithm in the NIST PQC standardization sense. It protects only encrypted data at rest.

Claim: No independent cryptographic audit exists for the quantum-critical scope. The Quantstamp audit covered only the H ERC-20 token contract.

Coverage basis: No quantum-critical audit.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: the MiCA white paper confirms a Quantstamp audit (January 7-8, 2025) of the H token smart contract only. The audit found one informational issue (fixed) and no high/medium/low severity issues. This audit did not cover cryptographic primitives, zkEVM proof systems, DAC signatures, or any quantum-critical scope.

The Quantstamp audit confirmed the H token is 'secure, upgradeable, and restricts minting and burning to the contract owner.' This is a standard smart-contract audit with no quantum relevance. No audit of the L2 protocol, zkEVM prover, DAC mechanism, or ZK identity verification system has been published.

• https://cdn.humanity.org/Humanity_Reserve_white_Paper.html

Claim: No open-source implementation of the L2 protocol, zkEVM prover, or cryptographic primitives has been published.

Coverage basis: No public source code for protocol cryptography.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence that no protocol-level source code is public. The github.com/humanity-org organization contains only a demo ERC-20 deployment repo. The github.com/humanprotocol organization belongs to a different project (HUMAN Protocol). The github.com/Proof-Of-Humanity organization contains identity registry contracts but not the L2 protocol implementation.

The Polygon CDK itself is open-source (AGPL-3.0), but Humanity Protocol's specific configuration, customizations, and deployment parameters are not publicly available. The zkEVM prover used is Polygon's, which is open-source, but Humanity's specific instantiation and any modifications are not published.

• https://github.com/humanity-org/hp-human-only-airdrop-off-chain-contracts

Claim: No parameter agility or cryptographic upgrade path has been documented.

Coverage basis: No agility documentation.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no parameter agility or cryptographic upgrade documentation exists.

The H token contract uses an upgradeable proxy pattern (OpenZeppelin), which could theoretically enable migration of token logic. However, this does not address the fundamental ECDSA dependency of Ethereum accounts, the zkEVM proof system, or the L1 settlement layer.

Claim: No PQC signatures are used, so stateful-signature safety is not directly applicable. No side-channel or implementation risk analysis has been published.

Coverage basis: No PQC signatures; no analysis published.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The subfactor is applicable because it measures whether the project has considered these risks. The project has published no analysis. Implementation Score is 0.00.

Standard EVM ECDSA implementations have well-known side-channel risks (nonce reuse, biased nonces). No project-specific analysis of these risks or mitigation measures has been published.

Claim: No performance or resource-impact analysis for any PQC deployment has been published.

Coverage basis: No analysis.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: no PQC performance analysis exists.

PQC signatures (e.g., ML-DSA, SLH-DSA) are significantly larger and more computationally expensive than ECDSA. No analysis of how this would affect L2 block sizes, gas costs, proof generation, or validator/node hardware requirements has been published.