Toward Ethereum Equivalence #1 — Introducing Klaytn v1.8.0

As mentioned in the Klaytn 2.0 Light Paper, Klaytn has committed to support Ethereum Equivalence. Klaytn v1.8.0 is a major milestone towards this initiative of compatibility which will enable seamless integration of Ethereum development tools with the Klaytn ecosystem. Given the potential impact of this major upgrade on the existing services running on the Klaytn ecosystem, the Klaytn team will be providing an article tetralogy — Toward Ethereum Equivalence for technical explanations on Medium, Klaytn Docs updates, as well as a temporary test network for users to test out the new features included in the Klaytn v1.8.0 release.

Important Changes on the Klaytn Mainnet with v1.8.0

1. Supporting London EVM

All features supported by Ethereum’s London EVM are now supported on Klaytn. Ethereum’s London hard fork is the latest technological update to the Ethereum ecosystem with changes to the EVM.

In other words, every EVM feature will now be available on Klaytn core protocol as well, however it should be noted that there have been some changes made with regard to precompiled contract addresses in the process of supporting London EVM, for which Klaytn developers should take into account. More on this will be covered in our second article in the Toward Ethereum Equivalence series.

2. Supporting Ethereum API Format (eth namespace)

Ethereum development tools will now be applicable for use within the Klaytn ecosystem. Klaytn and Ethereum have divergent data structures which have given rise to compatibility issues with the tooling. From Klaytn v1.8.0 onwards, making an API request using the klay namespace (e.g. klay_getBlockByNumber) will return results in the Klaytn data format exactly the same as what one would retrieve in previous Klaytn versions, whereas the eth namespace (e.g. eth_getBlockByNumber) will return values in Ethereum data format. Due to this additional data format support developers will be able to more readily utilize various development tools like Hardhat and Truffle within the Klaytn ecosystem.

However, given the structural differences between Klaytn and Ethereum, the return values of some of the data fields have been adjusted. For instance, since Klaytn’s consensus mechanism is not based on PoW, the `difficulty` field in the block header has been adjusted to return a different value. We will share such notable differences in Toward Ethereum Equivalence #3 in more detail.

3. New Transaction Types on Klaytn to Support Ethereum Transaction Types

Ethereum’s transaction types AccessList and DynamicFee will be supported. In 2021, Ethereum introduced what is called the transaction types. But varied transaction types are something that Klaytn has had since the launch of its mainnet in 2019, so there was a compatibility issue with Ethereum’s new transaction types. Klaytn v1.8.0 includes fixes to resolve the inconsistencies between transaction types of Klaytn and Ethereum.

Notably, since Klaytn has a different gas fee policy from Ethereum (namely its fixed gas fee structure), the introduction of Ethereum transaction types will not further reduce any transaction fee as they did in Ethereum. More on this will be shared in the upcoming article Toward Ethereum Equivalence #4.

Temporary Test Network for v1.8.0

We are excited to present our test network for Klaytn v1.8.0-rc version currently under QA process. Ecosystem developers can test out the changes of the new version, as well as partaking in the QA process.

​​HTTP Endpoints

Websocket Endpoints

  • wss://
  • wss://



  • This network is a temporary test network intended for testing purposes of Klaytn v1.8.0.
  • This network may be terminated without prior notice after Klaytn v1.8.0 has been fully updated on the Cypress mainnet (ETA: Mid-April).
  • This network does not provide any Service Level Agreements, and is subject to update or suspension without prior notice.
  • If you have any inquiries or find any bugs, please report them on Klaytn Discord (#report-a-bug #dev-support).

Timeline for v1.8.0

Klaytn v1.8.0 will proceed with the following suggested timeline. From the changes listed above, “Supporting Ethereum API format will be applied to each endpoint node (EN) when it is upgraded to Klaytn v1.8.0. Other changes will be effective at the block number where the hard fork upgrade will be applied. The exact block number will be announced in the official release note and covered in our technical articles on Medium.


  • 3/7 — Caver v1.8.0 Deployment
  • 3/16 — Klaytn v1.8.0 Deployment
  • 3/24 (Expected) — Baobab Testnet v1.8.0 hard fork
  • 3/31 (Expected) — Cypress Mainnet v1.8.0 hard fork

Article Series