Networks & chain IDs

Canonical reference for Krypton's EL/CL chain-id allocation. This is authoritative: every build, genesis, spec, image tag, and Kurtosis config derives from these ids.

Network	Decimal	Hex	Role
Mainnet	47337	0xb8e9	The registered Krypton id, reserved for the value-bearing chain. Gated on external audit.
Testnet	473374	0x7391e	The public / persistent test network — the from-source vehicle going forward.
Devnet	80087	—	Local Kurtosis / ephemeral.

Verify the hex with printf:

printf '%x\n' 47337    # b8e9
printf '%x\n' 473374   # 7391e

Operator sanity-checks use cast chain-id / eth_chainId (which return the numeric EVM chain-id), e.g. 0x7391e on the public testnet.

Mainnet

Chain-id 47337 (0xb8e9). The registered Krypton id, reserved for the value-bearing chain.

• Status: GATED. Mainnet launch is blocked on (1) the external audit of the two consensus-critical reward patches (epoch-mint + fee-router), and (2) a clean testnet soak on 473374.
• Images: CL ghcr.io/foreseerco/krypton-beacond:v1.3.9-47337; EL ghcr.io/foreseerco/krypton-bera-reth:v1.3.3 (chain-agnostic — the EL chain-id comes from genesis, so one EL tag serves both networks).
• When unblocked, mainnet reuses the testnet procedure verbatim — only the CL image tag (-47337) and the genesis chain-id (CHAIN_ID=47337) change. See Building the images and Genesis & the network bundle.

WARNING

This entire docs site targets the testnet (473374). Mainnet is not live and is gated on an external audit — do not point production value at 47337 until that gate clears.

Testnet

Chain-id 473374 (0x7391e). The public / persistent test network — the network these guides target.

• Status: the from-source vehicle going forward. Note the deploy artifacts are config-validated, not yet run on real cloud/baremetal hardware; the live finality / activation proofs ran under Kurtosis. Treat a first real deployment as a bring-up.
• Images: CL ghcr.io/foreseerco/krypton-beacond:v1.3.9-473374 (epoch-mint patched); EL ghcr.io/foreseerco/krypton-bera-reth:v1.3.3 (fee-router patched, chain-agnostic). Pin both by @sha256 digest in production — all operators on the network must pin the same digests.
• Bootstrap asserts the chain-id: bootstrap.sh fails fast if the bundle's eth-genesis.json chainId ≠ 473374.

How the build selects a chain-id

A single env var, KRYPTON_CHAIN_ID (default 47337 = mainnet), threads the chosen id through the image tag, the baked CL spec, the EL+CL genesis, and the Kurtosis vehicle:

./build.sh                            # mainnet (47337), default
KRYPTON_CHAIN_ID=473374 ./build.sh    # public testnet

The beacond image is tagged ${BEACOND_REF}-${KRYPTON_CHAIN_ID}, so mainnet and testnet produce distinct tags (v1.3.9-47337 vs v1.3.9-473374); bera-reth is chain-agnostic and shares one tag. See Building the images.

The chain-spec is one template, sed-derived per network

There is a single chain-spec template (from-source/spec/krypton.spec.toml). It carries deposit-eth1-chain-id = 47337 as the in-file default, but that value is never trusted verbatim on the raw path — both the Dockerfile (bake) and gen-genesis.sh (genesis) sed it to the selected chain-id before use. All the W3 safety params (max-effective-balance, min-activation-balance, validator-set-cap, hysteresis, …) are identical across networks and live only in this one template.

Historical note: the pre-split proofs ran on 47337

The earlier live from-source bring-up proofs — the Kurtosis enclave that finalized thousands of blocks, the 4→5 validator activation, and the EIP-7002 exit — were run on 47337, before the mainnet/testnet split was decided. Those mechanisms are chain-id-identical on any chain-id, so they are not re-run; they remain valid evidence of the from-source pipeline working. Going forward, 47337 is reserved for mainnet and 473374 is the public-testnet vehicle.

See also

• Building the images — the parameterized build + license gate.
• Genesis & the network bundle — what each network ships.
• Troubleshooting — chain-id mismatch and chain-halt recovery.