What it is. Kaia is the public blockchain formed when the Klaytn and Finschia networks merged in August 2024, and it still carries the whole Klaytn transaction record going back to 2019.
What we found. The only quantum-safe headline attached to Kaia came from an outside security company describing a Korean bank pilot, and that company's own later reports do not name Kaia, with its most recent update calling the relationship a discussion.
Why it matters. Kaia itself has named nobody to lead a change and put no date on one, so every balance and every past transaction on the chain stays protected by keys a future quantum computer is expected to break.
Kaia mainnet signs both account transactions and IBFT block seals with ECDSA secp256k1, hashes with Keccak-256, and holds its BLS12-381 KIP-113 registry keys for KIP-114 randomness and KIP-146 proposer selection rather than for quorum signing, with no post-quantum primitive live on mainnet, running on testnet, or written into any proposal: a full clone and case-insensitive grep of kaiachain/kaia at head on 2026-08-19 found no implementation of ML-DSA, SLH-DSA, Falcon, XMSS or ML-KEM, none of the 28 Core KIPs covers post-quantum signatures, and the governance forum search API returns an empty set for quantum and post-quantum. The single post-quantum signal is a vendor's: BTQ Technologies announced on 2026-05-06 that its QSSN would pair ECDSA with ML-DSA (FIPS 204, no parameter set named) on a bank-led KRW stablecoin proof-of-concept built as ERC-4337 smart accounts that require no protocol modification, so Kaia's own validation path checks only the ECDSA secp256k1 signature, Gate 1a-Sig and Gate 1a-KEM fail, and the mainnet-traffic cap binds at 5a = 0% with Migration Stage 0.
Summary
Kaia scores QRI 20, Band 2 Acknowledged, Migration Stage 0. Accounts sign ECDSA secp256k1 with 33-byte SEC1 compressed public keys recovered through ecrecover, and the inherited AccountKey schema (Legacy, Public, Fail, WeightedMultiSig, RoleBased) separates keys from addresses, so a key rotates without a new address, though every type is still secp256k1. IBFT seals are individual 65-byte ECDSA signatures with no aggregation: a live header decode on 2026-08-19 returned 33 validator addresses, one proposer seal and 22 committed seals, matching calcQuorumSize = ceil(2N/3) over a 33-member council. BLS12-381 keys in the KIP-113 registry cover KIP-114 randomness and KIP-146 proposer selection, not quorum signing. Node transport is RLPx: an ECIES handshake on secp256k1 with AES-128-CTR and HMAC-SHA-256, then frames under AES-256-CTR with a Keccak-256 MAC. Foundation RPC endpoints negotiate X25519 under TLS 1.3 and answer a hybrid-only client hello with handshake_failure, so Gate 1a-KEM fails. No post-quantum KIP sits among the 28 Core KIPs, and a full grep of kaiachain/kaia at head on 2026-08-19 returned zero post-quantum code. The mainnet-traffic cap binds at 5a = 0%, the Architecture-Execution Gap is 55, and the Supply-Chain cap fires across all four vendor tiles.
Forge. Forge-dominant: this chain secures value and operations with signatures, so the principal quantum risk is forgery of spends and attestations once Shor breaks the curve. There is no harvest-now component for forgery, the public key alone enables it. Decrypt/HNDL applies only to transport and RPC confidentiality.
1 announced → 0 shipped on mainnet under a named primitive. narrative-only-vendor.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition AND or OR on Kaia; no KIP, no roadmap, no spec
- Gate 1a, Hybrid KEM: FAIL , validator peer-to-peer transport is RLPx, whose asymmetric step is an ECIES handshake on secp256k1 with AES-128-CTR and HMAC-SHA-256, with the resulting frame channel under AES-256-CTR and a Keccak-256 MAC; no PQ KEM anywhere in the stack. The Foundation public RPC endpoints negotiate classical X25519 under TLS 1.3 and answer a hybrid-only client hello with a handshake_failure alert, observed 2026-08-19. Observed but not gate-qualifying: three third-party public endpoints listed in Kaia's own endpoint table (BlockPI, dRPC, QuickNode) negotiate X25519MLKEM768 at their CDN edge; this is not stated anywhere in Kaia's documentation and is not an operator policy
- Gate 1b, Commit-to-hash: COND , only relevant if 1a-Sig passes via OR-composition
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible within 48 hours from the public Kaia documentation site, the kaiachain/kaia Go client, the kaiachain/kips repository, the public governance forum and its search API, live public-RPC queries including kaia_getCouncil, kaia_getBlsInfos and a raw IBFT extraData decode, the vendor's press releases, and the vendor's SEC EDGAR Form 6-K filings
- Gate 3, Primitive naming: PASS , primitives named at every sub-score
Burn-vs-rescue policy on file
Declared option f, Undeclared. No published Kaia policy on what happens to KAIA at quantum-vulnerable accounts post-CRQC. No freeze/burn proposal, no rescue scheme, no rate-limit canary, no client-layer hybrid migration framework. Permissioned GC structure means a Foundation-driven rescue path is the operational base case but not declared policy.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 24 / 100
Kaia's published inventory is incomplete for its highest-value primitives: the user-facing accounts, transactions and consensus pages never write ECDSA, secp256k1 or Keccak, naming only 'a compressed public key on S256 curve' with SEC1 encoding, and the v1.3 white paper names IBFT, VRF proposer selection and the SimpleBlsRegistry but no signature or hash algorithm. Precise naming exists only in the KIP repository (KIP-113 and KIP-114 give the exact BLS ciphersuite string, key and proof-of-possession sizes; KIP-279 cites EIP-4844 and EIP-7594) and in the kaiachain/kaia client source (crypto/, consensus/istanbul/, blockchain/types/accountkey/, networks/p2p/rlpx/, blockchain/vm/contracts.go). No consolidated cryptography reference page exists; foundation, KIP and client surfaces checked 2026-08-19.
ECDSA secp256k1 (account signing; 33-byte SEC1 compressed public keys; (V, R, S) signature tuples; signer recovered via ecrecover) · ECDSA secp256k1 (IBFT proposer seal and per-validator committed seals, 65 bytes each, recovered via ecrecover; inherited from Klaytn) · BLS12-381, ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ per draft-irtf-cfrg-bls-signature-05 (KIP-113 SimpleBlsRegistry validator keys, 48-byte compressed public key and 96-byte proof-of-possession; KIP-114 randomReveal and KIP-146 proposer selection; not quorum signing) · Keccak-256 (state, transaction and address hashing per EVM; address = Keccak-256(uncompressed pubkey[1:])[12:]) · RLP encoding for transaction and block-header serialization · KZG commitments on BLS12-381 (EIP-4844 point-evaluation precompile at address 0x0a, present since the Cancun hardfork, block 147,534,000, 2024-03-04; blob transactions themselves enabled at the Osaka hardfork per KIP-279 with mainnet blob target and max of 1) · secp256r1 (P-256) signature-verification precompile per EIP-7951 at address 0x0100 (Osaka hardfork, block 213,333,000, 2026-04-07) and BLS12-381 precompiles per EIP-2537 at addresses 0x0b-0x11 (Prague hardfork, block 190,670,000, 2025-07-17) · RLPx peer-to-peer transport: ECIES handshake on secp256k1 with AES-128-CTR and HMAC-SHA-256 over a NIST SP 800-56 concatenation KDF, then an established frame channel under AES-256-CTR keyed by Keccak-256 output, with a Keccak-256 MAC construction · TLS 1.3 on the Foundation public RPC endpoints (X25519 key agreement, RSA-2048 certificate signed sha256WithRSAEncryption, CertificateVerify observed as rsa_pss_rsae_sha256, observed 2026-08-19) No PQ-safe primitive in active use at the protocol layer. Kaia publishes no such classification itself; every tag here is LayerQu's.
ECDSA-secp256k1→ Shor-break-via-DL-without-pairingsBLS12-381→ Shor-break-via-pairings (KIP-113 registry / KIP-114 randomness surface)Keccak-256→ Grover-weaken (256→128-bit)KZG-BLS12-381→ Shor-break-via-pairings (blob data-availability commitments only; blob shelf life is the retention window, not permanent like a signature)secp256r1-precompile→ Shor-break-via-DL-without-pairingsECIES-secp256k1 (RLPx handshake)→ Shor-break-via-DL-without-pairingsAES-256-CTR (RLPx frame channel)→ Grover-weaken (256→128-bit)X25519 (RPC TLS)→ Shor-break-via-DL-without-pairings
0 PQ families deployed. Multiple classical families (Weierstrass-curve ECDSA on secp256k1 and secp256r1, pairing-friendly BLS12-381, classical Diffie-Hellman in transport) but none PQ-safe.
ECDSA secp256k1 ≈ 128-bit classical / 0-bit post-Shor; BLS12-381 ≈ 128-bit classical / 0-bit post-Shor; Keccak-256 ≈ 128-bit post-Grover; AES-256-CTR ≈ 128-bit post-Grover. No NIST PQC category mapped because no NIST PQC primitive is in scope.
Kaia Go client (kaiachain/kaia) descends from the Klaytn fork of go-ethereum; the live mainnet client version string is Klaytn/v2.2.2. secp256k1 is provided by the erigontech/secp256k1 CGO binding of libsecp256k1 with a decred dcrec/secp256k1 pure-Go fallback; consensus BLS12-381 (KIP-113/114) by supranational/blst v0.3.16; the EIP-2537 BLS12-381 precompiles by consensys/gnark-crypto; KZG by ethereum/c-kzg-4844 v2 and crate-crypto/go-eth-kzg. Release v2.2.2 (2026-03-10) ported two upstream go-ethereum cryptography fixes: PR 760 'crypto: Fix ECIES invalid-curve handling', rejecting invalid ephemeral public keys before ECDH in the RLPx handshake, and PR 761 'crypto/secp256k1: Fix coordinate check'. No machine-checked formal-verification artifacts are published for Kaia consensus or signature modules. Tier 1 (mature classical EC + Keccak).
2 Quantum Recovery Exposure weight 10% 19 / 100
EVM-style account model: the secp256k1 public key is recovered from every signed transaction (ecrecover), so it is exposed on first outbound transaction. Klaytn mainnet history from the genesis block (timestamp 2019-06-24 UTC) plus Kaia post-merger continuation, DeFi, LINE Messenger Mini DApps and stablecoin flows produce a revealed-public-key surface that LayerQu has not measured; no public Kaia-specific exposed-key study was located, and this remains a genuine evidence gap rather than a null finding.
Accounts that have never signed retain Keccak-derived address protection. AccountKeyLegacy matches the Ethereum EOA exposure model; AccountKeyPublic, AccountKeyWeightedMultiSig and AccountKeyRoleBased serialize 33-byte compressed secp256k1 public keys on-chain at registration (client source serializes them through CompressPubkey), exposing them independently of transaction history. The dormant-unrevealed share is unmeasured.
Every historical secp256k1 validator seal and account signature on Klaytn (2019-2024) and Kaia (2024-present) is forgeable post-CRQC and none expires: a live header decode on 2026-08-19 showed one 65-byte proposer seal plus 22 individual 65-byte committed seals carried in the block header itself. No signature expiry mechanism. Cross-chain messaging and bridge attestations via LayerZero, Wormhole, Chainlink CCIP and Stargate (each documented on Kaia's own cross-chain tooling pages) extend signature trust off-chain.
Validator and node peer-to-peer transport is RLPx: the asymmetric step is an ECIES handshake on secp256k1 (AES-128-CTR, HMAC-SHA-256, NIST SP 800-56 concatenation KDF) and the established frame channel is AES-256-CTR with a Keccak-256-derived key and a Keccak-256 MAC, so the whole channel is in classical HNDL scope through its key agreement. The Foundation public RPC endpoints negotiate TLS 1.3 with classical X25519 and answer a hybrid-only client hello with a handshake_failure alert (observed 2026-08-19). Three third-party public endpoints listed in Kaia's own endpoint table (BlockPI, dRPC, QuickNode) negotiate the hybrid X25519MLKEM768 group at their CDN edge; this is not stated in Kaia's documentation. Scored at baseline: operator-controlled transport is classical throughout.
3 Metadata, Anonymity & Confidentiality weight 13% 22 / 100
Fully transparent EVM-compatible ledger; pseudonymous addresses; no shielded pool, no encrypted mempool and no confidential-transaction feature documented anywhere in Kaia's own documentation. KaiaScan and equivalents make graph analysis straightforward.
Public RPC documented by Kaia: Foundation endpoints plus QuickNode, BlockPI, OnFinality, GetBlock and dRPC in the mainnet endpoint table, with a further provider section naming Kaia API Service, Chainstack, All That Node, Tatum, Grove, Ankr, NodeReal and Nodit. 33 permissioned council nodes (live query 2026-08-19) means mempool gossip is observable to a tight set. No validator-metadata-retention policy declared at protocol level.
Cross-chain surface documented on Kaia's own tooling pages: LayerZero, Wormhole and Chainlink CCIP messaging, Stargate bridge, plus the KaiaBridge used for the Finschia-to-Kaia transition. All are observable by passive cross-chain indexers.
Kaia has no shielded-pool layer. Standard Shor-on-secp256k1 and Shor-on-BLS12-381 retroactive risks apply, but no ring-signature, ElGamal or zk-SNARK encryption layer adds confidentiality exposure beyond the signing layer.
None at protocol level.
4 Migration Architecture weight 10% 59 / 100
Kaia inherits Klaytn's modular AccountKey system supporting five key-structure types (Legacy 0x01, Public 0x02, Fail 0x03, WeightedMultiSig 0x04, RoleBased 0x05), plus AccountKeyNil at 0x00, which both the client type enumeration and Kaia's own account documentation carry as an empty key used only inside role-based updates. The schema decouples cryptographic keys from addresses, allowing key rotation via AccountUpdate transactions and role separation without changing the account address. Every key type is still secp256k1. No demonstrated production swap of the underlying signing curve; agility is architectural, not exercised against PQ primitives.
Kaia's AccountKey system provides protocol-native account-abstraction primitives: keys can be rotated without losing the account, weighted-threshold multisig is native (AccountKeyWeightedMultiSig), and role-based keys (AccountKeyRoleBased) separate RoleTransaction, RoleAccountUpdate and RoleFeePayer, with RoleTransaction used as the default when the other roles are unset. Fee delegation is a protocol transaction type; EIP-7702 SetCode transactions (KIP-228, still Draft in the KIP repository) and token-denominated gas abstraction shipped at the Prague hardfork (block 190,670,000, 2025-07-17). This is a genuine migration-architecture asset for hybrid PQ deployment. No documented client-layer PQ migration path.
Kaia executed the Klaytn-Finschia merger as a coordinated migration event (Kaia hardfork, mainnet block 162,900,480, block timestamp 2024-08-29 UTC, activating the KIP-160 TreasuryRebalanceV2 contract at the same block per the client's mainnet fork configuration; the merger governance thread KGP-25, posted 2024-01-15, had proposed a single new integrated token, provisionally named PDT there, claimable by KLAY and FNSA holders, and the token that shipped is KAIA), followed by the Prague hardfork (block 190,670,000, 2025-07-17) and the Osaka hardfork (block 213,333,000, 2026-04-07). The Osaka mainnet target was rescheduled once between releases: v2.2.1 published a block of 211,090,000 for 12 March and then withdrew it, and v2.2.2 set the final block. Hard forks are proposed through the KIP process and scheduled by the Foundation; the client's mainnet fork configuration records a single linear schedule with no competing branch, and we located no contested fork in the release history. A 33-node permissioned council concentrates upgrade coordination; the trade-off is centralisation.
AccountKeyRoleBased and AccountKeyWeightedMultiSig architecturally permit constructing a hybrid-key account (one role classical, one role PQ; or m-of-n with one PQ key) once a PQ scheme is added to the AccountKey type set. No KIP for a PQ AccountKey type exists among the 28 Core KIPs. No EVM precompile for ML-DSA, SLH-DSA or FN-DSA verification on Kaia: the Osaka precompile set adds only the classical secp256r1 verifier at 0x0100 alongside the Prague EIP-2537 BLS12-381 set. A full clone-and-grep of kaiachain/kaia on 2026-08-19 returned zero post-quantum code.
N/A by default, no stateful hash scheme in scope; stateless schemes score full per v3.1 rubric.
N/A, and excluded from this dimension's denominator. Kaia IBFT consensus uses per-validator ECDSA secp256k1 committed seals with no quorum-signature aggregation: a raw decode of the IBFT extraData at five sampled live blocks on 2026-08-19 returned 33 validator addresses, one 65-byte proposer seal and 22 individual 65-byte committed seals in every case, each recovered with ecrecover. Twenty-two is exactly the commit threshold the client enforces: calcQuorumSize returns ceil(2N/3) over N = min(qualified validators, committee-size parameter), and with a 33-member council against a live istanbul.committeesize of 50 that is ceil(66/3) = 22. The 2f+1 form is carried in the client only as the labelled pre-permissionless sealer quorum and is not the threshold applied here. The KIP-113 BLS surface is for randomness and proposer selection, not consensus quorum aggregation. Per v3.1 rubric, 4f applies only to chains with Shor-vulnerable signature aggregation at consensus, so weight redistributes to 4a-4e. Not scored, so it is left out of the dimension total rather than counted as a zero.
5 Deployment Execution weight 22% 4 / 100
0% of Kaia mainnet validator seals or account signatures under any PQC primitive. The vendor-announced QSSN pilot does not change this, and the vendor's own regulatory filing says why: BTQ's Q1 2026 management discussion describes QSSN as quantum-safe smart-account wallets for EVM-compatible networks 'using ML-DSA post-quantum cryptography within the ERC-4337 account abstraction standard', an approach that 'requires no modifications to underlying blockchain protocols'. Kaia's protocol therefore validates only the ECDSA secp256k1 signature on any such transaction, and no Kaia mainnet bytes are signed under a PQC primitive in a chain-verifiable way. The 1,477-transaction figure is vendor-reported and attributed by BTQ's own Q1 corporate update to the Finger pilot without naming Kaia; the 100,000-transaction figure in the Q2 update is not tied to Kaia or to any named chain.
No PQ scheme merged into kaiachain/kaia. A full shallow clone and case-insensitive grep of the default branch on 2026-08-19 (head commit dated 2026-08-19) returned zero files matching falcon, dilithium, ml-dsa, sphincs, slh-dsa, kyber, ml-kem, xmss, post-quantum, postquantum or quantum, in code or documentation. Two near-misses, stated so an independent reviewer running the same grep reaches the same place: the unspaced form 'mldsa' occurs once as an incidental substring inside api/cypress_credit_data.go, a multi-megabyte single-line encoded credit-allocation blob containing no code; and 'lattice' resolves to the lattice-reduction helper of the bn256 pairing implementation at crypto/bn256/cloudflare (lattice.go, curve.go, lattice_test.go) plus the two build-time licence-mapping scripts that list those filenames. None is post-quantum. Scanning the kaiachain organization's 62 public repositories on 2026-08-19 returned no repository whose name or description matches quantum, PQC, dilithium, kyber, falcon, sphincs or ml-dsa, so no PQ research fork is published there either.
All 33 council nodes (live query 2026-08-19) seal with ECDSA secp256k1. A live kaia_getBlsInfos query at the chain tip returned 34 registry entries covering all 33 current council addresses, each with a 48-byte BLS12-381 public key and a 96-byte proof-of-possession verifying without error. No GC member has registered a PQC consensus key, and the AccountKey schema contains no PQC type.
VOIDED to 0 per v3.1 rule (5a = 0). No dated, enforcement-mechanism-backed PQC milestones for Kaia mainnet. The active dated roadmap item is GP-20, the Kaia Permissionless Network Policy, posted to the governance forum on 2026-03-12 under the PGT (Permissionless, Governance, Tokenomics) roadmap with implementation timing stated as end of September 2026; it contains no PQC track, and no published vote result for it was located.
Foundation channels (the Kaia website, the documentation site, kaiachain/kips, kaiachain/kaia) make zero PQC commitments, and governance-forum search API queries returned an empty result set on every axis the API reports (posts, users, categories, tags, groups) for both 'quantum' and 'post-quantum', re-verified 2026-08-19. The announced-side signal is vendor-led on one surface: BTQ Technologies' QSSN, announced 2026-05-06 as the PQC security layer for a bank-led KRW stablecoin proof-of-concept with iM Bank and Finger Inc., to be implemented on the Kaia mainnet with ECDSA alongside NIST-aligned PQC signatures 'such as ML-DSA'. Shipped-side remains zero: no block-explorer-verifiable PQC bytes on Kaia; BTQ's Q1 2026 corporate update attributes its 1,477 vendor-reported pilot transactions to the Finger pilot without naming Kaia, neither its Q1 nor its Q2 2026 interim statements and management discussion name Kaia anywhere and both record QSSN as pre-revenue, and its 2026-08-14 Q2 update describes the Kaia relationship as discussions regarding potential progression toward production deployment. Partial credit for chain-side restraint; the vendor-side announced-versus-shipped gap takes a deduction, widened one point because the newest vendor primary source is weaker on Kaia than the announcement it followed. Kaia Wallet quantum-resistant marketing is not counted: no such claim appears on any first-party or store surface.
No PQ deployment, no published bytes-per-block analysis under any PQ scheme for Kaia. For reference, the current classical footprint measured from a live block header on 2026-08-19 is 2,275 bytes of IBFT extraData carrying 33 validator addresses, one proposer seal and 22 committed seals of 65 bytes each.
6 Supply Chain Vendor Readiness weight 22% 7 / 100
Wallets documented by Kaia: 26 rows in the wallet table, including Kaia Wallet, MetaMask, OKX Wallet, Rabby Wallet, D'cent and Safe Wallet, which is the only row typed as a smart-contract account and the only one flagged multi-sig; every other row is typed EOA. Kaia's documentation carries a separate hardware-wallet section covering D'cent and SafePal S1. None of these documents a PQ signing scheme or a dated PQC roadmap for Kaia, and the wallet table contains no occurrence of post-quantum, quantum-resistant or PQC. Kaia Wallet's own browser-extension store listing identifies LINE NEXT Inc. as both the offering party and the developer, describes the wallet as the transformed Kaikas following the Finschia and Klaytn integration, and makes no quantum claim of any kind. BTQ's vendor-reported figure of more than 200 post-quantum wallets created (Q1 2026 corporate update) arose inside the Finger pilot and is pilot-scoped vendor tooling, not an upgrade to any wallet in Kaia's general ecosystem.
Cross-chain surface documented on Kaia's own tooling pages: Stargate (bridge), LayerZero, Wormhole and Chainlink CCIP (messaging), plus the KaiaBridge used for the Finschia-to-Kaia transition. None of them publishes a PQC roadmap for Kaia routes, and none is documented as using anything other than classical elliptic-curve signing for its attestations.
Custodian coverage verifiable from a primary source is thin: BitGo defines a Kaia mainnet network and a KAIA coin family in its public client statics. No custodian publishes a Kaia-specific PQC roadmap and none has MPC-PQ in production for KAIA signing. Hex Trust applied for Governance Council membership jointly with BCW in GP-6, a governance-forum thread titled 'GC Membership of Hex Trust + BCW' opened 2024-11-11, endorsed by an existing Council member on 2024-11-19, with the Foundation replying on 2024-11-22 that the agenda would be brought to a GC vote; the thread carries no vote result and no current-membership listing naming Hex Trust was located, so the card does not score Hex Trust as a confirmed custodian tile. iM Bank's role in the vendor-announced QSSN stablecoin proof-of-concept is announced-stage participation in an application-layer pilot, not a KAIA custody PQC roadmap.
Public RPC documented by Kaia: Foundation endpoints plus QuickNode, BlockPI, OnFinality, GetBlock and dRPC in the mainnet endpoint table, with Kaia API Service, Chainstack, All That Node, Tatum, Grove, Ankr, NodeReal and Nodit named in the provider section. The Foundation endpoints negotiate classical X25519 under TLS 1.3 and refuse a hybrid-only handshake (observed 2026-08-19); the BlockPI, dRPC and QuickNode endpoints negotiate hybrid X25519MLKEM768 at their CDN edge, while the OnFinality and GetBlock endpoints do not. None of this is stated in Kaia's documentation or presented as policy. Kaia's node-security documentation states that node keys 'have to be stored on the disk or entered via the command line', recommends backing them up 'in an encrypted keystore file' held offline, and says that 'in the future, the nodes could support storing the keys in an external provider such as key management systems (KMS) or hardware security modules (HSM)', which places KMS and HSM support outside the shipped node today. No public inventory of HSM use by GC validators was located, and no PQ signing is documented anywhere in the validator stack. No TEE-attestation chain in Kaia's documented validator stack. BTQ's QSSN is vendor application-layer settlement software at announced proof-of-concept stage, not part of Kaia's RPC, HSM or TEE stack.
7 Governance & Coordination weight 8% 37 / 100
Permissioned Governance Council: 33 consensus nodes in the live council on 2026-08-19; membership requires a minimum 5,000,000 KAIA staked and operation of a compliant node; voting power is 1 vote per 5M KAIA, capped so that no entity exceeds (total valid GC members − 1) votes; approval needs a one-third count or power quorum plus a majority of participating votes. Seven GC-member resignation notices were posted on the governance forum between 2026-03-03 and 2026-08-18 (LINE Xenesis 2026-03-03, Presto Labs 2026-03-05, SEGA 2026-03-31, Dora 2026-04-16, Beergang DAO 2026-04-28, Cosmostation 2026-07-02, ABGA 2026-08-18); an eighth notice, StableLab, sits just outside that window at 2026-02-10, so seven is the count inside the stated window, not a 2026 total. Three membership applications followed in May 2026 (HashPort, Alchemy, NODERS). One node implementation is documented for running a Kaia node and it is the only one that reports a live mainnet version string: kaiachain/kaia, Go. Nakamoto coefficient is structurally low: a small permissioned set with Foundation curation. GP-20, the Kaia Permissionless Network Policy, was posted on 2026-03-12 under the PGT roadmap and proposes opening validator participation with consensus limited to the top 50 nodes by total staking amount, with policy implementation timing stated verbatim as 'End of September 2026'; it is not yet executed and its thread carries no vote result. Separately, all four KIPs on the permissionless track (KIP-286 Permissionless Validator Lifecycle, KIP-287 Permissionless Staking Policy, KIP-290 Permissionless Smart Contracts, KIP-311 Permissionless P2P Network Topology) are still Draft in the KIP repository; GP-20's own text does not name them, so the card records their Draft status as a fact and does not assert that they are GP-20's implementing KIPs.
The Klaytn-Finschia merger (Kaia hardfork, 2024-08-29) was executed as a coordinated cross-foundation event; the Prague (2025-07-17) and Osaka (2026-04-07) hardforks followed through the KIP and on-chain governance process, the Osaka mainnet block being rescheduled once between the v2.2.1 and v2.2.2 releases. No documented emergency upgrade executed under active exploit pressure.
Kaia DLT Foundation, the integrated foundation formed in the Klaytn-Finschia merger and named as copyright holder across Kaia's own surfaces, operates as coordinator; the v1.3 white paper's regulatory disclaimer is written against the Abu Dhabi Global Market FSRA regime. GC membership changes are posted on the governance forum; the KIP process is documented in the kaiachain/kips repository, which carries 28 Core KIPs out of 37 total. No named PQC migration lead, no PQC working-group charter, and no PQC entry in the PGT roadmap.
The Klaytn-Finschia merger involved coordinated migration of two chain states, token supplies (KLAY and FNSA to KAIA), validator sets and governance processes, executed at a single mainnet block alongside KIP-160 treasury rebalancing; a non-trivial coordination precedent. No precedent of a coordinated cryptographic-primitive change while under attacker pressure.
No canary, honeypot, rate-limited spending rule, or cryptographic tripwire on Kaia.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Kaia's consensus documentation states verbatim that 'More than 50 consensus nodes can participate in the CNN (Consensus Node Network) at the moment'; a live kaia_getCouncilSize query on 2026-08-19 returned 33 nodes in the council, and kaia_getCommitteeSize returned 33; the governance forum records seven GC-member resignation notices between 2026-03-03 and 2026-08-18 (LINE Xenesis, Presto Labs, SEGA, Dora, Beergang DAO, Cosmostation, ABGA) alongside new membership applications (HashPort, Alchemy, NODERS). The divergence resolves mechanically rather than remaining open: the live governance parameter istanbul.committeesize is 50, and because the council of 33 is smaller than that ceiling the whole council is the per-block committee, which is why getCouncilSize and getCommitteeSize both return 33 even though the client's genesis chain configuration still carries a SubGroupSize of 22. The card uses the live on-chain council size (33) for validator counts and treats the documented 50 as a capacity ceiling, not a headcount.
Kaia's user-facing documentation names the account key material only as 'a compressed public key on S256 curve' with SEC1 encoding; the strings ECDSA, secp256k1 and Keccak do not appear on the accounts, transactions or consensus pages, and the v1.3 white paper names IBFT, VRF proposer selection and the SimpleBlsRegistry but no signature or hash algorithm. The scheme and hash are nameable only from the kaiachain/kaia client source (secp256k1 sign/recover/verify over the S256 curve; Keccak-256 address derivation) and from the KIP repository, where KIP-113 and KIP-114 do name their primitives exactly. The card scores 1a on the published inventory, not on our reconstruction.
Kaia inherits Klaytn's IBFT implementation, AccountKey schema, and the KIP-113 SimpleBlsRegistry; KIP-113, KIP-114 and KIP-146 were authored under Klaytn and activated at the Randao hardfork (block 147,534,000, block timestamp 2024-03-04 UTC), before the Kaia hardfork, and carried into Kaia unchanged. Card scores Kaia as the active chain post-merger and treats Klaytn artifacts as inherited but not re-attributed.
BTQ's 2026-05-06 release names ML-DSA as an example of the NIST-aligned PQC signatures in its dual-signature design ('such as ML-DSA') and separately lists ML-DSA, ML-KEM and SLH-DSA only as the standards NIST has finalized; it names no parameter set and does not state that ML-KEM or SLH-DSA are used in the pilot. BTQ's Q1 2026 management discussion names only ML-DSA, inside the ERC-4337 account-abstraction standard, and describes validator nodes generating attestations under a dual-signature mechanism combining classical ECDSA with post-quantum ML-DSA. A previous published reading wrote all three schemes into the pilot design; the card now carries only ML-DSA, unparameterised, as the vendor states it.
BTQ Technologies' primary documents do not agree on how advanced or how Kaia-specific its QSSN stablecoin proof-of-concept is, and the 2026-05-06 release does not agree with itself on tense: its subheading asserts 'Built on the Kaia mainnet, the proof-of-concept is connected to the blockchain ecosystems originally developed by Kakao and LINE', while the body of the same release states that 'A notable feature of the proof-of-concept is that it will be implemented on the Kaia mainnet' (future tense). The card carries the future-tense body wording because it is the specific statement, and because no later BTQ primary source upgrades it. BTQ's Q1 2026 corporate update (news release dated 2026-05-18, furnished on Form 6-K) reports 1,477 cumulative pilot transactions at a vendor-reported 100% success rate and 0% fallback rate, attributed to the Finger pilot, and does not mention Kaia anywhere; BTQ's Q1 2026 interim financial statements and management discussion (Form 6-K filed 2026-05-18) also do not mention Kaia and state that QSSN is pre-revenue. BTQ's 2026-08-14 Q2 update still calls the iM Bank / Finger initiative a proof-of-concept, reports that QSSN 'surpassed 100,000 transactions processed on mainnet' without tying that figure to Kaia or to any named chain, and describes the Kaia relationship separately as discussions regarding potential progression toward production deployment. Card scores chain-verifiable deployment, which is zero; the pilot is recorded as a vendor-announced application-layer claim.
Three expansions of the acronym QSSN appear across BTQ's own primary documents: 'Quantum Secure Stablecoin Settlement Network' (2026-05-06 release), 'Quantum Stablecoin Settlement Network' (Q1 2026 management discussion) and 'Quantum Secure Systems & Networks' (Q1 2026 corporate update and 2026-08-14 Q2 update). The precedence claim also moves: the May release calls the initiative 'South Korea's first bank-led KRW stablecoin proof-of-concept', while the August update calls it 'one of South Korea's first'. The card carries neither superlative and refers to the initiative as a bank-led KRW stablecoin proof-of-concept.
Two protocol features the card records as live on mainnet rest on KIPs that are still marked Draft in the KIP repository: KIP-279 (BlobTx for Kaia, Draft, created 2025-11-24), implemented at the Osaka hardfork with mainnet blob target and max of 1, and KIP-228 (SetCode for EOA, Draft, created 2024-11-15), implemented at the Prague hardfork per EIP-7702. The card scores activation state from the client's mainnet fork schedule and the release notes, not from KIP status, and flags the divergence here.
Kaia's own two primary sources disagree on the provenance of the P-256 verification precompile at address 0x0100. The v2.2.0 release notes list it as 'Added the secp256r1 precompile as per EIP-7951', while the comment above the precompile map in the client source attributes the same contract to EIP-7212. Both describe the same shipped behaviour, a secp256r1 signature-verification precompile at 0x0100 activated at the Osaka hardfork, and the two EIPs are successive drafts of the same primitive, so the divergence is one of citation rather than of behaviour. The card carries the release-note attribution (EIP-7951) because that is the Foundation's published statement of what shipped.
The client exposes two different fault-tolerance expressions and only one of them is the commit threshold. calcFaultTolerance returns ceil(N/3) - 1, which for a 33-member set gives f = 10 and would imply a 2f+1 = 21 quorum, and the sealer carries 2f+1 in a comment explicitly labelled the pre-permissionless sealer quorum. The threshold actually enforced on COMMIT messages is calcQuorumSize, which returns ceil(2N/3), giving 22 for N = 33. Every sampled mainnet header carries exactly 22 committed seals, matching calcQuorumSize and not 2f+1. The observed 22 seals match calcQuorumSize, not 2f+1 = 21. This affects the description of consensus, not any sub-score, since 4f is scored N/A and excluded from its dimension denominator.
The kaiachain GitHub organization contains kaia-erigon alongside kaiachain/kaia. On 2026-08-19 kaia-erigon carried no releases, a default branch of release/3.0, a last push dated 2025-10-14 and an unmodified upstream Erigon README with no Kaia-specific content, and it is not offered on Kaia's node download or node-operation documentation. The live mainnet client version string is Klaytn/v2.2.2, from the kaiachain/kaia tree. The card therefore treats kaiachain/kaia as the documented node implementation while recording the existence of the second repository here, rather than asserting a bare one-client claim that the organization's repository list appears to contradict.
Delta-QRI under alternative weighting
Under a profile that weighted Dim 5 at 30% and Dim 6 at 30% (other dimension weights scaled proportionally to the remaining 40%), QRI would fall to ≈ 16 and Band would remain 2.
Announcement-to-shipped ratio
Announced: 1. Shipped: 0. Ratio: 0.
Tag: narrative-only-vendor
Peers in the L1 profile
9 chains closest to Kaia by Stage then QRI.