Skip to main content
Kronex runs the Ethereum Virtual Machine. Solidity contracts, ABIs, events, logs, CREATE2, ERC-20 and ERC-721 all behave as they do on Ethereum, and the usual libraries — ethers, viem, web3.js — talk to a Kronex node without modification. There is exactly one setting you have to change, and getting it wrong produces a contract that deploys and then reverts on every call.

Set the EVM version to London

Kronex’s EVM is at London. Solidity 0.8.20 and newer default to shanghai, which emits the PUSH0 opcode. PUSH0 does not exist on Kronex, so a contract compiled with the default settings fails at runtime.Set evmVersion to london in every project.
What London gives you: EIP-1559 base fee and type-2 transactions, Berlin access lists, and everything below. What it does not give you: PUSH0, transient storage (TSTORE/TLOAD), and MCOPY.

Hardhat

hardhat.config.js

Foundry

foundry.toml

Connect a library

Nothing about the provider is Kronex-specific. If your code already works against an Ethereum node, it works here once the endpoint and chain ID point at Kronex.

Transactions and fees

Kronex uses EIP-1559: blocks carry a base fee, and the priority fee is what miners compete for. Type-0 (legacy), type-1 (access list) and type-2 (dynamic fee) transactions are all accepted, and eth_feeHistory, eth_maxPriorityFeePerGas and eth_estimateGas work as usual.
The priority fees a block collects are not paid entirely to the block’s sealer. They are pooled and split across the block’s recipients — see Rewards. This changes nothing for the sender.

Chain-specific data

Anything Kronex adds on top of Ethereum lives in the krnx_ namespace: supply, lockups, reward schedules, mining status. See the RPC reference.