[Breaking Change] v2.2.2 Hardfork Upgrade: Removal of Bytecode at address(0)

Summary

Starting from the v2.2.2 Hardfork (estimated date: 07 Apr, 10:03 UTC+9 / block number: 213333000), the bytecode deployed at address(0) on Kaia Mainnet will be completely removed.

After this change, address(0) will behave identically to an EOA without code. Most applications will not be affected, but if any of your logic depends on the previous behavior of address(0), review and update your code before the hardfork.

Motivation

On most EVM chains, address(0) acts as an EOA with no known private key. However, before the merger of Klaytn and Finschia into Kaia, a special contract (CypressCredit) had been injected at address(0) during Klaytn's genesis, causing address(0) to behave differently from other EVM chains.

This has led to compatibility issues when integrating Ethereum-based tooling and open-source contracts on Kaia. With this hardfork, Kaia is aligning address(0) behavior with the EVM standard.

What's changing?

Since Osaka Hardfork on Kaia Mainnet, the address(0) will be identical to EOA without code. It will bring several behavior changes including:

Checklist for Builders

If any of the following apply to your contracts, services, or tooling, action is required before the hardfork. Please check for the items below, including but not limited to:

1. Direct calls to address(0) functions

If your code calls getNames(), getPhoto(), or other CypressCredit functions at address(0), these will no longer exist after the hardfork.

Action: Remove these calls. If you still need the data, migrate it to a separate contract or off-chain storage.

2. Logic that depends on calls to address(0) reverting

Previously, arbitrary calls to address(0) would revert. After the change, they will succeed and return empty data.

*Please note that calls to EOAs without code succeed and return empty data 0x

Action: Replace any branching logic that expects a revert from address(0) with explicit validation (e.g., an address allowlist or zero-address check).

3. Logic that assumes KAIA transfers to address(0) will fail

Previously, sending KAIA to address(0) failed because the contract had no receive or fallback function. After the change, transfers will succeed, meaning KAIA sent to address(0) is effectively burned permanently.

Action: If you relied on transfer failure as a safety mechanism, add an explicit guard such as require(to != address(0)).

4. Code existence checks against address(0)

If your logic uses EXTCODESIZE, EXTCODEHASH, or isContract() to check whether address(0) is a contract, the return values will change.

Action: Review any conditional logic that treats address(0) as a contract. For example, any logic that assumes isContract(address(0)) == true must be updated.

5. Assumptions that address(0) cannot receive funds

This is related to item 3 above, but may also appear in access-control or validation logic beyond simple transfers.

Action: Audit all assumptions about address(0) in your codebase and replace them with explicit address checks where necessary.

How to Verify

1. Test on testnet first. Kairos testnet has never had bytecode at address(0) since genesis, so it already behaves the same as Mainnet will after the hardfork. You can test your contracts on Kairos to verify they work correctly without the bytecode at address(0).
2. Search your codebase. Grep for address(0) across your contracts and off-chain services to identify any logic that matches the checklist above.

Final Notes

This change removes a long-standing Kaia-specific exception and brings address(0) semantics in line with the broader EVM ecosystem. For questions or migration guidance, please reach out through the support channels below. Thank you.

Support Channels

• Kaia Developer Forum: https://devforum.kaia.io/
• Discord: https://discord.com/invite/kaiachain