Kaia v2.2 Overview — Ethereum compatibility work planned for 2026 (v2.2.0, late Jan testnet)

[sean.lin]

TL;DR
Kaia v2.2 is a compatibility + infra upgrade planned for early 2026. It focuses on:

1. Blob transactions (EIP-4844) for data availability foundations,
2. secp256r1 precompile (EIP-7951) for passkey/WebAuthn-style UX groundwork, and
3. tooling parity improvements (eth_config + ModExp gas alignment + smaller EVM parity fixes).

Article: https://blog.kaia.io/kaia-v2-2-overview-en/

Release plan

• Testnet: targeted for late January 2026
• Mainnet: targeted for late February 2026

What’s in v2.2

1) Data availability foundation (BlobTx / EIP-4844)

• Adds support for blob transactions as a foundation for data-heavy architectures (including L2/rollup-style systems).
• Uses sidecar handling via JSON-RPC (not Ethereum’s Beacon API framework), per the overview.

2) Account abstraction enablement (passkey groundwork)

• Adds a secp256r1 precompile to support more efficient verification for passkey/WebAuthn-style flows and smart account patterns.

3) Developer tooling parity

• Adds eth_config for better hard fork coordination across tooling/operators.
• Aligns ModExp gas behavior (and includes smaller EVM parity changes).

What’s not in v2.2

• No consensus changes in v2.2
• No permissionless validator change in v2.2
  (Compatibility work is scoped separately from broader redesign efforts.)

Questions welcome

If you’re planning around v2.2, reply with:

• what you build (app/wallet/infra /L2/rollup tooling)
• what you’re worried about (RPC surface, signing/account model, blob plumbing, fork coordination)
• any “must-have” parity gaps you’re tracking

We’ll consolidate the common themes and reply in-thread.

[sean.lin]

Concrete scenario: you’re planning around v2.2 as a wallet/app/infra team and want to know what to start testing first (blobs, passkeys, or tooling parity), without waiting for mainnet.

Things to think about:

• For BlobTx testing: treat blobs as “new plumbing” in your tx + RPC path (and remember sidecars are served via JSON-RPC, not a Beacon API flow).
• For passkey/WebAuthn groundwork: map where a secp256r1-friendly verification path changes your signing/account UX assumptions (especially onboarding + recovery flows).
• For tooling parity: plan how you’ll use eth_config for fork checks across clients/services, and don’t leave this to the last minute if you run infra.

Targets: testnet early Feb 2026, mainnet late Feb 2026. No consensus changes in v2.2.

Full overview: Kaia v2.2 Overview
If you’re planning for v2.2, reply with what you build (app/wallet/infra /L2 tooling) + which area you care about most (blobs/passkeys/fork coordination), and we’ll reply in-thread.