Injective INJ

Claim: Injective's cryptographic primitives are identifiable from public architecture documentation and source code, but no formal quantum-focused cryptographic inventory or threat model has been published by Injective Foundation.

Coverage basis: Public architecture docs confirm Cosmos SDK + CometBFT; primitives are Ed25519 (validator consensus), secp256k1 ECDSA (Cosmos tx signing), ethsecp256k1 (EVM tx signing), SHA-256, Keccak-256. No quantum vulnerability assessment.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No public cryptographic inventory published by Injective Foundation. Cap: 10.

Assurance: Primitives are well-established Cosmos SDK/Tendermint defaults and are independently verifiable from public documentation and code. LayerQu third-party analysis has compiled a comprehensive primitive inventory.

Injective Foundation has not acknowledged quantum risk in any public communication. The project's architecture docs describe classical primitives for functional purposes, not for quantum vulnerability assessment.

• https://injective.com/blog/understanding-injective-architecture-and-consensus
• https://docs.hyperweb.io/auth
• https://github.com/InjectiveLabs/injective-protocol-specification
• https://layerqu.com/chains/injective/

Claim: Sufficient public evidence exists to assess quantum vulnerability: architecture docs, open-source code, mainnet explorer, and independent analysis. However, this evidence has not been compiled or acknowledged by Injective Foundation in a quantum-risk context.

Coverage basis: Public sources allow identification of all critical cryptographic primitives and their quantum-vulnerability status without project cooperation.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Evidence quality is Medium: primitives identifiable from public code and docs, but no project-compiled quantum assessment exists. Informal Systems audit (2021) is stale but confirms classical architecture.

Evidence exists but is scattered across multiple sources and has not been organized into a quantum risk assessment by the project. Third-party compilation (LayerQu) fills this gap.

• https://injective.com/blog/understanding-injective-architecture-and-consensus
• https://github.com/InjectiveFoundation/injective-core
• https://explorer.injective.network/
• https://github.com/informalsystems/audits/blob/main/Injective/informal-report-injective-audit-202106.pdf
• https://layerqu.com/chains/injective/

Claim: All transaction signing on Injective mainnet uses classical ECC: secp256k1 ECDSA for Cosmos-side accounts and ethsecp256k1 for EVM accounts. No PQC or hybrid signatures are supported.

Coverage basis: Confirmed by Cosmos SDK defaults, Hyperweb auth documentation, mainnet explorer, and LayerQu independent analysis. 0% mainnet PQC traffic.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECC-only (secp256k1 + ethsecp256k1). Cap: 40.

Assurance: High confidence: primitives confirmed by multiple independent primary sources including official documentation, code repositories, and mainnet transaction inspection.

Both Cosmos-side and EVM-side accounts are quantum-vulnerable. The Native EVM launch (2025-11-11) expanded the secp256k1 attack surface by adding ethsecp256k1 signing paths without introducing any PQC alternatives.

• https://docs.hyperweb.io/auth
• https://explorer.injective.network/
• https://layerqu.com/chains/injective/
• https://injective.com/blog/understanding-injective-architecture-and-consensus

Claim: Public keys are revealed on first outgoing transaction for both Cosmos-side and EVM accounts. Injective's exchange module requires continuous order-book activity, meaning effectively every active address has a revealed public key. No PQ/hybrid address formats or key-derivation schemes exist.

Coverage basis: Cosmos SDK and EVM defaults expose public keys in transaction signatures. Injective's derivatives-focused architecture ensures near-universal public key exposure among active users.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value with near-universal public key exposure. Cap: 55.

Assurance: High confidence: public key exposure is inherent to Cosmos SDK and EVM transaction models and is directly observable on the mainnet explorer.

Long-exposure (at-rest) attack surface is near-total among active addresses. Dormant holdings with exposed keys have accumulated since mainnet genesis (2021-11-08).

• https://explorer.injective.network/
• https://layerqu.com/chains/injective/
• https://docs.hyperweb.io/auth

Claim: Validator consensus signing uses Ed25519 (pubkey type /cosmos.crypto.ed25519.PubKey). 0% of the ~50-60 active validators use any PQC consensus key. CometBFT/Tendermint consensus is entirely classical.

Coverage basis: CometBFT v1.0.x uses Ed25519 for validator signatures. Confirmed by architecture docs, LayerQu analysis, and standard Tendermint specifications.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Consensus finality and validator authentication remain entirely Ed25519 (Shor-breakable). Cap: 70.

Assurance: High confidence: validator key types are observable on-chain via the Cosmos SDK staking module. All active validators use ed25519 keys.

Quantum-enabled validator key recovery would allow consensus manipulation, finality reversal, and validator impersonation. The validator set is capped at 60 with a single-client implementation (injectived).

