EVM-equivalent, with instant finality: what's actually different on Krypton
If you have shipped contracts on Ethereum, you already know how to build on Krypton. That is the honest one-sentence summary. But "EVM-compatible" is a claim a hundred chains make, and they do not all mean the same thing. This post explains precisely what Krypton preserves from Ethereum, what it changes, and why those changes exist.
The execution layer is revm — the same EVM you already target
Krypton's execution layer is bera-reth, a fork of Reth running revm as the EVM interpreter. Reth's revm is the same Rust implementation used by Ethereum mainnet clients. Krypton does not wrap Ethereum, simulate it, or re-implement its opcodes: when a transaction hits the Krypton EVM, it runs through the same bytecode interpreter with the same gas schedule.
The consequence is that Krypton is EVM-equivalent, not merely EVM-compatible. The distinction matters:
- EVM-equivalent means the bytecode semantics and gas accounting are identical. A contract compiled for Ethereum and deployed on Krypton behaves the same way, including edge cases.
- EVM-compatible is a weaker claim — it means the chain can run Solidity contracts, but the execution engine may differ in ways that bite you at the margins (custom precompiles, divergent gas schedules, opcode gaps).
Krypton makes the stronger claim. Every tool in your existing workflow connects without modification:
- Foundry and Hardhat work unmodified.
forge test --fork-url <krypton-rpc>and Hardhat forking work the same way they do against Ethereum. - ethers.js and viem connect to the standard
eth_*JSON-RPC namespace. The execution node also surfacesdebug_*,trace_*, andengine_*namespaces — the same surface a full Reth node exposes on Ethereum. - Wallets (MetaMask, etc.) add Krypton as a custom network by chain ID; no browser-extension updates required.
- Blockscout runs as the block explorer at kryscan.com. It indexes Krypton blocks the same way it indexes any EVM chain.
Testnet RPC and explorer details are in the Networks reference.
The consensus layer is CometBFT — instant finality, not probabilistic
This is where Krypton meaningfully diverges from Ethereum, and it is a deliberate product decision rather than a cost-cutting compromise.
Ethereum uses LMD-GHOST and Casper FFG: a block is probabilistically safe after a few slots, and considered finalized after two epochs (roughly 12–15 minutes). Krypton uses CometBFT, a classical BFT consensus algorithm. The practical difference:
When a Krypton block commits, it is final. No reorgs. No waiting for confirmations.
For a Solidity developer, this has direct implications:
- A transaction confirmed in a block does not need any additional confirmation count. One block is final.
- Contract logic that accounts for reorg risk on Ethereum — such as waiting for
SAFEorFINALIZEDtags before releasing funds — can be simplified on Krypton. - L2 bridges and settlement contracts benefit directly: a bridge that settles to Krypton can read a committed state root as final immediately, rather than waiting for Ethereum's two-epoch finalization window.
The tradeoff is honest: BFT consensus requires 2/3 of validators by stake to be online to produce blocks. A chain halt is possible if enough validators go offline simultaneously, whereas Ethereum would continue producing (unfinalized) blocks. This is a liveness tradeoff that is well-understood and appropriate for a chain that prioritizes safety and instant settlement.
The consensus node (beacond) drives the execution node (bera-reth) over the standard Engine API — the same interface Ethereum uses between its consensus and execution clients. The CL/EL split follows a well-tested integration pattern rather than a hand-rolled bridge.
Two protocol-level divergences from Ethereum you should know about
1. Fee routing instead of fee burning
On Ethereum, EIP-1559 burns the base fee. On Krypton, the base fee is redirected instead of burned.
The mechanism: the block coinbase is hardcoded in the execution layer to a protocol-controlled address called FEE_SINK. In post-execution accounting, the base fee is credited to FEE_SINK minus a governable burn fraction called baseFeeBurnBps. At genesis, baseFeeBurnBps is 0 — meaning 100% of the base fee goes to the sink rather than being burned.
What Ethereum does, in effect:
burn baseFeeTotalWhat Krypton does:
burn = baseFeeTotal × baseFeeBurnBps / 10_000
toSink = (baseFeeTotal − burn) + priorityTipsTotal
credit FEE_SINK by toSink
assert burn + toSink == baseFeeTotal + priorityTipsTotal // value conservationThe value-conservation assertion runs on every node. The intent is that fees flow to the protocol — to stakers and the security budget — rather than disappearing. Governance can dial baseFeeBurnBps up over time if the economics warrant a burn component. At launch it is zero.
What this means for you as a contract developer: fee economics are the same at the transaction level. You still pay base fee plus priority tip; tx.gasprice, block.basefee, and gas accounting all behave normally. The difference is purely in where those fees land after execution.
It also means block.coinbase is always FEE_SINK, not a validator's address. If your contract uses block.coinbase for anything other than academic purposes, audit that logic.
2. EIP-4844 blob transactions
Ethereum's Cancun upgrade introduced blob-carrying transactions (EIP-4844) for cheap L2 data availability. Treat blob support as a known divergence to verify against the current release rather than assume — EIP-4844 is primarily an L2-data-availability concern, so if you are building application contracts (not a rollup that posts blobs to L1), it is unlikely to affect you. If your design depends on native blob transactions, confirm the behavior on the target network before relying on it.
Chain IDs
- Testnet:
473374(0x7391e) — the public network the node setup guides target. - Mainnet:
47337(0xb8e9) — reserved and gated on an external security audit of the two consensus reward patches. Do not point production value at this chain ID until that gate clears; this documentation will be updated when it does.
These protocol patches are determinism-proven — byte-identical state across a 4-validator network — but mainnet is not live.
Summary for the EVM developer
| Property | Ethereum | Krypton |
|---|---|---|
| EVM interpreter | revm (and others) | revm (same) |
| Bytecode / gas semantics | EIP-specified | Identical |
| JSON-RPC namespaces | eth_*, debug_*, trace_* | Same |
| Finality | Probabilistic (~12–15 min) | Instant single-slot BFT |
| Reorg risk | Yes | No |
| Base fee | Burned (EIP-1559) | Redirected to FEE_SINK; burn fraction governance-controlled |
block.coinbase | Validator fee recipient | FEE_SINK (hardcoded) |
| Foundry / Hardhat | Yes | Yes, unmodified |
| Blockscout explorer | Yes | Yes |
The short version: deploy your contracts as you would on Ethereum. Expect your tests to pass. Watch block.coinbase if you use it. Know that a confirmed block is final.