1 Signature scheme 0/10, weighted 30%
Band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.
AKT accounts sign with ECDSA on secp256k1: all 279 transaction signers in mainnet blocks 29,178,700 to 29,178,740, read from the chain on 22 October 2026, carry secp256k1 keys. Validators sign with Ed25519. Akash's SDK fork adds no other key type, so nothing post-quantum protects AKT on mainnet.
source
2 Deployment stage 1/10, weighted 25%
Band 1: Tier 5: Exposed.
Tier 5: Exposed. The signatures securing AKT are quantum-vulnerable, and we found no post-quantum plan, proposal or research programme from Akash: none in the Akash Economic Proposals repository, the 2026 roadmap, the node releases or the governance proposals the chain's API returns. The ML-DSA work in Cosmos SDK v0.55 belongs to the upstream framework, whose maintainers have no authority over Akash's fork.
source
3 NIST alignment 0/10, weighted 15%
Band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.
No post-quantum scheme has been named for Akash's accounts or validators. ML-DSA-65, from the final FIPS 204, exists in Cosmos SDK v0.55, but Akash pins its own fork of v0.53.7, and nobody with authority over Akash has referred to it.
source
Placement in the band The floor of the band rather than a 1 or a 2: Akash itself has named no scheme at any point. Crediting the upstream ML-DSA option would score a framework Akash has not adopted rather than the chain.
4 Migration path 2/10, weighted 15%
Band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.
No post-quantum migration plan has been published. A route exists upstream: under Cosmos SDK v0.55 a holder creates a new ML-DSA account and transfers funds to it, and a validator rotates its consensus key in place. None of it applies until Akash carries its fork onto that release line, and its governance does ship software upgrades routinely: seventeen software-upgrade proposals have passed since 2021, the latest bringing v2.1.0 in June 2026.
source
Placement in the band The top of the band rather than a 1: a working mechanism exists in the framework Akash is built on, and its governance has a long record of coordinated software upgrades. It cannot reach 3, because Akash has not acknowledged quantum migration as a problem anywhere we could find.
5 Exposure 2/10, weighted 10%
Band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.
A Cosmos SDK account address is a hash of the secp256k1 public key, so an account that has never signed keeps its key off the chain. The key is recorded with the account's opening transaction, and staking AKT or paying for a deployment needs a signed transaction, so actively held AKT sits behind a revealed key. Validator consensus keys are published by design. No measurement of the exposed share has been published.
source
Placement in the band The top of the band rather than a 3: the address structure is the same as on other Cosmos SDK key-hash chains, where any send or delegation reveals the key. It is not a 0 or a 1 because never-used addresses do keep their keys hidden.
6 Verification 2/10, weighted 5%
Band 0 to 2: No post-quantum component exists, or the claims rest on marketing.
No post-quantum component protects Akash, so there is nothing to verify. Its SDK fork carries the same key types as upstream v0.53, secp256k1, secp256r1, Ed25519 and multisig, and no ML-DSA. Under v1.8 the openness of the classical code earns nothing here.
source
Placement in the band The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about the chain is marketed as quantum-safe, so its position does not rest on marketing.