Krypton L1: an overview

Krypton is a sovereign, EVM-equivalent proof-of-stake Layer-1. It is not a rollup, not an app-chain, and not a fork of Ethereum mainnet — it is an independent chain with its own validator set, its own genesis, and its own consensus. This post covers what it is, how the node software is structured, and where things currently stand.

The architecture in two sentences

Every Krypton node runs two processes wired by the Engine API: beacond, a fork of Berachain's beacon-kit (CometBFT/Tendermint BFT consensus), and bera-reth, a fork of Reth running revm (EVM execution). The split follows the same Engine API boundary as post-Merge Ethereum, but swaps the probabilistic beacon chain for a BFT consensus engine that gives instant, single-slot finality.

        validators ──┐
        (sign blocks) │   CometBFT BFT consensus (instant finality)
                      ▼
   ┌──────────────────────────────────┐   Engine API   ┌──────────────────────┐
   │ beacond (CL, beacon-kit/CometBFT) │ ─────────────▶ │ bera-reth (EL, revm) │
   └──────────────────────────────────┘                └──────────────────────┘
                      │
            RPC / full nodes (L5) ── eth_getProof ──▶  edge nodes (light clients)
                      │
            block explorer (kryscan.com) · monitoring · public RPC

The EVM side is revm — the same interpreter inside a standard Reth node. Standard Solidity and Foundry toolchains work unchanged against Krypton RPC.

Why CometBFT over a probabilistic beacon

CometBFT's BFT guarantee means that once a block is committed, it is final. There are no reorgs, no missed slots, and no two-epoch (~12 minute) wait for Ethereum-style finality. One CometBFT height equals one canonical block, and the commit is irreversible. This matters most for bridge and rollup use cases where a downstream system needs to act on settled state: a 1-block bridge is a qualitatively different product than one that requires watching for a 64-block confirmation window.

The tradeoff is explicit: CometBFT requires 2/3+ of validators online to produce blocks. A small early validator set has real halt risk if multiple operators go offline simultaneously.

Node types

The node overview defines four distinct roles. Each needs the same two binaries; behavior is driven by configuration.

Role	What it does	Key constraint
Validator	Signs and proposes blocks; holds (or threshold-signs) the consensus key	24/7 uptime required; double-sign is slashable
RPC / full node (L5)	Non-validating; serves `eth_getProof` (EIP-1186) and full JSON-RPC to wallets, dApps, the block explorer, and edge clients	8 vCPU, 32 GB RAM, 1–2 TB NVMe (MDBX is NVMe-sensitive)
Seed / bootnode	Peer discovery only; smallest box in the fleet	2 vCPU, 8 GB, 100 GB SSD
Edge node	Verifying light client — holds no state, no key, no reward; verifies every read against the BLS commit chain	Runs on a Raspberry Pi 4/5, x86, or any ARM/VM/container

The edge node is not a "lite wallet" in the traditional sense. It runs a full verification pipeline: BLS commit verification → header binding → SSZ state-root anchor → eth_getProof → revm eth_call. It trusts no single RPC endpoint. This is the role suited to a home appliance that someone wants to run for self-sovereign chain access without the storage and bandwidth cost of a full node.

The full decision guide walks through hardware specs and port requirements for each role.

The app-layer economic suite

Krypton's staking, governance, slashing, and reward logic lives in Solidity, not in custom consensus code. This is a deliberate architecture choice: keep beacond and bera-reth as close to upstream as possible, and push economic policy into auditable, upgradeable contracts.

The suite in contracts/staking/ includes:

StakingRouter — validator registration, delegation, unbonding (mirror model)
FeeDistributor — routes block rewards to delegators via pluggable IRewardSource implementations
SlashingModule — applies pooled-share economics when a validator equivocates; reduces every delegator's redemption pro-rata; burn + tombstone
KryptonGovernor + TimelockController — on-chain parameter governance; all governed contracts are owned by the timelock
WithdrawalManager — unbonding reconciliation against EIP-7002 EL withdrawal requests

Native gas token: KRY. Staking token: stKRY (non-transferable).

The suite has 177 Foundry tests and has undergone a round-1 internal audit (Slither + economic-invariants + access-control review). One CRITICAL, four HIGH, and six actionable MEDIUM findings were identified and fixed. An external professional audit is required before mainnet — this internal round is audit-prep, not a substitute.

Consensus reward patches

Two patches on top of the upstream forks handle inflation and fee routing:

Epoch-mint patch (beacond): a deterministic, curve-derived inflation amount credited to INFLATION_SINK each block
Fee-router patch (bera-reth): redirects EL block fees to FEE_SINK rather than burning them (base-fee burn is set to zero at launch)

Both patches are applied post-clone in the build Dockerfiles and have been verified for determinism on a 4-validator network: 139+ blocks across 4+ epochs finalized with byte-identical EL stateRoot, CL app_hash, and sink balances across all nodes.

The reward model targets bonding-ratio inflation: it starts at 7% (with a 50% bonded-ratio target) and tapers the cap from 8% toward a terminal ~1.5% over roughly 8 years, transitioning toward fee-driven real yield as the network matures.

Supporting services

Service	Implementation	Status
Block explorer	Blockscout, branded as kryscan.com	Deploy overlay built; not yet stood up
Monitoring	Prometheus + Grafana	Deploy stack and dashboards built; not yet running
Validator key management	Horcrux 2-of-3 threshold signing	Deploy artifact built; not yet stood up
Secrets management	HashiCorp Vault / AWS KMS	Deploy overlay built; not yet stood up
Deployment	docker-compose (all roles) + systemd unit + Helm chart	Config-validated

The distinction between "artifact built" and "running" matters here and is covered in the status section below.

Networks and chain IDs

Network	Chain ID	Hex	Status
Testnet	473374	`0x7391e`	the public network these guides target
Mainnet	47337	`0xb8e9`	reuses the same artifacts; gated on external audit + testnet soak
Devnet	80087	—	local Kurtosis / ephemeral

See Networks & chain IDs for the canonical allocation.

Honest status

The patched binaries are determinism-proven on a 4-validator Kurtosis network. Stake-in (4→5 validator activation) and stake-out (EIP-7002 voluntary exit, active set 4→3) are both proven live on the matched beacon-kit v1.3.9 / bera-reth v1.3.3 pair.

What is not yet done:

The AWS/baremetal raw-compose deploy path is config-validated but has not been run end-to-end on real cloud or baremetal hardware. Treat a first deployment as a bring-up exercise.
The public testnet (473374) is not yet launched.
Mainnet is gated on an external professional audit (contracts, consensus/ABCI bridge, and execution fork) and a clean public-testnet soak.
Two consensus seams remain open: automated CometBFT equivocation-evidence → EVM slashing ingestion (the current slashing reporter is a trusted bridge, not fully automated), and automated CL↔EL fee-coverage readback.

The chain is past "can we build it?" The remaining gates are validation and operations: external audit, testnet soak, and standing up the operational fleet.

For more detail, start at the introduction or go directly to the node overview.

Krypton L1: an overview ​

The architecture in two sentences ​

Why CometBFT over a probabilistic beacon ​

Node types ​

The app-layer economic suite ​

Consensus reward patches ​

Supporting services ​

Networks and chain IDs ​

Honest status ​