The four node types on Krypton — and which one to run
Krypton runs a two-container stack per host: beacond (a beacon-kit / CometBFT fork providing instant single-slot finality) paired with bera-reth (a Reth-based EVM execution layer). Every role uses this same docker-compose.yml; what changes is how you configure it. There are exactly four roles to choose from.
At a glance
| Role | Signs blocks | Holds a key | Earns rewards | Minimum hardware | Public ports | Stakes |
|---|---|---|---|---|---|---|
| Validator | Yes | Yes — slashable | Yes | 4 vCPU, 16 GB RAM, 500 GB NVMe | 30303, 26656 | Highest |
| RPC / full node (L5) | No | No | No | 8 vCPU, 32 GB RAM, 1–2 TB NVMe | 30303, 26656 | Medium |
| Seed / bootnode | No | No | No | 2 vCPU, 8 GB RAM, 100 GB SSD | 30303, 26656 | Low |
| Edge node (light client) | No | No | No | 1–2 vCPU (Pi 4/5 or any x86/ARM), ≥ 2 GB RAM, no state disk | None — outbound only | None |
One rule cuts across all full-node roles: NVMe is required for any node that runs the EL. bera-reth uses an MDBX database with heavy random-write and fsync patterns. On an SD card, a spinning disk, or slow network storage, MDBX corrupts the volume. Edge nodes in light mode hold no chain state and are exempt from this requirement.
Validator
A validator signs and proposes blocks. It runs the standard stack with PAYLOAD_BUILDER=true and a CometBFT signing key (priv_validator_key.json). It is the only role that advances the chain and the only role that earns rewards.
Who should run one. Operators who want to participate in consensus directly — infrastructure teams, staking services, or technically capable validators prepared to commit to operational discipline.
Stakes and risk. This is the highest-stakes role on the network. Double-signing (running the same key on two hosts at once) is equivocation, and it is slashable. The risk is not theoretical: it fires whenever an automated failover brings up a second instance without first confirming the first is fully down. Lose the key and you lose the validator identity; leak the key and an attacker can equivocate on your behalf. The production path is threshold signing via Horcrux — a 2-of-3 remote signer so no single host holds the complete key and no two co-signers can produce a double-sign.
Hardware. 4 vCPU, 16 GB RAM, 500 GB NVMe (pruned). On AWS, an m6i.xlarge (4 vCPU / 16 GB) plus a gp3 volume. Equivalent baremetal: a 4-core x86-64 machine with 16 GB RAM and a 500 GB NVMe drive.
Operational requirements. The validator must be 24/7 with a stable public IP. Downtime carries a consensus cost now and a slashing / inactivity cost on mainnet. Never co-locate two validators on one host — it destroys fault independence and wipes out the benefit of physically separate failure domains. RPC (8545) stays on loopback; only P2P ports 30303 and 26656 are public.
Full guide: krypton-docs.foreseer.workers.dev/nodes/validator
RPC / full node (L5)
An RPC node is a non-validating full node. It holds no signing key, sets PAYLOAD_BUILDER=false, and serves eth_getProof (EIP-1186) plus the standard JSON-RPC namespace to wallets, dApps, the block explorer, and edge / light clients. This is the L5 fleet that sits between the validator set and end users.
Who should run one. Teams building on Krypton — wallet providers, dApp teams, block explorer operators, and anyone who wants to give their edge nodes a reliable, self-operated proof source. A non-validating node tolerates restarts and a residential line; you can run one at home behind a WireGuard tunnel.
Stakes and risk. Medium. No key means no slashing risk, but an RPC node that goes down takes dependent services with it. Archive nodes that fall behind re-sync slowly, so avoidable head rollbacks are costly. The 8545 port must never be bound to 0.0.0.0 on a public interface — bind to a VPN/WireGuard address and put a reverse-proxy auth gateway in front of any public-facing endpoint.
Hardware. 8 vCPU, 32 GB RAM, 1–2 TB NVMe. On AWS, m6i.2xlarge plus gp3 (or io2 for archive). Baremetal: 8-core, 32–64 GB RAM, 2 TB NVMe. Archive nodes (full historical state, needed for deep eth_getProof) grow larger than pruned nodes — provision headroom and expect to expand.
Public ports. 30303 and 26656 for P2P. Port 8545 stays on a VPN/WireGuard bind, not on a public interface.
Full guide: krypton-docs.foreseer.workers.dev/nodes/rpc
Seed / bootnode
A seed is a CometBFT bootnode whose only job is peer discovery. It runs the same two-container stack in a pruned, non-validating configuration with tight memory limits. Other nodes dial it at startup to find peers; once they have a peer list, they no longer depend on it for ongoing operation.
Who should run one. Anyone who wants to strengthen the network's peer-discovery layer at minimal cost, or operators who want a low-stakes way to participate. A seed holds no key and tolerates restarts, so a residential internet line or a Pi 5 behind WireGuard is sufficient.
Stakes and risk. Low. There is no key and no consensus weight. The main availability concern is that EXT_IP must be a reachable address — if it isn't, nobody can dial in, and the node serves no purpose. A seed behind a dynamic IP or CGNAT should use a Tailscale or WireGuard address for EXT_IP rather than the residential IP.
Hardware. 2 vCPU, 8 GB RAM, 100 GB SSD. On AWS, t3.large or m6i.large. NVMe or SSD is still required for the EL even at this small scale; MDBX's write patterns will wear or corrupt slower storage.
Public ports. 30303 and 26656 — a seed must expose these to do its job. RPC stays on loopback.
Full guide: krypton-docs.foreseer.workers.dev/nodes/seed
Edge node (verifying light client)
An edge node is a role, not a specific device. It runs krypton-edge-light, a portable Rust binary that holds no chain state and no signing key. Instead of maintaining a local copy of the chain, it points at the RPC / L5 fleet and cryptographically verifies every read before serving it: BLS commit verification against the pinned validator set, SSZ EVM state-root binding, and Merkle-Patricia-Trie proof verification via eth_getProof. A malicious upstream RPC can withhold responses but cannot forge a verified answer.
Who should run one. Anyone who wants trust-minimized chain access without the hardware cost or operational burden of a full node. Home users, developers working from personal machines, and anyone who wants to verify their own reads rather than rely on a third-party RPC.
Hardware. The reference appliance is a Raspberry Pi 4 or 5 (8 GB recommended; first boot refuses boards under 4 GB), shipped as a flashable SD-card image. In light mode the client holds no chain state, so the SSD requirement that applies to full-node roles is dropped. The same binary also runs on x86-64, other ARM single-board computers, a VM, or a container — the Pi path is turnkey packaging, not a hardware requirement.
Stakes and risk. None. No key, no consensus weight, no rewards. Upgrades are a re-flash or a binary replacement; either way the client re-bootstraps from its checkpoint. The only dependency is a reachable, honest RPC / L5 node to verify against.
Ports. No public inbound ports. The client makes outbound calls to the CL and EL RPC fleet and serves verified results on loopback at :8645 (distinct from the full-node :8545). To reach it from another host on your LAN, change KRYPTON_LISTEN to a LAN bind and add a corresponding firewall rule.
One current status note: the light client was validated end-to-end against the devnet, not yet against a live public testnet. A live, reachable 473374 RPC / L5 fleet is a hard prerequisite before an edge node can bootstrap on testnet.
Full guide: krypton-docs.foreseer.workers.dev/nodes/edge
How to choose
Work through these questions in order; stop at the first match.
Do you want to sign blocks and earn rewards? Run a validator — but only if you can commit to 24/7 uptime, a stable public IP, and proper key management (ideally threshold signing). If any of those are out of reach, a different role serves you better.
Do you need to serve JSON-RPC or eth_getProof to other software? Run an RPC / full node. If you are building a wallet, a dApp, or a block explorer, or if you want to supply proofs to your own edge nodes, this is your role. Choose pruned for current-state queries; choose archive if you need full historical proofs.
Do you want to help bootstrap peer discovery on a minimal box? Run a seed. No key, cheap hardware, tolerates residential internet. You can co-locate a seed with a full node on a capable machine to amortize cost — do not co-locate multiple validators.
Do you just want verified read access for yourself, without running a full node? Run an edge node. Flash a Pi, or build the Rust binary for your platform, point it at a reachable RPC fleet, and get cryptographically verified answers on your local loopback port.
If the full-node deploy artifacts carry a caveat — they are config-validated but not yet run end-to-end on real cloud or baremetal hardware — treat your first deployment as a bring-up and verify chain-id, peers, and sync before depending on it. The hardware matrix with AWS instance types, baremetal specs, and cost tiers is at krypton-docs.foreseer.workers.dev/reference/hardware.