Architecture

Krypton is a sovereign, EVM-compatible proof-of-stake L1 built by forking two mature clients over a standard Engine-API split — not by writing a consensus engine or an EVM from scratch. This page explains the pieces, why they were chosen, and where the sovereign economics live.

New here? Read the Introduction first for the one-paragraph overview, then this page for the component-level detail.

Build-vs-fork: why a fork

Building an L1 client from scratch in 2026 recapitulates Ethereum-client history with no differentiation; every credible new EVM chain forks. The decision was fork — CometBFT (consensus) + Reth (execution) over an Engine-API split, in the proven, integrated form of Berachain's beacon-kit + bera-reth, built from source.

Layer	Choice	Why
Execution	Reth → bera-reth (Apache-2.0, Rust, revm)	Permissive, no copyleft, high performance. LGPL clients (Geth, Erigon core, Nethermind) carry source-disclosure overhead for a commercial product; Besu (Apache) was rejected for the JVM operational mismatch.
Consensus	BFT — CometBFT (via beacon-kit), not Ethereum-style probabilistic	Gives instant single-slot finality — a 1-block bridge instead of a ~12-minute (2-epoch) wait — the material product differentiator for L2 settlement and L4 bridging.

Tradeoff (consensus). BFT liveness needs 2/3+ of validators online, so a small early validator set has real halt risk, and EVM-equivalence must be tracked manually as Ethereum ships EIPs.

Rejected: consensus from scratch (solved, but catastrophic when wrong); forking an app-chain (Evmos/Cronos — inherits their debt + tooling divergence); OP Stack / Arbitrum Orbit settling to Ethereum (that would make this a rollup, not a sovereign L1).

Why the Engine-API split lowers risk

Because the EL/CL split keeps a standard Engine API (no hand-rolled ABCI state-transition bridge), bridge-correctness risk is materially lower than a from-scratch BFT+EVM integration.

The two clients

        validators ──┐
        (sign blocks) │   CometBFT BFT consensus (instant finality)
                      ▼
   ┌──────────────────────────────────┐   Engine API   ┌──────────────────────┐
   │ beacond (CL, beacon-kit/CometBFT) │ ─────────────▶ │ bera-reth (EL, revm) │
   └──────────────────────────────────┘                └──────────────────────┘

Component	Role
beacond (CL — beacon-kit / CometBFT)	Tendermint BFT (propose / prevote / precommit), stake-weighted proposer selection, validator-set updates, double-sign evidence + slashing. Drives the EL over the Engine API.
bera-reth (EL — revm)	All EVM state transitions; chain data (blocks / state / receipts) in MDBX; standard eth_* / debug_* / trace_* / engine_* RPC. The fork adds the chain-id, genesis/gas-token config, and the fee-router.

The CL reaches the EL engine API at http://el:8551 over the internal network; 8551 is never published. See Ports & firewall.

EVM equivalence (revm)

Krypton is EVM-equivalent at the execution layer: it runs revm, the same EVM as a Reth mainnet node — not a from-scratch reimplementation. Standard Solidity / Vyper and Foundry (forge / cast / anvil) work unchanged.

The chain differs from Ethereum at the consensus layer (BFT instant finality, not probabilistic) and in a few governed economics — most visibly, the base fee is redirected, not burned (see the fee-router below).

The sovereign app-layer suite

Consensus staking (who is in the CometBFT validator set, and with what voting power) stays beacon-kit-native: deposits to the BeaconDeposit predeploy at 0x4242…4242 are ingested via the v1.3.9 eth_getLogs bridge and drive the CometBFT set. The sovereign app-layer suite sits on top to provide the economic layer — delegation, reward routing, fee distribution, on-chain governance, and the slashing hook. Native gas token KRY plus a non-transferable stKRY.

Contract	Responsibility
StakingRouter	Validator + delegator registry; delegation accounting; unbonding queue.
FeeDistributor	Reward routing and claims; pulls value from a pluggable IRewardSource.
KryptonGovernor + Timelock	On-chain governance: parameters, upgrades, treasury spend.
SlashingModule	The ISlashingSink hook (W3 boundary — no slashing implementation designed in the app layer).
ValidatorSetOracle	The seam — feeds the active validator set + effective balances back into the EVM.

The seam is the hard problem, not the contracts

The validator set lives in consensus state, not EVM state, and is not EVM-addressable. Two facts dominate the design:

1. Source of truth for stake is split. Consensus voting power = beacon state; economic stake / delegation = EVM (StakingRouter). These must be reconciled, never double-counted — the single most security-sensitive invariant.
2. Value must reach the app layer. block.coinbase is 0x0 and inflation is zeroed by default, so the reward source is pluggable (IRewardSource).

The suite was built as a Foundry project (177 tests, internally audited). The reward model (W4) and slashing (W3) are deliberately left as replaceable interfaces.

The two reward patches (built + determinism-proven)

The missing economic value reaches the app layer via two consensus-critical patches. Both reuse a proven CL↔EL crossing — they credit a fixed predeploy "sink" address that an EVM contract sweeps — rather than inventing a new bridge.

Patch	Direction	What crosses	Notes
(1) beacon-kit epoch-mint	CL writes EVM balance	minted KRY → INFLATION_SINK	A re-parametrization of a live mint: beacon-kit already mints a fixed amount every block (EVMInflationWithdrawal); the patch makes the per-block amount a state-carried, curve-derived value and points it at INFLATION_SINK. The launch security budget.
(2) bera-reth fee-router	EL writes EVM balance	base-fee + priority tips → FEE_SINK (minus burn)	Forces block.coinbase to the FEE_SINK predeploy in-protocol (not via the proposer-supplied suggestedFeeRecipient); redirects the base fee (normally burned) minus a governance baseFeeBurnBps (genesis 0 = full redirect). The growing real-yield source.

Determinism is the load-bearing requirement

Each patch runs inside block/epoch processing on every validator. Any non-pure input (wall-clock, floats, map-iteration order, off-chain reads) would fork the chain. Both patches use integer-only math with value-conservation asserts, and were finalized in lockstep with byte-identical state across a 4-validator network — see Building the images and the bring-up log.

A third patch — CometBFT equivocation-evidence → EVM slashing ingestion — replaces the trusted-reporter slashing bridge with an in-protocol path. It is the open W3 item and the highest-risk crossing (it both crosses the seam and triggers a value-destroying slash). It is not built yet.

Where to go next

• Run a node: Prerequisites → Quick start.
• Pick a role: Choosing a node type.
• Reference: Networks & chain IDs · Genesis & the network bundle.