• https://injective.com/blog/understanding-injective-architecture-and-consensus
• https://layerqu.com/chains/injective/
• https://docs.tendermint.com/master/tendermint-core/consensus/

Claim: Injective uses SHA-256 (Cosmos-side) and Keccak-256 (EVM-side) for state hashing. No KZG/pairing-based commitments are used. However, state integrity ultimately depends on validator consensus (Ed25519), which is quantum-vulnerable.

Coverage basis: Hash functions are Grover-weakened (128-bit security) but not catastrophically broken. No pairing-based cryptographic commitments identified in the protocol design.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Hash-based state integrity (Merkle trees, tx hashes) has partial quantum resistance (128-bit Grover). However, block certification and state binding depend on Ed25519 validator signatures, which are Shor-breakable. No independent audit of state-integrity mechanisms for quantum resistance.

Partial credit (0.25) for hash-based design without pairing/KZG dependencies. The absence of KZG commitments and ZK proof systems means Injective avoids the most severe quantum-vulnerable structural assumptions, but state binding remains gated by classical consensus signatures.

• https://injective.com/blog/understanding-injective-architecture-and-consensus
• https://layerqu.com/chains/injective/
• https://github.com/InjectiveFoundation/injective-core

Claim: Injective is a transparent (pseudonymous) blockchain with no shielded transactions, zero-knowledge proof systems, note encryption, viewing keys, or stealth addresses.

Coverage basis: Injective uses Frequent Batch Auctions (FBA) for order-book privacy within auction intervals, but all transactions are published on-chain. No native privacy layer exists.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: N/A - no privacy layer to evaluate. FBA provides limited pre-trade confidentiality within auction intervals but is not a cryptographic privacy mechanism.

Marked N/A per QRI applicability rules: chain has no privacy layer. This is not scored; the weight is redistributed across remaining applicable subfactors.

• https://injective.com/blog/understanding-injective-architecture-and-consensus
• https://layerqu.com/chains/injective/

Claim: CometBFT P2P uses X25519/Ed25519 Noise-style handshake for validator-to-validator gossip. RPC/JSON-RPC endpoints use classical TLS with ECDHE + ECDSA/RSA certificates. Bridge relayer traffic uses classical TLS.

Coverage basis: Standard CometBFT/Tendermint P2P stack. LayerQu analysis confirms classical P2P authentication.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity is not consensus-critical, spend-critical, bridge-critical, or custody-critical. P2P compromise could affect liveness but not safety. Per QRI spec Section 11.2 example, P2P can be satisfied-by-design when network identity is not critical-path. However, given that no PQC exists anywhere, scored conservatively at 0.00.

P2P transport uses classical cryptography. In a chain with zero PQC deployment, P2P is a secondary concern relative to spend authorization and consensus. Does not independently change the quantum-risk posture.

• https://layerqu.com/chains/injective/
• https://docs.tendermint.com/master/tendermint-core/consensus/

Claim: Top wallets (Keplr, Leap, MetaMask) and hardware wallets (Ledger, Trezor) have no published PQC roadmap covering Injective signing surfaces. Ledger's PQC work is focused on its OS roadmap, not deployed in production.

Coverage basis: LayerQu analysis identifies Keplr (dominant Cosmos-native), Leap, and MetaMask (post-Native EVM) as top-3 wallets. None has PQC support for Injective.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Wallet ecosystem has no PQC support. Ledger multisig with EIP-712 signatures (mentioned in Vulcan upgrade) extends classical signing to institutional custody but introduces no PQC protection.

Wallet and custody workflows are downstream of protocol-level signature support. Without protocol-level PQC, wallet-level PQC is not possible. This subfactor reflects the ecosystem-wide absence of quantum-safe custody paths.

• https://layerqu.com/chains/injective/
• https://www.npmjs.com/package/@injectivelabs/wallet-ledger?activeTab=readme

Claim: 0% of Injective's value-at-risk is protected from quantum key-recovery attacks. All native circulating supply, treasuries, bridges, custody wallets, protocol-controlled assets, and long-exposure balances remain on Shor-breakable primitives.

Coverage basis: All active addresses use secp256k1/ethsecp256k1 or Ed25519. No PQC-protected accounts exist. Coverage: <25%.

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path. Cap: 55.

Assurance: High confidence: 0% PQC traffic is independently verifiable from mainnet. Injective Foundation has declared no position (option f: Undeclared) on quantum-vulnerable balance treatment. Exact market cap and TVL figures fluctuate; the material point is that ~100% of economic value is on quantum-vulnerable primitives.

Coverage scored at <25% (score 1/20 = 0.05). This is the lowest coverage band. Dormant holdings (validator self-stake, foundation treasury, early vesting wallets) have no identified migration or freeze path.

