Permissioned ledger
Kaia ticker KAIA
Summary
Kaia continues the Klaytn chain, launched in June 2019, under the same chain ID. Consensus is an optimized Istanbul BFT run by the consensus nodes of the Kaia Governance Council. For each block a proposer and a committee are drawn at random from the council, seeded by on-chain randomness since the Randao hard fork (KIP-146); the proposer builds the block and it is complete once more than two-thirds of the committee have signed it. Blocks target one-second intervals. Every council member stakes at least 5 million KAIA and has an equal chance to propose; stake above the minimum earns a share of staking rewards but does not weight block production. A read of the Kaia Foundation's archive endpoint on 2026-09-29 returned a council size of 31. The node software is derived from go-ethereum, and its consensus engine from Quorum's Istanbul BFT code. 1252122242628
Design
- System
- Permissioned ledgerKaia mainnet (chain ID 8217) is the former Klaytn mainnet, renamed by the Kaia Transition hard fork on 29 August 2024 after Klaytn and Finschia governance approved a merger. Anyone can read, send and deploy contracts, but only Governance Council members admitted through governance and onboarded by the Kaia Foundation run consensus nodes, so this profile uses the permissioned class; the package listed it as a permissionless layer 1. A permissionless transition is planned under a policy (GP-20) marked passed, but was not active on mainnet at review. Service chains are separate networks.
- Settlement family
- Ethereum / EVM
- Scarce resource
- Reputation
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- Council members, chosen at random per block from the council. Joining needs 5 million KAIA staked, an application on the governance forum endorsed by an existing member, a Kaia Square vote and onboarding by the Kaia Foundation, whose node operators also remove departing members from the validator list. KIP-286 (January 2026) says the Kaia team currently manages validator states manually.
- Fork choice
- No open weight-based chain selection. Istanbul BFT commits one block per height once the committee has signed it, and Kaia's docs say there are no forks and finality is immediate. If a round fails, the round changes and the next proposer comes from the same committee (KIP-146). A permissionless policy (GP-20), marked passed on the governance forum, would let the top 50 qualified validators by stake join consensus; it was not active on mainnet at review.
Qualifications
- System class · Contested. Anyone can use Kaia, but validator membership is approved through governance and managed by the Kaia Foundation: KIP-146 (2023) described the chain as permissioned, KIP-286 (January 2026) says the Kaia team manages validator states manually, and council applications still went to Kaia Square votes in May 2026. This profile follows who can produce blocks. GP-20, marked passed on the governance forum, would open candidacy to anyone meeting a stake and performance bar; it was not active at review, with no final node release and no next fork listed by the public endpoint.
- Scarce resource · Partial. Council members must stake at least 5 million KAIA; stake above that minimum earns staking rewards, and total staked and delegated KAIA sets governance votes, but admission is by governance approval and every member has an equal chance to propose, so stake does not weight block production. The consensus is recorded as authority or reputation based. Under the planned permissionless policy the top 50 qualified candidates by stake would validate.
- Finality · Partial. Recorded as other. Kaia's own terms: immediate finality under an optimized Istanbul BFT. A block is final once more than two-thirds of the committee drawn for it have signed, and the docs say there are no forks. Finality rests on a permissioned council; the docs list penalty cases for safety and liveness failures, but no enforced stake slashing was found.
- Slashing · Contested. No stake slashing was found in the reviewed docs. Penalties found are reward exclusions, such as seven days without block rewards after three consecutive missed governance votes, and removal through governance. The white paper lists an autonomous validator slashing system among features planned for the permissionless network.
- Evm compatibility · Partial. Contracts run on the Kaia Virtual Machine, which the white paper calls a derivative of the EVM that supports all EVM opcodes plus Kaia's own precompiled contracts. Kaia also has its own transaction types (fee-delegated, account update, cancel) and account keys that can be changed without changing the address, alongside Ethereum-format transactions.
- Fee delegation · Applies. Kaia's own transaction types let a fee payer co-sign a user's transaction and pay all of its fee, or a set percentage with the ratio types. Since the Prague hard fork, gas abstraction also lets users pay gas by swapping approved tokens for KAIA.
Tradeoffs
- Emphasizes
- Scalability
- Gives up
- Open validator membership. Only Governance Council members, admitted through governance and onboarded by the Kaia Foundation, produce blocks (31 in a 2026-09-29 read), and each block is signed by a committee drawn from that council. KIP-146 describes Istanbul BFT as tolerating Byzantine validators up to one-third of the set, so a larger coordinated share falls outside that guarantee. No stake slashing was found: the docs list penalty cases but leave the rules to governance.Kaia's docs present one-second blocks, immediate finality and reliability for enterprise use as design goals. Security is not listed as an emphasis because finality rests on a permissioned council without enforced slashing; readers who weight committee finality as a security emphasis may reasonably disagree. The planned permissionless transition would change this trade-off if it activates.
- Full node at home
- Demanding 5810Kaia's endpoint node guide recommends 8 vCPUs, 64 GiB of memory, more than 4,000 GiB of storage, 3,500 Mbps of disk bandwidth and up to 10 Gbps networking, and estimates about 2.5 GB of new data per day under the load it assumes. New nodes can start from a chaindata snapshot instead of a full sync, which means trusting that snapshot. Consensus nodes need more hardware and council membership.
- Throughput claims
- Theoretical peak: 4,000 tx/s 1211Theoretical peak; not comparable across chains or with observed load.Kaia's docs and white paper state the figure in the present tense with no method, window, hardware or transaction mix, so it is treated as a design claim. The consensus page carrying it was last updated in January 2025 and describes the design inherited from Klaytn. Not an observed mainnet rate; it ignores state growth, propagation and spam or decoy load.
- Lab benchmark: 10,900 tx/s 27Controlled benchmark; not observed network behavior.Reported as roughly 10,900 transactions per second with a 1,000 ms maximum block interval and no failed transactions in that run.Devnet test of the KaiaBFT consensus change reported in a post dated 2026-06-30Vendor-reported devnet run; the transaction mix, hardware and node count were not published. KaiaBFT was not live on mainnet at review; the post says rollout is expected over the coming months. Not an observed mainnet rate and not comparable with other chains' figures.
Scaling layers
- Kaia Service Chains (data anchoring and value-transfer bridges) · Sidechain, status unknown 19
Service chains are separate chains run by application operators with their own consensus nodes; Kaia's docs say the design gives up full decentralization for usability and instant finality. A service chain can anchor its block hashes to the Kaia main chain and move KAIA and tokens through bridge contracts, so assets on it depend on its own operators. The node software ships in the Kaia client; which service chains anchor to mainnet today was not verified.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | No hash-time-locked or other trust-minimized swap mechanism was documented for Kaia. The virtual machine could host one, but none was reviewed. |
| Authenticated data publication | Built into the protocolLimited scope | Blob transactions, added by the Osaka hard fork (KIP-279; mainnet block 213,333,000, April 2026): a block records each blob's versioned hash of a KZG commitment, validators must verify the blob before committing the block, and nodes should keep blobs and serve them over JSON-RPC, so readers can fetch the data and check it against the commitment. Limited: nodes may delete blobs after 21 days, a block holds one blob, and there is no update mechanism. The KIP is still marked draft, but the node releases implement it and the public endpoint listed the blob schedule as active on 2026-09-29. 202325 |
| Light clients | Unknown | No light client that checks council signatures was found in Kaia's docs. Validators register BLS keys in a system contract, a building block only, and new nodes may start from a chaindata snapshot, which is trusted rather than verified. 1011 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Kaia was reviewed. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Smart contracts run on the Kaia Virtual Machine, derived from the EVM, and ordinary accounts can hold weighted multi-signature or role-based account keys that the protocol checks when validating transactions. 311 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | No protocol feature that reclaims or delays a sent payment was found. Role-based account keys let a separate account-update key replace a lost transaction key, which is key rotation by a current key holder and does not meet this row, and the cancel transaction type only replaces a transaction still waiting in the pool. 313 |
| Rollups | Unknown | No rollup anchored to Kaia was verified. KIP-279 says blob transactions are meant to let rollups post data to Kaia, but no live rollup using them was found. 23 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinDragonSwap, KLAYswap | DragonSwap's docs describe a decentralized exchange on Kaia for swaps, liquidity and farming, and KLAYswap's docs describe an automated market maker built by ozys for the network when it was named Klaytn. DeFiLlama's protocol data on 2026-09-29 showed modest deposits in each and lists several smaller Kaia exchanges. Operators' audits and liquidity depth were not reviewed. 323334 |
| Issuer-native stablecoins | Established in the ecosystemUSD₮ (Tether), JPYC (JPYC Inc.) | Tether's supported-protocols page lists a USD₮ contract on Kaia, and JPYC's GitHub organization lists Kaia among JPYC's deployments. Native here means an issuer-listed contract on Kaia, not a protocol asset; issuers keep freeze and similar controls. Circle's USDC address list does not include Kaia. 293031 |
| Algorithmic stablecoins | Unknown | Algorithmic or collateralized-debt stablecoins on Kaia were not reviewed. |
| Bridges | Established in the ecosystemStargate (LayerZero), Wormhole, Kaiabridge (FNSA to KAIA swap, Kaia), Service chain value-transfer bridges | Kaia's docs list Stargate and Wormhole as cross-chain tools that support Kaia mainnet; those pages were last updated in October 2024, and current support was not checked on the bridges' own pages. Kaiabridge, run by Kaia, is a one-way swap of FNSA from the Finschia network into KAIA at a fixed rate. Service chain bridges move KAIA and tokens between the main chain and a service chain. Which routes the Kaia Portal bridge page uses, and bridge volumes, were not reviewed. Risk: Each third-party route has its own verifier or relayer set and trust model, not assessed here. Kaiabridge swaps are irreversible and rely on Kaia's contracts and operators. Service chain assets depend on that chain's own operators. A wrapped asset is only as sound as the bridge that minted it. 791617 |
| Block explorers | First-partyKaiaScan, OKX Kaia Explorer | Kaia's docs list KaiaScan, which they call the official explorer, developed by the Kaia Foundation with Bisonai, and OKX's Kaia explorer. Explorer data is provider-indexed, not canonical consensus; listing is not a quality check. 1415 |
| Hardware wallets | ThinD’CENT, SafePal S1, Trezor (through MetaMask or Rabby), Ledger (network in wallet code behind a switch) | Kaia's docs publish guides for D'CENT and SafePal hardware wallets. See the custody rows: Trezor's Kaia page routes users through MetaMask or Rabby, and Ledger's wallet code lists the network behind a switch that is off by default. 18193639 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | PartialSame as native: Unknown | Can: Possibly add a Kaia account in Ledger Wallet: its code lists the network, still named Klaytn with chain ID 8217 and a KLAY unit, behind a feature switch that is off unless Ledger turns it on remotely Cannot: Rely on a readable Ledger page for Kaia: Ledger's Kaia and Klaytn coin pages returned not found, and its Klaytn wallet address redirects to its generic supported-assets pageLedger's own wallet code includes the network, but support is limited: Ledger Wallet's EVM configuration (develop branch, read 2026-09-29) lists chain ID 8217 with a node address on a Ledger domain, and the currencyKlaytn feature switch is declared without a value, so it is off by default. No Ledger page confirms it is on for users, and the code still uses the pre-2024 name and ticker. 35363738 |
| Trezor | Through an intermediaryMetaMask or Rabby, as listed on Trezor's Kaia pageSame as native: Unknown | Can: Hold and send KAIA with a Trezor device through MetaMask or Rabby, the third-party wallet apps Trezor's Kaia page lists Cannot: Manage KAIA in Trezor Suite: Trezor's Kaia page lists only third-party wallet apps, and its older Klaytn page says Trezor does not support KlaytnTrezor's older Klaytn page asks users who used the asset with Trezor before to contact support; its current Kaia page names MetaMask and Rabby as the supported paths. 3940 |
Public data
iKnow Blockchain has no public-data lookups for Kaia yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Reviewed Sep 29, 2026 Next review due Oct 9, 2026, 12:00 UTC.
Publication date · newest first
-
Kaia Safe interface retired as Safe Global adds Kaia support
Kaia announced that Safe Global now supports Kaia mainnet and the Kairos testnet directly, and that its own hosted interface, safe.kaia.io, would close on 31 August 2026. Kaia's migration guide, updated on 18 September 2026, confirms the interface was retired and that existing Safe accounts, owners, thresholds and assets are unchanged.
- Implementation:Kaia supported on Safe Global
- Release:announced 2026-07-28
- Activation:safe.kaia.io retired on 31 August 2026, per Kaia's guide
Sources: Kaia Blog — Important Update: Kaia Safe is moving to Safe Global (external site) · Kaia Docs — Migrate to Safe Global (external site)
-
Contribution Reward replaces the equal proposer reward, with unearned rewards set to be burned
Under GP-21, which the governance forum marks as passed, the per-block reward that every council member shared equally is replaced by Contribution Reward: 0.96 KAIA per block goes to the Kaia Performance Fund and is paid for measured contribution or burned. The first mission counts USDT deposited in designated protocols, capped at one USDT per 10 KAIA staked or delegated. The first epoch report (9 September 2026) paid out 36,421 KAIA of a 2,500,000 KAIA monthly budget and calculated the remaining 98.5% as the amount to burn; the operation guide says unpaid rewards are burned in a batch after three epochs.
- Proposal:GP-21 marked passed on the governance forum
- Implementation:Mission-1 operated by the Kaia Foundation
- Release:operating parameters published; no separate node release confirmed
- Activation:first epoch ran from about 23 July to 22 August 2026; claims opened on 7 September 2026, with rewards released over six months; the calculated burn happens in a batch after three epochs
Sources: Kaia Governance Forum — [GP-21] Contribution Reward Operation Guide (English) (external site) · Kaia Governance Forum — [CR] Contribution Reward Monthly Report - Epoch 1 (external site) · Kaia Docs — Kaia Governance (external site) · Kaia Docs (Kaia Foundation) — Kaia Blockchain White Paper v1.3 (external site)
-
GP-20 sets a policy for opening Kaia validation to qualified candidates
The Kaia Foundation posted GP-20, a policy for moving from an approved Governance Council to open validator participation, and the governance forum now marks it as passed. Anyone could become a candidate; one that passes the VRank performance evaluation and has 5 million KAIA staked would become a validator, and the 50 largest stakes would take part in consensus. Council membership would become a separate role gained automatically after a seven-day challenge window. The policy applies only once the permissionless transition is complete, which Kaia's roadmap targeted for late September 2026.
- Proposal:policy proposal published 2026-03-12; marked passed on the governance forum
- Implementation:draft KIPs (KIP-277, KIP-286, KIP-287); v3.0.0 release candidates tagged in July and August 2026
- Release:no final release found at review
- Activation:not active on mainnet; the public endpoint listed no next fork on 2026-09-29
Sources: Kaia Governance Forum — [GP-20] Kaia Permissionless Network Policy (English) (external site) · Kaia Blog — PGT Part 1: Kaia's Structural Transition to a Permissionless & Performance-Based Network (external site) · Kaia Improvement Proposals — KIP-286: Permissionless Validator Lifecycle (external site) · Kaia Governance Forum — Permissionless Implementation Overview (external site) · Kaia (GitHub) — kaiachain/kaia releases (external site) · Kaia Docs and Kaia Foundation endpoint — eth_config method; read of the Kaia Foundation public endpoint on 2026-09-29 (external site)
-
Osaka hard fork scheduled for mainnet block 213,333,000, adding blob transactions
Kaia v2.2.2 set the mainnet Osaka hard fork for block 213,333,000, estimated for 7 April 2026. The fork adds blob transactions (KIP-279), which carry data that nodes are expected to keep for 21 days against commitments recorded in blocks, a secp256r1 signature precompile for the signatures passkeys use, the eth_config method and other execution changes, and it turns address(0) into an ordinary account without code. It followed v2.2.0 (28 January 2026), which scheduled the Kairos testnet fork.
- Proposal:specified in KIP-279 and KIP-276, among others
- Implementation:shipped in Kaia v2.2.0 and v2.2.2
- Release:mandatory mainnet upgrade in v2.2.2
- Activation:active on mainnet by 2026-09-29: the public endpoint's configuration listed the blob schedule and the secp256r1 verification precompile that the fork adds; the exact activation time was not checked
Sources: Kaia (GitHub) — Kaia v2.2.2 Release Notice (external site) · Kaia (GitHub) — Kaia v2.2.0 Release Notice (external site) · Kaia Blog — Kaia v2.2 Overview (external site) · Kaia Blog — [Breaking Change] v2.2.2 Hardfork Upgrade: Removal of Bytecode at address(0) (external site) · Kaia Improvement Proposals — KIP-279: BlobTx for Kaia (external site) · Kaia Docs and Kaia Foundation endpoint — eth_config method; read of the Kaia Foundation public endpoint on 2026-09-29 (external site)
-
MEV Auction went live on mainnet under KIP-249
Kaia announced that its MEV Auction went live on mainnet on 18 December 2025. Searchers bid in sealed bids through an auctioneer for a backrun slot placed directly after a target transaction; the proposing consensus node includes the winning transaction, and bids are paid into a governance-controlled vault. Consensus node support shipped in node v2.1.0 on 28 October 2025, which needed no hard fork.
- Proposal:KIP-249, status Draft on the KIP site
- Implementation:shipped in Kaia v2.1.0
- Release:v2.1.0 released 2025-10-28; no hard fork
- Activation:live on mainnet since 2025-12-18, per Kaia
Sources: Kaia Blog — Kaia MEV Auction Launch & Bid Fee Reimbursement Program (external site) · Kaia (GitHub) — Kaia v2.1.0 Release Notice (external site) · Kaia Improvement Proposals — KIP-249: Slot-Based Auction on Kaia (external site)
Topics your AI can explain
Your AI can explain these topics for Kaia through the connection, with sources.
Known gaps
What this profile's review did not establish:
- When a permissionless hard fork will activate was not verified. The governance forum marks GP-20, the permissionless network policy, as passed, and its appendix expected the transition by the end of September 2026, but release candidates for v3.0.0 (July and August 2026) have no final release, and the public endpoint listed no next fork on 2026-09-29.
- The council size of 31 comes from one endpoint read on 2026-09-29. The committee size per block, operator identities and how much council stake is delegated by the Kaia Foundation to newer members were not verified.
- No enforced stake slashing was found; the search covered Kaia's docs and white paper and was not exhaustive.
- The transactions-per-second figure in Kaia's docs has no published method, and no observed mainnet rate was measured.
- Current chain data size and archive node storage needs were not verified; the endpoint node guide gives only a minimum disk size.
- Whether any service chain anchors to Kaia mainnet today was not verified.
- Whether any rollup posts blob data to Kaia, and how often blob transactions are used, were not measured.
- No trust-minimized swap mechanism, light client, or feature for reversing or delaying payments or recovering accounts was found; absence was not exhaustively verified.
- Whether Ledger has switched on its Klaytn network for users was not confirmed; its code still uses the pre-2024 name and KLAY ticker.
- Which third-party routes the Kaia Portal bridge page uses, their trust models and volumes were not reviewed.
- DEX operators, audits and liquidity depth were not reviewed.
- Whether the Finschia network still produces blocks, and how much FNSA remains unswapped, were not verified.
- Kaia's docs give 9.6 KAIA of new issuance per block and a 5.2% initial inflation target, while an April 2026 Kaia post says current annual inflation is roughly 4.87%; with contribution rewards burned when unearned, effective issuance was not computed.
Sources
Oldest dated source check: Source checked Sep 29, 2026 Next check due Oct 29, 2026.
- Kaia Overview (external site)
- Consensus Mechanism (external site)
- Accounts (external site)
- Token Economy (external site)
- Kaia Governance (external site)
- Kaia Hard Fork History (external site)
- Kaiabridge (external site)
- Endpoint Node: System Requirements (external site)
- Scaling Solutions (Service Chain and multi-channel communication) (external site)
- Use Chaindata Snapshots (external site)
- Kaia Blockchain White Paper v1.3 (external site)
- Fee Delegation transaction types (external site)
- Basic transaction types (including TxTypeCancel) (external site)
- Block Explorers (external site)
- KaiaScan (external site)
- Cross-chain tools: Stargate (external site)
- Cross-chain tools: Wormhole (external site)
- Hardware wallets: D'cent Biometric Wallet (external site)
- Hardware wallets: SafePal S1 (external site)
- eth_config method; read of the Kaia Foundation public endpoint (public-en.node.kaia.io) on 2026-09-29 returned chain ID 0x2019, an active blob schedule and no next fork (external site)
- kaia_getCouncilSize method; read of the Kaia Foundation archive endpoint (archive-en.node.kaia.io) on 2026-09-29 returned 31 (external site)
- KIP-146: Unpredictable Proposer Selection (Final) (external site)
- KIP-279: BlobTx for Kaia (Draft) (external site)
- KIP-286: Permissionless Validator Lifecycle (Draft) (external site)
- Kaia v2.2.2 Release Notice (Osaka hard fork mainnet schedule) (external site)
- consensus/istanbul/backend/engine.go (dev branch): derived from Quorum's Istanbul engine and go-ethereum (external site)
- Scalable Kaia: KaiaBFT (external site)
- [GP-20] Kaia Permissionless Network Policy (English) (external site)
- Supported protocols (external site)
- JPYC GitHub organization (deployment addresses by chain) (external site)
- USDC contract addresses (external site)
- DeFiLlama protocols API (Kaia entries) (external site)
- DragonSwap documentation: Overview (external site)
- KLAYswap documentation: Introduction (external site)
- Ledger Wallet EVM network configuration (config.ts, develop branch; config_currency_klaytn) (external site)
- Ledger Wallet feature switch currencyKlaytn (declared without an enabled value) (external site)
- Ledger Wallet feature-flag defaults (a switch declared with no value is off) (external site)
- Ledger Supported Coins and Tokens (target of the ledger.com Klaytn wallet redirect) (external site)
- Kaia wallet (external site)
- Klaytn (KLAY) wallet page: not supported (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding