Update: Klaytn Contract Library

In line with the recent network upgrades, and our recent push to achieve Ethereum Equivalence Klaytn has now released an updated version of its contracts library. With this update comes several significant topics to be aware of as a smart contract developer:

  • There is now support for ERC/EIP smart contract standards within the Klaytn ecosystem
  • The new Klaytn contracts library update utilizes the popular Ethereum based OpenZeppelin library standardization
  • Klaytn will continue to support full backwards compatibility for existing KIP contract standards (KIP-7, KIP-13, KIP-17, and KIP-37)
  • The scope of new KIPs for smart contract standards should no longer duplicate ERC/EIP standards but are instead intended for new and unique Klaytn ecosystem smart contract standards and innovations.
  • Developers should take under consideration standard usage as well as the mixing and matching of existing KIP standards with their ERC/EIP counterparts

The updated Klaytn contract library can be found at

`klaytn-contracts` is an open source smart contract library which provides reusable building blocks for developers to easily use in their Klaytn based projects. It contains a full suite of standardized smart contract interfaces, libraries, and implementations for quick and safe inheritance and development.

Below are a few items which are widely used and included in the `klaytn-contracts` repository

  • Access Control: Smart contracts for allowing and managing elevated permissioning at the contract and function level.
  • Tokens: Smart contracts to create tokens, assets, or collections, this includes both fungible and non-fungible token standards. 
  • Proxy: Smart Contracts to facilitate the upgradability of contracts through a proxy pattern.
  • Utilities: generic code blocks and common tools, including non-overflowing maths, signature verification, and escrow… among others
  • Security: Smart contract modules to help prevent known security vulnerabilities

When to use a smart contract library

Using a smart contract library for your project has several benefits. 

  1. First and foremost, developers save time by using ready-to-use building blocks which can be imported and included directly in their projects, rather than having to develop code themselves.
  2. Smart contract libraries use standardized coding style and coding patterns for clean readable code which makes understanding and using the code much easier.
  3. Better security is also a major plus. Open source smart contract libraries are often heavily scrutinized and widely used. Some libraries also undergo external audits for additional security. While this is not a guarantee against unknown code errors or exploits, it helps mitigate individual project implementation errors.

However, using external smart contract libraries carries the risk of including code a developer is not familiar with into their project. It’s tempting to import a contract and include it directly into a project without deep research, but without a good understanding of what that contract does, developers may be inadvertently introducing unexpected behavior or unwanted logic into their project. 

Always make sure to read the documentation of the code you are importing, and review the code itself before making it a part of your project. Security and correctness of implementation should always be a developer’s primary focus when building with smart contracts.

How to use `klaytn-contracts` in your own project

`klaytn-contracts` is packaged using npm, to install use the following:

npm install @klaytn/contracts

Most IDEs and tools for compiling contracts (i.e. Truffle, Hardhat, etc…) will access your project’s `node_modules` folder for easy usage of smart contract packages. As such, you can do the following to import and use `’klaytn-contract` smart contract code directly in your project:

// This will load the klaytn-contracts package from node_modules
import “@klaytn/contracts/token/ERC721/ERC721.sol”;

