Choosing a node type
Krypton runs as two containers per host wired by the Engine API: the consensus layer beacond (a berachain/beacon-kit fork, CometBFT consensus with instant single-slot finality) and the execution layer bera-reth (Reth/revm). One docker-compose.yml serves every role; behaviour is driven by .env toggles. This page helps you pick the role, then sends you to its dedicated install/deploy/operate guide.
Networks
These guides target the public testnet, chain-id 473374 (0x7391e). Mainnet 47337 (0xb8e9) reuses the same artifacts and is gated on an external audit plus a clean testnet soak. See Networks & chain IDs.
Decision guide
Answer top-to-bottom; the first match is your role.
| If you want to… | Run a… | Stakes | Page |
|---|---|---|---|
| Sign and propose blocks, earn rewards, secure the chain | Validator | Highest — holds a signing key; double-sign is slashable | Validator node |
Serve eth_getProof / JSON-RPC to wallets, dApps, the explorer, and edge/light clients | RPC / full node (L5) | Medium — non-validating, no key | RPC node |
| Help peers discover each other; run the smallest, cheapest box | Seed / bootnode | Low — non-validating, tiny | Seed node |
| Get trust-minimized chain access for yourself, without running a full node (turnkey on a Raspberry Pi; also runs on other hardware) | Edge node (verifying light client) | None — no key, no state, no reward | Edge node |
A validator is not a "set and forget" box
A validator must be 24/7 with a stable public IP; downtime has a consensus cost now and a slashing/inactivity cost on mainnet. If you only need read access, run an edge node or a seed, not a validator. Never stack multiple validators on one host — it destroys fault independence.
Role / hardware summary
Baselines for testnet. The full matrix (AWS instance types, baremetal, cost tiers) is in Hardware specs.
| Role | vCPU | RAM | Disk | Sync | Public ports |
|---|---|---|---|---|---|
| Validator | 4 | 16 GB | 500 GB NVMe (pruned) | --full | 30303, 26656 |
| RPC / L5 | 8 | 32 GB | 1–2 TB NVMe (archive = larger) | --full or archive | 30303, 26656 |
| Seed | 2 | 8 GB | 100 GB SSD | --full | 30303, 26656 |
| Edge (light) | 1–2 (Pi 4/5 or any x86/ARM) | ≥2 GB (Pi image floors 4) | none (light mode) | n/a — verifies remotely | none (outbound only) |
NVMe is required for any full node (EL)
bera-reth stores state in an MDBX database with heavy random-write/fsync patterns. On SD cards, spinning disk, or slow/oversubscribed network storage, MDBX corrupts or wears out the volume and the EL falls behind or dies. Use local NVMe on baremetal; on AWS use gp3 (or io2 for archive RPC) — never standard/sc1/st1. Edge nodes in light mode hold no state and are exempt.
How the fleet fits together
- Validators form the BFT consensus set and produce blocks. Validator-set sizing is a safety property — a single over-weighted validator can wedge finalization if it goes offline (the "offline-whale halt"). See Validator node → Operate.
- RPC / L5 nodes are the non-validating fleet that serves
eth_getProof(EIP-1186) and JSON-RPC to wallets, dApps, the block explorer, and the edge / light clients that verify reads against it. - Seeds are tiny CometBFT bootnodes that bootstrap peer discovery for everyone.
- Edge nodes are verifying light clients — they hold no state and trust-minimally verify reads against the RPC/CL fleet above. A Raspberry Pi is the turnkey appliance, but the client is plain software that also runs on x86/other ARM hardware, a VM, or a container.
Shared foundations (all roles)
Before any role-specific work, every host needs the same base:
- Prerequisites — Docker Engine + Compose v2, an NVMe volume mounted at
DATA_DIR, NTP time-sync, a host firewall, and the non-root UID. - Quick start — the 10-minute happy path that wraps the steps below.
- Ports & firewall — only
30303/tcp+udpand26656/tcpare public; RPC (8545), engine API (8551), CometBFT RPC (26657), and metrics (9001) stay loopback/VPN-only. - Genesis & the network bundle —
eth-genesis.json+spec.toml+kzg-trusted-setup.json, fetched bybootstrap.sh.
Status — not yet run on real hardware
The patched binaries are determinism-proven (both W4 consensus patches finalized in lockstep with byte-identical state on a 4-validator net; 4→5 validator join and EIP-7002 exit proven live). The AWS/baremetal deploy artifacts here are config-validated but have not yet been run end-to-end on real cloud or baremetal hardware — treat your first deployment as a bring-up. The earlier live proofs ran under Kurtosis, not this raw-compose topology. See Troubleshooting.
Next
Pick your role: Validator · RPC / full node · Seed · Edge node.