Skip to main content
Current versions of Beacon Kit and Bera-Reth are listed here.

Peering

If you are running in a containerized environment, ensure your services are properly advertising their real network address, and that traffic is being directed into the container, both for Beacon Kit and your execution client. Both the CL and EL should have no static or persistent peers set up, unless they are for your internal network or business partners you want permanent connections to. Review the following sections for specific peering advice for Beacon-Kit and Bera-Reth.

Beacon Kit (beacond)

The diagnosis script inspects beacond only. It does not check Bera-Reth, JWT paths, or EL peering.
Use your Beacon Kit home (the directory with config/ and data/ inside it) and your beacond binary. Attach the full output when asking for support.

Consensus-layer peering


Bera-Reth

Execution-layer peering

The execution layer needs excellent peering so transactions reach your validator for block sealing. Open TCP and UDP on the devp2p port (default 30303).

Reth flags you need

Minimal example — only flags you really should set. Relies on secure and reasonable Bera-Reth defaults (see table below). Set PUBLIC_IPV4 to your node’s external address.
Full example — every flag stated explicitly, useful when you need non-default ports or want a self-documenting unit file. \
If a flag’s default already matches your deployment, omit it. Shorter unit files are easier to audit and less likely to drift from upstream changes:

Reth flags you may not need


Set your validator name and logo on the Hub

Validators should identify themselves so ops can reach you. Send a PR to Validator Metadata, then ping #node-support on Discord so we can let you into dedicated validator support channels.

Operational hygiene

See Monitoring for full Prometheus and Grafana setup.