AKASH NETWORK · L1 · STAGE 0 UNAWARE · QRI 22 v3.1.0 methodology

In plain terms

What it is. Akash is a marketplace where people rent out spare computing power to each other, and today it protects every account, validator, and rental contract with the kind of math a future quantum computer is expected to break.

What we found. Renting compute means there is extra security between providers and tenants on top of what a normal network of this type carries, and none of it, not the core network and not the rental layer, has any plan or working code to move to quantum-safe protection.

Why it matters. If a powerful quantum computer arrives before any of this is upgraded, an attacker could forge past approvals or impersonate accounts, providers, and rental agreements, and the team has not said publicly what would happen to people's funds if that day comes.

Akash is a Cosmos appchain (CometBFT consensus, Cosmos SDK v0.53 since Mainnet 14 on 2025-10-28) using Ed25519 validator consensus signatures and secp256k1 ECDSA for AKT account signing. The provider/tenant marketplace adds an mTLS surface (ECDSA secp256k1 client certificates, 365-day default lifespan) plus on-chain auditor signatures over provider attributes, extending the classical-crypto blast radius beyond the standard Cosmos baseline. No PQC ADR, no PQ roadmap, no named PQ migration lead.

inLinkedIn ↷Audit access ⇆Compare Verified 2026-05-02

Summary