• https://explorer.injective.network/
• https://layerqu.com/chains/injective/
• https://www.coingecko.com/en/coins/injective-protocol

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to or protected by PQC on Injective. No critical wallet is inherently PQ-native.

Coverage basis: All critical wallets remain on classical ECC. Bridges (Peggy, Wormhole, IBC, Hyperlane) use classical signer sets. Foundation treasury, validator self-stake, and exchange-controlled INJ are all on quantum-vulnerable paths.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Major value pools (treasury, bridge, foundation, validator stake) remain quantum-vulnerable with no migration path. Cap: 70.

Assurance: High confidence: critical wallets are identifiable from on-chain data and bridge architectures. All use classical ECC with no PQC alternatives.

Bridge signer sets are especially critical: Peggy uses validator-orchestrated secp256k1 multisig; Wormhole uses 19-guardian secp256k1 multisig with 13-of-19 threshold; IBC uses Tendermint Ed25519 light-client proofs.

• https://layerqu.com/chains/injective/
• https://www.coingecko.com/en/coins/injective-protocol
• https://explorer.injective.network/

Claim: No identification, measurement, deprecation, migration, or freeze of legacy quantum-vulnerable balances has been performed. Injective Foundation has declared no position on quantum-vulnerable balance treatment (option f: Undeclared).

Coverage basis: LayerQu analysis confirms 'Declared option f, Undeclared.' No governance proposals, documentation, or public statements address legacy vulnerable balance treatment.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: absence of any quantum-vulnerable balance treatment is confirmed by exhaustive review of Injective Foundation communications, governance proposals, and documentation.

This subfactor captures the absence of even basic inventory work for quantum-vulnerable balances. Without identification and measurement, no migration planning can begin.

• https://layerqu.com/chains/injective/
• https://injective.valopers.com/proposals/

Claim: No public migration or protection roadmap exists. Injective Foundation has published no PQC milestones, no dated deliverables, and no governance proposal addressing quantum migration.

Coverage basis: LayerQu confirms zero published PQ milestones. Search of all governance proposals (619, 632, 650) reveals no quantum-related content. Injective blog and docs contain no PQC references.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQC roadmap or migration plan. Cap: 25 (roadmap/proposal only; no public code, prototype, or testnet).

Assurance: High confidence: absence of roadmap is confirmed by exhaustive search of official channels, governance proposals, GitHub repositories, and documentation.

Injective has demonstrated strong upgrade capability (multiple successful hard forks), but this general governance capacity has not been directed toward quantum migration planning.

• https://layerqu.com/chains/injective/
• https://injective.valopers.com/proposals/
• https://injective.com/blog/

Claim: No PQ/hybrid account creation exists. No wallet tooling supports PQC for Injective. No user-facing quantum warnings, migration prompts, or educational materials exist.

Coverage basis: All account creation follows classical Cosmos SDK and EVM patterns. No PQC transaction paths exist. Wallet ecosystem (Keplr, Leap, MetaMask) has no PQC support for Injective.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: absence of PQC tooling, paths, and education is confirmed across all wallet providers, documentation, and mainnet observable behavior.

Users can still create new quantum-vulnerable accounts by default with no warnings. All transaction paths remain ECC-only.

• https://docs.hyperweb.io/auth
• https://layerqu.com/chains/injective/
• https://explorer.injective.network/

Claim: No enforcement mechanisms exist for quantum migration. No exchange, custody, bridge, or wallet coordination for quantum safety has been initiated. No unsafe-path blocking exists.

Coverage basis: No governance proposals, documentation, or public statements address enforcement mechanisms. Bridge upgrades (e.g., Vulcan v1.20.0) address classical security only.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: absence of enforcement mechanisms is confirmed by governance proposal review and documentation search. Recent Vulcan upgrade (v1.20.0, June 2026) reinforced bridge security but with no quantum-related changes.

Injective has no consensus-embedded canary, no rate-limited spending rule, no honeypot, and no automated post-Shor response mechanism.

• https://injective.valopers.com/proposals/650
• https://layerqu.com/chains/injective/

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

Coverage basis: No quantum-specific security contacts, no quantum vulnerability disclosure process, and no quantum emergency governance path are documented. Injective's general security processes do not address quantum threats.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI spec Section 8.2: 'No formal quantum-specific incident-response playbook' does not create a Readiness & Risk Cap by itself. Recorded as assurance note.

The absence of quantum-specific incident response is noted as an assurance gap but does not independently reduce the QRI Score given the more fundamental absence of any PQC deployment or migration planning.

• https://layerqu.com/chains/injective/
• https://injective.com/

Claim: No NIST PQC algorithms (ML-DSA, ML-KEM, SLH-DSA, FN-DSA) are used in Injective's codebase or production environment. Zero PQC primitives deployed.