contract MyNFT is ERC721 {
    constructor() ERC721("MyNFT", "MNFT") public { }

OpenZeppelin and ERC/EIP standards support

As a part of our Ethereum Equivalence initiative Klaytn will now support ERC/EIP contract standards in its ecosystem, as such we also have made a commitment to maintain a modified fork of the most popular and well used EVM based contracts library. 

The updated `klaytn-contracts` repository is a fork of the well maintained and well used OpenZeppelin Contracts repository. If you are new to OpenZeppelin or contracting with their repository, they have extensive documentation for reading and understanding the latest smart contract standards, patterns, and changes.

Continued KIP standards support

For the `klatyn-contracts` repository, in addition to containing the latest ERC/EIP standard contract implementations provided by OpenZeppelin, Klaytn will also include maintained versions of the existing KIP contract standards as well as any future KIP contract standards to be officially accepted by the Klaytn community.

To ensure backwards compatibility, the `klaytn-contracts` repository will maintain the latest stable versions of implementations (solc 0.8.0 at the time of writing) of the existing KIP standards KIP-7, KIP-13, KIP-17, and KIP-37.

Corresponding EIP and KIP standard considerations

The above mentioned four existing KIPs are Klaytn equivalents to their Ethereum counterparts and in this way they operate in much the same way (oftentimes exactly the same) as their corresponding ERC/EIP standard. However, there are some nuanced implementation and usage considerations if a developer considers using these standards interchangeably.

KIP-7 and ERC-20

KIP-7 is based on the ERC-20 fungible token smart contract standard. To be precise, KIP-7 holds the same interface as ERC-20 except it includes the addition of the following methods:

function safeTransfer(address recipient, uint256 amount, bytes data)
function safeTransfer(address recipient, uint256 amount)
function safeTransferFrom(address sender, address recipient, uint256 amount, bytes data)
function safeTransferFrom(address sender, address recipient, uint256 amount)

These methods were added to follow the common token transfer pattern of verifying receiver operator contracts (modelled after ERC-721 safeTransferFrom) as well as being able to trigger additional logic on the receiving contract when transfers occur by including and implementing the IKIP7TokenReceiver  interface and the  onKIP7Received  method in the receiving operator contract.

Nonetheless, these `safe` functions are not included in the ERC-20 interface definition, which makes the ERC-20 interface a strict subset of the KIP-7 token standard interface. As such the following behaviour is to be expected when interacting between the two:

  • KIP-7 tokens can be used inside an ERC-20 interface without any code changes. This is because the functionality exposed by the ERC-20 standard is strictly a subset of the KIP-7 interface. Note: wrapping an existing KIP-7 token into an ERC-20 interface will prohibit usage of its safeTransfer  and safeTransferFrom  functionality unless these are exposed via some other means.
  • When using ERC-20 tokens in a KIP7 interface, extra logic should implement safeTransfer  and safeTransferFrom for interface consistency. This is because the ERC-20 standard does not have these functions available.

KIP-17 and ERC-721

KIP-17 and ERC-721 are exactly equivalent in terms of interfaces. Similar to the KIP7/ERC20 case there are two ways to integrate these two standards, via simple interface usage, or via the deeper wrapped token method. Aside from the considerations of using these two interaction strategies and the fact that KIP-17 inherits KIP-13 for introspection while ERC-721 uses ERC-165, the KIP-17 and ERC-721 standard are equivalent. 

KIP-37 and ERC-1155

The KIP-37 and ERC-1155 interface standards are also equivalent, and also only differ internally in the same ways, i.e., they use KIP-13 and ERC-165 for introspection respectively.

KIP-13 and ERC-165

KIP-13 and ERC-165 support the exact same interface and functionality. The only difference is in the naming of the two standards (which does not affect the interfaceId return value).

EIP and KIP wrapping considerations

For all of the above KIP to ERC interactions, it should also be noted that there are two methods to manage KIP and ERC token interfacing:

  • The first method is basic interface usage. This method simply implements the usage of one (or the other) interface `around` the original token standard implementation, examples of this usage will be released soon here.
    • If using this method developers should remember that while you may be using one token standard within the other token’s interface, the actual tokens being sent are of the original type, and as such, any receiver contract must also have logic to handle the original token standard. 
    • For example, if using a KIP17 token within an IERC721 interface, when calling the safeTransfer or safeTransferFrom methods, any receiver contract would still need to implement onKIP17Received not onERC721Received along with other KIP17 token handler logic.
    • Due to the above considerations this method may be best for intra contracting use cases rather than inter-contracting usage.
  • The second method uses a wrapped token strategy. This method requires the deposit of the original standard token and in return distributes an equivalent wrapped version of tokens in the other interface. An example of a generalised wrapped token implementation for both KIP and ERC standards will be released soon here.
    • This methodology has overhead in terms of deployment of a wrapped token contract as well as extra transactions for deposit and withdrawal, but is very clear cut for inter-contract usage. Deposit the original token, receive the wrapped standard token and use that wrapped token anywhere.

New KIPs and change of policy

Since Klaytn will now accept EIP/ERC standards into its ecosystem freely, we have decided to change our approach toward the usage of KIP standards moving forward in the following ways:

  • The existing KIP standards will be maintained for backwards compatibility within the Klaytn ecosystem.
  • Any new KIP standard creation will be reserved for unique or novel standards originating from the Klaytn community which do not replicate in interface or implementation an existing EIP/ERC standard, except for the below
  • If the Klayn community decides to diverge significantly (for any manner of reason) from an existing EIP/ERC standard definition, then a new KIP can be considered

The primary driving force behind this policy change is three fold. Firstly, we want to welcome the innovation and well intentioned standards (and standard creation process) of the Ethereum community into the Klaytn ecosystem. Secondly, we want to maintain backwards compatibility and support for the existing KIP standards. And lastly, we want to allow the Klatyn community to contribute its own unique standard to both the Klaytn and Ethereum ecosystems. It is our belief that community and collaboration are core tenets of the blockchain industry and such an approach will only benefit all.

For more information on upcoming updates, or to continue the dialogue please follow our social media channels here or visit our discord or forum.