Validator responsibilities
A validator owns execution state, consensus safety state, authenticated peer traffic and access to an external signer. An observer follows certified state without voting.
Keys and durable safety
Never share a safety backend between concurrent writers or reuse one voting identity in independently running validators. The node fails closed after ambiguous safety/execution writes; recovery must preserve the authorized vote history.
The devnet signer stores BLS keys in private files and signs validator requests. It is a development signer, not production slashing-protected custody. It holds no production DKG share setup.
Peer identity and membership
Mutual TLS authenticates transport peers by configured credentials/names. Votes additionally require current committee membership and valid proposal/context-bound evidence. Replacing a trusted peer endpoint does not change voting authority.
Per-peer budgets bound overload. One noisy peer should consume its own admission allowance rather than expanding its authority. Clock timeouts cannot substitute for authenticated new-view quorums.
Clocks
Keep validator clocks synchronized with NTP. A proposer whose clock runs more than 15 seconds ahead stalls its own rounds. A clock that steps backwards below a slot the validator already signed raises a clock-health fault: the validator stops signing proposals, votes and reports until the clock catches up. This fails closed, so watch for it rather than restarting around it.
Observer RPC
Observers follow committed finality and can serve reads. Observer role alone does not guarantee submission is enabled: startup policy can make RPC read-only, and gateway clients have method allowlists. The local devnet observer permits Ethereum submission by default. Observers never join consensus rounds.
Monitor
Watch committed height, peer reachability, signer response timing, clock health, store health, disk headroom and bounded queues. Development defaults need measured multi-host calibration before production use.