Kaia

Is Kaia quantum-safe?

Where we are making a judgement call Four judgement calls carry this profile. The first and largest is the tier. The Kaia DLT Foundation, the chain's own authority, is a party to a three-year commercial agreement under which BTQ and the foundation say they will introduce quantum-safe security across Kaia's transaction and settlement infrastructure. We do not read that as Tier 4 or Tier 3. It is a commercial agreement announced by the vendor, not an improvement proposal or a research programme; it names no scheme and describes no mechanism; and BTQ's own published account of the product, from June 2025, dual-signs a stablecoin issuer's privileged operations such as minting and burning while leaving holders' transfers and keys unchanged, which is not a change to the signatures that authorise holders' spends. A reader who counts the agreement as documented post-quantum work by the chain's authority would place Kaia in Tier 4 and add 2.5 points; a reader who counts it as a funded plan would place it in Tier 3 and add 10 points before any change to NIST alignment. The second is NIST alignment: ML-DSA appears in BTQ's description of its product, not in the Kaia agreement, so it is not counted; a reader who counts it would score 3 and add 4.5 points. The third is migration. The account update mechanism is credited above the floor because it exists on mainnet and keeps the address, even though it can only install secp256k1 keys today; a reader who credits nothing short of a post-quantum key type would score 2 and take 1.5 points off. The fourth is verification: BTQ markets post-quantum security for Kaia, but for a product not yet deployed and outside the fund-protecting signatures, so it is not read as Kaia marketing itself as quantum-safe; a reader who does would score 1 and take 0.5 points off.

At a glance

Cryptography in use

• Account signatures ECDSA on secp256k1 Mainnet, mandatory Account public keys must lie on the S256 curve; legacy, public, weighted multisig and role-based account keys all verify secp256k1 signatures. Source code or release
• Validator consensus ECDSA on secp256k1 Mainnet, mandatory Committed seals in Kaia's Istanbul BFT variant are signed with crypto.Sign on secp256k1. Source code or release
• Randomness BLS signatures on BLS12-381 Mainnet, mandatory KIP-114 randomReveal: the proposer signs the block number with its BLS12-381 key from the KIP-113 registry. Active since the Randao hard fork on 4 March 2024. Specification or proposal

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

How it compares

Roadmap

1. 29 August 2024 shipped

   The Kaia transition hard fork activates at block 162,900,480, described by Kaia as the transition from Klaytn to the Kaia blockchain. Accounts continue to sign with secp256k1 keys. source

2. 17 July 2025 shipped

   The Prague hard fork activates on mainnet, adding EIP-7702 SetCode transactions under KIP-228. A delegated account still obeys its original ECDSA key, so delegation offers no route off a secp256k1 key. source

3. 30 September 2026 planned

   BTQ Technologies announces a three-year commercial agreement with the Kaia DLT Foundation to deploy its Quantum Secure Stablecoin Network across Kaia, protecting stablecoins at the account level. No scheme, date or technical design is published. source

4. No date published proposed

   No Kaia Improvement Proposal, research programme, implementation or testnet for post-quantum account or validator signatures was found at the time of writing. source

If holders never migrate

No stated policy

Neither the Kaia DLT Foundation nor the KIP process has said anything about accounts that never move to post-quantum keys. The BTQ announcement describes protection applied at the account level without saying how, or what happens to accounts it does not reach.

As of 22 October 2026. source Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.

A legacy Kaia account follows Ethereum's address model: the address is derived from a hash of the public key, so an account that has received funds but never signed has not published its key. Kaia adds two cases of its own. An account that has replaced its key through an account update transaction stores the new public key in its account state, so that key is public from the moment of the update, whether or not it has signed. And because a legacy account uses the same keys and addresses as Ethereum, a key that has signed on any EVM chain exposes the same address on Kaia. Validator signing keys and their BLS keys in the KIP-113 registry are public by design. Kaia continues Klaytn's own chain, so its history is its own; Finschia's holders moved across through a token swap bridge rather than a fork, and the exposure inheritance rule does not apply.

Questions

Sources

1. Kaia node client Kaia (GitHub) · primary · checked 22 October 2026
2. Account key public key type (blockchain/types/accountkey/public_key.go) Kaia (GitHub) · primary · checked 22 October 2026
3. Account key types (blockchain/types/accountkey/account_key.go) Kaia (GitHub) · primary · checked 22 October 2026
4. Istanbul sealer (consensus/istanbul/sealer.go) Kaia (GitHub) · primary · checked 22 October 2026
5. Accounts Kaia documentation · primary · checked 22 October 2026
6. Consensus mechanism Kaia documentation · primary · checked 22 October 2026
7. Account update Kaia documentation · primary · checked 22 October 2026
8. Kaia hard fork history Kaia documentation · primary · checked 22 October 2026
9. Klaytn hard fork history Kaia documentation · primary · checked 22 October 2026
10. Finschia to Kaia Kaia documentation · primary · checked 22 October 2026
11. Kaia Improvement Proposals Kaia (GitHub) · primary · checked 22 October 2026
12. KIP-113: BLS public key registry Kaia (GitHub) · primary · checked 22 October 2026
13. KIP-114: Supplant DIFFICULTY opcode with RANDOM Kaia (GitHub) · primary · checked 22 October 2026
14. KIP-228: SetCode for EOA Kaia (GitHub) · primary · checked 22 October 2026
15. Kaia Governance Forum Kaia · primary · checked 22 October 2026
16. BTQ Technologies to Bring Post-Quantum Security to LINE NEXT's Unifi Wallet Under Commercial Agreement with Kaia DLT Foundation BTQ Technologies (Cision) · primary · checked 22 October 2026
17. Future-Proofing Stablecoins: How BTQ's QSSN Secures Digital Money for the Quantum Era BTQ Technologies · primary · checked 22 October 2026
18. FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA) NIST · primary · checked 22 October 2026

@misc{hardyindex_kaia_2026,
  author       = {{The Hardy Index}},
  title        = {Kaia: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/kaia}},
  note         = {Hardy Score 10.0 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-04}
}