Kaia RPC: The Merged Klaytn + Finschia Chain, for Developers

Kaia is one of the largest chains most Western developers have barely touched - and that's a distribution opportunity. Formed in August 2024 by merging Klaytn (Kakao's chain) and Finschia (LINE's chain), Kaia is an EVM Layer 1 with a built-in path to hundreds of millions of messaging-app users across Asia. For developers, the good news is that connecting to it is almost identical to Ethereum. Here's the map.

The Essentials

Kaia mainnet is chain ID 8217 (inherited from Klaytn). It's an EVM-compatible Layer 1 running BFT proof-of-stake consensus with ~1-second block times and immediate finality. The native token is KAIA (18 decimals).

Because it's EVM-compatible, standard Ethereum tooling connects without changes:

import { createPublicClient, http } from "viem";
import { kaia } from "viem/chains";

const client = createPublicClient({
  chain: kaia, // chain ID 8217
  transport: http("https://rpc.swiftnodes.io/rpc/kaia?key=YOUR_API_KEY"),
});

await client.getBlockNumber(); // just works

Solidity contracts, ABIs, deploy scripts, and read/write flows behave as they do on Ethereum. Reading a receipt and estimating gas work the same way.

Two RPC Namespaces: eth_* and the Klaytn-Heritage klay_*

Here's the one thing worth knowing up front. Kaia inherits Klaytn's original JSON-RPC, which used a klay_* namespace (e.g., klay_blockNumber, klay_getBalance) mirroring Ethereum's methods. To make life easier for Ethereum developers, Kaia also exposes the standard eth_* namespace. Use eth_*. It's what viem, ethers, web3.py, and every standard tool expect, and SwiftNodes serves it directly:

curl -s -X POST https://rpc.swiftnodes.io/rpc/kaia?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"result":"0x2019"} (0x2019 = 8217)

The klay_* / kaia_* namespace is still there if you need Kaia-native features (below), but for ordinary reads, writes, and contract calls, treat Kaia as a standard EVM chain and reach for eth_*.

Immediate Finality: No Reorgs

Kaia uses BFT consensus with immediate finality - once a block is produced and committed by the validator set, it is final and cannot be reverted. There's no probabilistic settling and, in normal operation, no reorgs.

For an RPC consumer that's a real simplification, the same benefit we covered for Sei:

• The latest block is effectively already final - you don't need deep confirmation waits before crediting a deposit or acting on an event.
• Indexers can largely skip reorg-handling logic - no parent-hash break detection, no rollback (contrast the reorg handling an Ethereum indexer needs).

Combined with ~1-second blocks, Kaia is a fast, deterministic target - great for consumer apps where users expect instant confirmation.

The Klaytn Feature That's Genuinely Different: Fee Delegation

Kaia's standout capability, inherited from Klaytn, is fee delegation - a transaction can be paid for by a different account (a "fee payer") than the one sending it. The user signs the transaction; a separate fee-payer account signs to cover the gas.

This is how Klaytn/Kaia apps deliver gasless UX to end users without account-abstraction gymnastics - the app sponsors fees natively at the protocol level.

The catch: fee-delegated transactions use Kaia-native transaction types, not standard Ethereum transactions, so you build them with the Kaia SDK (ethers-ext / web3js-ext or the native libraries), not vanilla sendTransaction.

If you're building a consumer app on Kaia and want to sponsor user gas, this is the feature to reach for - and it's a big part of why Kaia suits messaging-app-distributed apps. Standard (non-delegated) transactions remain plain EVM.

Why Kaia Matters: Distribution

The strategic point isn't the tech - it's the audience. Klaytn was Kakao's chain; Finschia was LINE's. Merged into Kaia, the chain has a direct integration path to the Mini Dapp / messaging-app ecosystem across Japan, Korea, and Southeast Asia - hundreds of millions of users who already have wallets tied to apps they use daily.

For a developer, "EVM chain with a built-in Asian consumer funnel" is a genuinely different value proposition from another general-purpose L2.

What Carries Over Unchanged

Treat Kaia as standard EVM for almost everything:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction all behave normally.
• Solidity contracts, ABIs, events, and tooling deploy and run without changes.
• WebSocket subscriptions (eth_subscribe) for newHeads and logs work.
• KAIA is the gas token (18 decimals) - no exotic fee handling for normal transactions.

The rule of thumb: build on Kaia as you would on Ethereum via eth_* - then, if you want gasless consumer UX, layer in fee delegation with the Kaia SDK, and enjoy the fact that immediate finality means you can trust one block.

The Short Version

Kaia (chain ID 8217) is the EVM L1 formed by merging Klaytn and Finschia, with ~1-second blocks, immediate BFT finality (no reorgs), and a large Asian messaging-app user base. It exposes both the standard eth_* namespace (use this - viem/ethers just work) and the legacy klay_* namespace for Kaia-native features. The one feature worth learning is fee delegation - protocol-level gas sponsorship for gasless UX, built via the Kaia SDK. Otherwise, it's standard EVM you can treat like Ethereum, minus the reorg anxiety.

Reaching Kaia's user base needs an endpoint that keeps up with its fast blocks. A flat-rate Kaia RPC endpoint gives you the full eth_* surface plus WebSocket subscriptions across dozens of chains under one key. Grab a free key and point your app at: https://rpc.swiftnodes.io/rpc/kaia?key=YOUR_API_KEY

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints - HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.