Akash scores QRI 22, Band 3 Planning, Migration Stage 0. Validator consensus uses CometBFT-default Ed25519; AKT account signatures use secp256k1 ECDSA (R||S, SHA-256 digest); SHA-256 for block and IBC commitment hashing; X25519/Ed25519 for CometBFT p2p secret-connection handshake. Provider/tenant marketplace authentication uses mTLS with ECDSA secp256k1 client certificates (365-day default) plus on-chain auditor signatures over provider attributes, an extra classical-crypto surface beyond the Cosmos baseline. Mainnet 14 (block #23939793, 2025-10-28) shipped Cosmos SDK v0.53 (Olympus), inheriting consensus-key-rotation and the x/accounts module. Akash is IBC-connected, so historical Ed25519 validator-set signatures sit in the IBC light-client trust path. No PQC scheme merged into akash-network/node, akash-network/provider, or any canonical client. No Akash Foundation or Overclock Labs public communication on PQ migration. No PQ wallet, no PQ bridge, no PQ custodian, no PQ HSM in the supply chain. mainnet-traffic cap binds at 5a=0%. Architecture-Execution Gap binds. The provider-attestation mTLS surface is the differentiator from a vanilla Cosmos appchain and pulls Dim 1 and Dim 6 marginally lower than the Hub.

What the gates say

Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition AND or OR on Akash; no ADR, no roadmap, no spec; provider-side mTLS also classical ECDSA secp256k1
Gate 1a, Hybrid KEM: FAIL , CometBFT secret-connection X25519, RPC TLS classical X25519/RSA, provider mTLS classical ECDH; no hybrid PQ KEM deployed
Gate 1b, Commit-to-hash: COND , only relevant if 1a-Sig passes via OR-composition
Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts within 48 hours
Gate 3, Primitive naming: PASS , primitives named at every sub-score

Burn-vs-rescue policy on file

Declared option f, Undeclared. No published Akash policy on what happens to AKT at quantum-vulnerable accounts post-CRQC. No freeze/burn proposal, no STARK rescue, no rate-limit canary, no client-layer hybrid migration framework. No published policy on the provider/tenant mTLS layer either.

Seven dimensions

Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.

1 Cryptographic Exposure weight 15% 26 / 100

1a · primitive inventory 13 / 20

Inventory clear and reconstructible from CometBFT, Cosmos SDK, and akash-network/provider docs/code. The mTLS provider/tenant surface is the Akash-specific differentiator from vanilla Cosmos.

Primitives: Ed25519 (CometBFT validator consensus signing, default per priv_validator_key.json and cometbft init) · secp256k1 ECDSA (Cosmos SDK account signatures for AKT, R||S lower-S form, SHA-256 message digest) · secp256k1 ECDSA (provider/tenant mTLS client certificates, 365-day default lifespan) · SHA-256 (block hashing, IBC commitment hashing) · X25519/Ed25519 (CometBFT p2p secret connection handshake) · Standard TLS for RPC/REST and provider gRPC endpoints

1b · shor grover pq tag 5 / 20

No PQ-safe primitive in active use anywhere in the Akash stack.

Tags:

Ed25519 → Shor-break-via-DL-without-pairings
secp256k1 ECDSA (account) → Shor-break-via-DL-without-pairings
secp256k1 ECDSA (mTLS) → Shor-break-via-DL-without-pairings
SHA-256 → Grover-weaken (256→128-bit)

1c · family diversity 0 / 20

0 PQ families. Two classical families (Edwards-curve EdDSA, Weierstrass-curve ECDSA), neither PQ-safe; the diversity rubric counts PQ families.

1d · nist security category 2 / 20

Ed25519 ≈ 128-bit classical / 0-bit post-Shor; secp256k1 ECDSA ≈ 128-bit classical / 0-bit post-Shor; SHA-256 ≈ 128-bit post-Grover. No NIST PQC category mapped because no NIST PQC primitive in scope.

1e · implementation quality 6 / 20

CometBFT consensus inherits TLA+ specification and machine-checked safety proofs; underlying Ed25519 / secp256k1 libraries are standard Go implementations (crypto/ed25519 constant-time; btcec/dcrec for secp256k1). Provider mTLS uses standard Go crypto/tls with ECDSA secp256k1, no machine-checked PQ-relevant proofs. Tier 1 (mature classical EC + SHA-2). No PQ implementation.

2 Quantum Recovery Exposure weight 10% 22 / 100

Forge subtotal: 17/75 Decrypt subtotal: 5/25

2a · active key exposure 5 / 25

akash1… accounts derive from secp256k1 pubkey hash (RIPEMD-160(SHA-256(compressed pubkey))) per Cosmos SDK convention. Pubkey is published on-chain on first outbound tx, so any account that has ever signed has its pubkey publicly recorded, Shor-forgeable post-CRQC.

2b · cold key exposure 6 / 25

Accounts that have never signed retain pubkey-hash protection; accounts that signed once retain exposed pubkeys indefinitely. Akash mainnet has been live since 2020-09 (Mainnet 1), so a non-trivial fraction of cold AKT supply has revealed pubkeys at some point. No public study quantifies the unmoved-only-incoming fraction.

2c · sig long term validity 6 / 25

Every historical Ed25519 validator vote and secp256k1 account signature is forgeable after CRQC. IBC light-client checkpoints rely on Ed25519 validator-set signatures: a CRQC adversary can forge a valid-looking historical Akash header against any Tendermint light client trusting historical validator-sets. Lease and deployment manifests carry historical secp256k1 ECDSA mTLS signatures, also forgeable.

2d · encryption confidentiality hndl 5 / 25

CometBFT p2p secret connection uses X25519 ECDH (Shor-vulnerable). RPC/REST and provider gRPC use standard TLS (classical X25519 / RSA / ECDH). Provider/tenant mTLS handshake uses classical ECDH. No hybrid PQ KEM deployed. Validator gossip, mempool, and provider control plane all sit fully in classical-DH HNDL scope.

3 Metadata, Anonymity & Confidentiality weight 13% 19 / 100

3a · tx graph visibility 5 / 20

Fully transparent ledger; akash1… addresses pseudonymous; deployment-bid-lease tuples (DBL) are public on-chain, linking tenants to providers in the clear.

3b · rpc mempool concentration 5 / 20

Public RPC concentrated among a handful of operators (Akash Foundation, Polkachu, Allnodes, Lavender.Five). Mempool gossip observable to any validator-grade node. Provider gRPC endpoints addressable by URI from on-chain provider records, deployment traffic correlatable to tenants.

3c · cross chain bridge correlation 4 / 20

IBC channels link Akash to Cosmos Hub and other zones, cross-chain AKT flows directly linkable. AKT also bridged to Ethereum via Axelar / wAKT paths, EVM-side correlation straightforward.

3d · retroactive de anonymization 5 / 20

Akash does not publish encrypted payload data, ZK-shielded transactions, or DL-based ring signatures. Confidentiality risk from Shor on its curves limited to long-term cryptographic identity correlation rather than payload decryption. Workload contents on provider hardware are not protocol-encrypted, confidentiality is a deployment-layer concern, not a chain-layer one.

3e · mixnet shuffle 0 / 20

None at protocol level.

4 Migration Architecture weight 10% 54 / 100

4a · crypto agility 6 / 15

Inherits Cosmos SDK crypto/keys modular structure, new schemes added historically (sr25519, secp256r1) at SDK level. CometBFT --key-type flag selects validator consensus key type at init. Mainnet 14 (2025-10-28) jumped Akash from SDK v0.45 to SDK v0.53 in a single upgrade, showing the chain can absorb large architectural deltas. No production instance of a validator-consensus-key-type swap on Akash mainnet, agility architectural, not demonstrated for crypto rotation.

4b · aa key rotation 8 / 20

Inherits ADR-016 validator consensus key rotation and the x/accounts module from SDK v0.53 (Olympus). x/authz and x/feegrant live. No native account abstraction comparable to ERC-4337. No documented client-layer PQ migration path. Provider/tenant mTLS supports certificate rotation (365-day default lifespan), rotation muscle exists at the marketplace layer.

4c · hard fork track record 11 / 15

Strong execution cadence. Mainnet 14 (block #23939793, 2025-10-28) shipped Cosmos SDK v0.53 + CometBFT modernization in a coordinated upgrade, a multi-version SDK jump executed cleanly under on-chain governance. Earlier coordinated upgrades (Mainnet 4, 6, 9, 11) sustained through 2021-2025.

4d · hybrid deployment readiness 5 / 15

Architecturally constructible (cometbft init --key-type accepts multiple consensus key types; SDK crypto/keys modular). No spec proposal or AEP for a hybrid Ed25519+PQ scheme on Akash. No hybrid plan for the provider mTLS layer either.

4e · stateful hash state management 15 / 15

N/A by default, no stateful hash scheme in scope; stateless schemes score full per v3.1 rubric.

4f · bft aggregation path 0 / 20

N/A. Akash uses Ed25519 non-aggregating signatures at consensus per CometBFT default. BLS not in the Akash consensus path. Per v3.1 rubric, 4f is N/A for non-aggregating-signature consensus.

5 Deployment Execution weight 22% 13 / 100

5a · mainnet pqc traffic pct 0 / 25

0% of validator votes, AKT account signatures, or provider-tenant mTLS handshakes on Akash mainnet under a PQC primitive.

5b · pqc code in consensus client 1 / 15

No PQC scheme merged into akash-network/node, akash-network/provider, akash-network/cosmos-omnibus, or upstream cometbft/cosmos-sdk main crypto/keys. No internal PQ branch published by Overclock Labs or Akash Foundation.

5c · validator pqc key adoption 0 / 15

All active Akash validators use Ed25519 consensus keys per CometBFT default. No validator has registered a PQC consensus key. No provider has registered a PQC mTLS certificate.

5d · published dated milestones 0 / 10

VOIDED to 0 per v3.1 rule (5a = 0). No dated, enforcement-mechanism-backed PQC milestones for Akash mainnet (no flag-day, no sunset, no PQ-validator-key registration deadline, no mTLS PQ migration date). The Akash 2025 roadmap covers compute spend, tokenomics, Homenode, and agent-meta, no PQ line item.

5e · pqc washing delta 12 / 15

Announced PQC trailing-12-mo from Akash Foundation / Overclock Labs: ~0 official communications. Shipped PQC: 0. Ratio undefined / low. No washing detected (no claims to deflate).

5f · signature footprint multiplier 0 / 20

No PQ deployment, no published bytes-per-block analysis under any PQ scheme for Akash.

6 Supply Chain Vendor Readiness weight 22% 7 / 100

6a · wallet 2 / 25

Top-3 wallets supporting AKT: Keplr, Leap, Ledger HW. None publish a PQC roadmap. Ledger HW has internal PQC research at Ledger Donjon but no shipped PQ-signing for Cosmos SDK / Akash accounts.

6b · bridge 2 / 25

Top bridges in AKT flow: IBC (light-client model, Ed25519 verification), Axelar (BLS + Ed25519, classical) for AKT-to-EVM. None publish a PQC roadmap. IBC v2 / IBC Eureka work targets ZK-Tendermint-light-client, succinctness, not PQ.

6c · custodian 1 / 25

Institutional AKT custody coverage thinner than ATOM. Coinbase, Kraken (custodial), and a handful of Cosmos-native custodians cover AKT. None publish an Akash-specific PQC roadmap. None have MPC-PQ in production for AKT signing.

6d · rpc hsm tee infra 2 / 25

RPC providers (Akash Foundation, Polkachu, Allnodes, Lavender.Five) publish no PQ-enabled TLS. Validator HSMs follow Cosmos norms (YubiHSM2 / Thales / AWS KMS), no PQ signing for Ed25519/secp256k1. The provider stack (Kubernetes operators, akash-network/provider services) uses standard mTLS with ECDSA secp256k1, no PQ certificates. Hardware attestation roadmap announced (TEE / confidential computing) targets workload integrity, not signing-primitive PQ.

7 Governance & Coordination weight 8% 42 / 100

7a · validator stake distribution 9 / 20

~100 active validators. Stake concentration broadly comparable to mid-cap Cosmos appchains; reported Nakamoto coefficient typically 5-7 with top operators (Allnodes, P2P, Cosmostation, Stakefish) carrying material weight. Client diversity weak: universal CometBFT (no second consensus client).

7b · upgrade cadence under pressure 12 / 20

Mainnet 14 (2025-10-28) executed multi-version Cosmos SDK jump (v0.45→v0.53) cleanly. Earlier mainnet upgrades sustained through 2021-2025. Less stressed-upgrade history than Cosmos Hub (no equivalent of Hub v19.2 emergency).

7c · named coordination lead 11 / 20

Akash Network Foundation (foundation), Overclock Labs (core engineering, founders Greg Osuri / Adam Bozanich), validator coalition. Clear named ownership at chain level. No named PQC migration lead. No PQ working group, no PQ AEP.

7d · adversarial coordination precedent 10 / 20

Active on-chain governance with 280+ proposals; tokenomics overhauls (Mainnet 14 path) ratified on-chain. No precedent of a coordinated cryptographic-primitive change while under attacker pressure.

7e · canary tripwire mechanism 0 / 20

No canary, honeypot, rate-limited spending rule, or cryptographic tripwire on Akash.

X + Y vs Z, when does the math turn against you?

v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?

X, signature shelf life

5–15 years, historical Ed25519 validator votes and secp256k1 account signatures sit on-chain indefinitely; IBC light-client checkpoint trust extends sig validity downstream; provider/tenant mTLS material rotates on 365-day default but lease and deployment manifests carry the ECDSA signature trail

Y, migration time

5–10 years to Stage 5, given current Stage 0, a hybrid ADR + Cosmos SDK / CometBFT main-branch merge + ~100–150 validator coordinated rotation + provider/tenant mTLS scheme upgrade + IBC counterparty alignment is multi-year minimum

Z10 (10% CRQC year)

2030

Z25 (25% CRQC year)

2035

Verdict

X+Y > 2035, Outside risk window vs Z25; X+Y > 2030, Crisis Zone vs Z10

Z-compliance

Outside compliance window, AKT faces the 2035 disallowance for any classical PK still in active validator-key, account-signing, or provider-mTLS scope

Source-disagreement disclosure

v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.

Cosmos SDK inheritance vs Akash-specific surface

Akash inherits CometBFT/Cosmos SDK consensus and account cryptography wholesale; the marketplace layer (provider attestation, tenant mTLS, lease/manifest signing) is Akash-specific and adds classical-crypto surface area not present on a vanilla Cosmos appchain. Scoring weights both: consensus path pulls from the Cosmos baseline, marketplace path pulls 6a/6d down.

Hardware attestation roadmap

Akash announced hardware verification via attestation (TEE / confidential-computing path) ahead of full GA. That roadmap targets workload integrity, not PQC of the signing primitives. Card does not credit it as PQ progress.