Coverage basis: LayerQu and source code review confirm zero PQC algorithm usage. Dependency tree contains no liboqs/PQCA/OQS Go bindings.

Implementation score: 0 · Evidence confidence: High

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

Assurance: High confidence: absence of PQC algorithms in the injective-core dependency tree is independently verifiable. No liboqs, PQCA, or OQS Go bindings in go.mod/go.sum.

This subfactor receives 0.00 because no PQC algorithms are in use. The positive case (using NIST-standardized PQC) cannot be scored when no PQC is deployed.

• https://github.com/InjectiveFoundation/injective-core
• https://layerqu.com/chains/injective/
• https://csrc.nist.gov/projects/post-quantum-cryptography

Claim: No independent audit of quantum-critical implementation exists. The Informal Systems audit (2021) covers classical protocol design only with no quantum or PQC scope.

Coverage basis: Informal Systems audit (2021) focused on spot/derivatives exchange module, oracle module, and insurance module. No quantum threat model, no PQC algorithm review, no quantum-aware cryptographic assessment.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The only available audit is from 2021, focused on classical protocol security. It is scope-mismatched for quantum-critical evaluation. Per QRI spec, this is an assurance-only caveat affecting Confidence, not QRI Score, since the absence of PQC is independently verifiable from public code.

No PQC-specific audit exists because no PQC implementation exists to audit. This subfactor cannot be scored positively until PQC deployment begins.

• https://github.com/informalsystems/audits/blob/main/Injective/informal-report-injective-audit-202106.pdf
• https://injective.com/blog/injective-passes-the-informal-systems-audit-with-flying-colors

Claim: injective-core is open-source (GitHub) and buildable from source. However, this subfactor evaluates the PQC implementation, which does not exist.

Coverage basis: injective-core repository is public with build instructions. No PQC code exists within it.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The classical codebase is open-source and reproducible, which is positive for future PQC integration but provides no current quantum protection. Scored 0.00 because there is no PQC implementation to evaluate for reproducibility.

Open-source nature of the codebase is a necessary precondition for PQC deployment but not sufficient for scoring this subfactor.

• https://github.com/InjectiveFoundation/injective-core

Claim: Injective's Cosmos SDK architecture supports governance-driven hard-fork upgrades with modular keepers. The project has demonstrated upgrade capability (Cosmos SDK bumps, Native EVM, Vulcan). However, no specific PQC parameter agility or cryptographic upgrade path is documented.

Coverage basis: Multiple successful mainnet upgrades demonstrate architectural upgrade capability. Cosmos SDK modularity and CosmWasm custom signature verification provide theoretical PQC migration paths, but none are specified or planned.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Injective's upgrade track record is strong (v1.11 Cosmos-SDK + CometBFT, Native EVM 2025-11-11, Vulcan v1.20.0 June 2026). However, no in-place algorithm hot-swap has been demonstrated and no PQC-specific parameter agility is documented. Score 0.25 reflects architectural possibility without specification.

Cosmos SDK's AnteHandler architecture and CosmWasm's custom signature verification provide theoretical paths for PQC integration, but this remains entirely speculative without project commitment.

• https://injective.valopers.com/proposals/650
• https://injective.valopers.com/proposals/632
• https://injective.valopers.com/proposals/619
• https://layerqu.com/chains/injective/

Claim: No PQC signatures are in use, so stateful-signature safety considerations (XMSS/LMS anti-reuse controls, signing-state discipline) are not applicable. No side-channel or fault-injection analysis for PQC implementations exists.

Coverage basis: No PQC deployment means these considerations have not been addressed.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: This subfactor becomes relevant only when PQC signatures are deployed. The absence of PQC deployment means these risks have not been considered in any Injective-specific context.

Scored 0.00 because no PQC implementation exists to evaluate for stateful-signature safety or side-channel resistance.

Claim: No performance or resource-impact analysis for PQC deployment exists. Injective Foundation has not published any analysis of how PQC signature sizes, verification times, or memory requirements would affect Injective's 0.65s block time, 25,000 TPS target, or validator/node hardware requirements.

Coverage basis: No PQC footprint analysis from Injective Foundation. LayerQu confirms 'Undisclosed (no PQ scheme selected, no on-chain footprint analysis).'

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI spec Section 8.2: 'No formal performance/resource benchmark' does not create a Readiness & Risk Cap by itself. This is recorded as a note-only caveat given the more fundamental absence of PQC deployment.

Injective's high-performance architecture (0.65s block time, 25K TPS claimed) would face significant challenges from large PQC signature sizes. No analysis of this compatibility has been performed.

• https://layerqu.com/chains/injective/
• https://injective.com/blog/understanding-injective-architecture-and-consensus