Indexed KaiaBlockchain Data

Kaia is the chain that launched as Klaytn in 2019 and was renamed in a hard fork whose transition activated on mainnet on 29 August 2024, keeping the same chain ID and the same block numbering. It came out of a merger with Finschia: KLAY balances were reflected as KAIA, while FNSA holders burned their tokens on the Finschia network and claimed the new asset here. Consensus is an optimized Istanbul BFT, so a block is produced and confirmed in about a second with immediate finality, and validators form a council rather than an open set. Execution is the EVM over twenty-byte addresses, with two additions Ethereum lacks: transaction types in which a fee payer other than the sender covers gas, and accounts whose keys can be multi-signature or role-based. Compare the validator model with BSC.

SonarX indexes Kaia blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, in the normalized model used on every chain SonarX covers.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. The real-time balances API and the batch wallets, tokens and balances API are available for Kaia, and the rest can be enabled on request. Kafka streaming can be enabled for Kaia on request.

Transactions on this chain do not all have Ethereum’s shape. Fee delegation means the account that paid is often not the account that sent, and partial delegation splits one cost between two parties, so cost attribution is a two-sided record rather than a subtraction from the sender’s balance. Account keys are the second difference: a single account can be controlled by several keys with distinct roles, so authorization is not a one-to-one mapping from address to signer. The rename is the third. Balances that read as KLAY before August 2024 read as KAIA after it, in one unbroken series, and a pipeline that treats them as two assets will double count supply.

Sponsored-transaction accounting is the workload specific to this chain. When an application pays its users’ gas, the cost of running that application is a fee-payer series, not a sum of user fees, and only the delegated records answer it. Consumer token and NFT analysis is the second job, since much of the activity here comes from applications with large retail user bases, and token analytics covers the asset side of it across networks. Portfolio and treasury reporting is the third and has to run through the rename cleanly. Teams comparing chains with fixed producer sets often look at TRON alongside it.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Kaia history back to the Klaytn years and the balance APIs are available now, so a first delivery is usually a provisioning question. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.