Running an Ethereum Validator: Slashing Protection, Web3Signer and MEV-Boost

Running an Ethereum validator as an operator comes down to three habits: never let one key sign two conflicting messages, never depend on a client that holds a supermajority and choose your MEV-Boost relays on purpose, with a local block as the fallback. The first habit means slashing protection, one signer per key and, when you sign remotely, one shared database. The second means a minority client on both layers. The third means a relay list you can defend and a minimum bid. All of it applies to a network that has run Fusaka (Fulu) since 3 December 2025.

This is the operator’s checklist, not a guide to staking ETH. If you need the basics of what a validator is, start with what a blockchain validator does. For the general hardware and monitoring picture across networks, see how a validator node works. Here we stay on the Ethereum specifics that decide whether a validator stays online and unslashed. Specs, documentation and dashboards were read on 7 November 2026, and where a source is dated or two sources disagree, the text says so.

The short version

• One key, one signer, one history. Slashing comes from signing conflicting messages, and the usual way to do that is to run the same key in two places.
• Keep the signing history with the key. Every client has a slashing protection database. Move it with the key using the EIP-3076 interchange format, with the client stopped.
• Share one database when you sign remotely. Web3Signer instances that load the same keys must use the same PostgreSQL database, and the database is part of your availability.
• Use doppelganger protection at startup, not as failover. It costs missed attestations on every restart and the documentation says not to build redundancy on it.
• Run minority clients. The client share datasets disagree, so do not trust a single number. Choose a minority client on both the consensus and the execution layer.
• Treat MEV-Boost as a decision. It is optional. Pick relays deliberately, set a minimum bid and keep local block building as the fallback.

What gets a validator slashed

The consensus specs define three slashable offences:

• Two blocks for one slot. A proposer signs two different block headers for the same slot.
• A double vote. A validator signs two different attestations with the same target epoch.
• A surround vote. One attestation has a lower source epoch and a higher target epoch than another, so it surrounds it.

ethereum.org lists the same three. None of them needs malice. All of them are what happens when two copies of a key are live, or when a client forgets what it signed.

The penalties are set in the Electra part of the consensus specs and still apply on Fulu, which does not redefine any slashing function. In order:

1. Initial penalty. The validator loses its effective balance divided by 4,096. That is 0.0078125 ETH at 32 ETH and 0.5 ETH at 2048 ETH, the maximum for a compounding validator.
2. Forced exit. Its exit is started at once (it still waits its turn in the exit queue) and its withdrawable epoch is pushed out by 8,192 epochs, about 36 days. During that time it is flagged as slashed.
3. Correlation penalty. At the midpoint of the window, about day 18, a second penalty applies. It scales with the stake slashed in the preceding 36 days multiplied by three and is capped at the whole balance. If a third of the stake is slashed in one window, the penalty takes the whole balance.
4. Ejection. A validator whose effective balance falls to 16 ETH or below is ejected.

The inactivity leak is a different mechanism. If the chain goes more than 4 epochs without finalizing, validators that do not attest to the correct target accumulate an inactivity score, and their penalty grows with it. It is not slashing, but a client bug that takes your validator offline during a finality problem lands you in it.

How do real slashings happen? The Prysm postmortem for the May 2023 finality losses looked at three slashings near the event and judged them “likely due to operator error while switching clients or attempting a complex unsafe failover”. The pattern is a failover that went wrong, not an attack. Everything below is built around that.

Check finality and the slashing constants yourself

The constants above are chain configuration, so you can read them from any beacon node instead of trusting a blog. This script reads the config, the head and the finality checkpoint from a beacon API and prints the numbers used in this article. It uses Node’s built-in fetch and no packages. Save it as eth-validator-samples.mjs and give it a beacon API URL as the first argument (the default is the public endpoint below).

// Reads finality and the slashing constants from a beacon API. Node 18+, no packages.
const BEACON = process.argv[2] ?? 'https://ethereum-beacon-api.publicnode.com';
const j = async (p) => (await fetch(BEACON + p)).json();

const spec = (await j('/eth/v1/config/spec')).data;
const head = (await j('/eth/v1/beacon/headers/head')).data.header.message;
const fin = (await j('/eth/v1/beacon/states/head/finality_checkpoints')).data.finalized;
const slot = Number(head.slot), epoch = Math.floor(slot / Number(spec.SLOTS_PER_EPOCH));
console.log('head slot', slot, 'epoch', epoch, 'finalized epoch', fin.epoch, 'finality lag (epochs)', epoch - Number(fin.epoch));
console.log('inactivity leak threshold: finality delay >', spec.MIN_EPOCHS_TO_INACTIVITY_PENALTY, 'epochs');

// Electra slash_validator initial penalty = effective_balance // MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA
const q = BigInt(spec.MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA);
for (const eth of [32n, 2048n]) {
  const gwei = eth * 1_000_000_000n;
  console.log(`effective balance ${eth} ETH -> initial slashing penalty ${Number(gwei / q) / 1e9} ETH`);
}
// Withdrawable delay after slashing
const secs = Number(spec.EPOCHS_PER_SLASHINGS_VECTOR) * Number(spec.SLOTS_PER_EPOCH) * Number(spec.SECONDS_PER_SLOT);
console.log('EPOCHS_PER_SLASHINGS_VECTOR', spec.EPOCHS_PER_SLASHINGS_VECTOR, '=', (secs / 86400).toFixed(2), 'days; correlation penalty applied at half:', (secs / 2 / 86400).toFixed(2), 'days');
console.log('proportional multiplier', spec.PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX, '=> if >= 1/3 of stake slashed in window, correlation penalty = full balance');
console.log('ejection balance', Number(spec.EJECTION_BALANCE) / 1e9, 'ETH; max effective balance (0x02)', Number(spec.MAX_EFFECTIVE_BALANCE_ELECTRA) / 1e9, 'ETH');
console.log('gloas fork epoch (ePBS fork) on this network:', spec.GLOAS_FORK_EPOCH, spec.GLOAS_FORK_EPOCH === '18446744073709551615' ? '(FAR_FUTURE, not scheduled)' : '');

We ran it with Node 24 against https://ethereum-beacon-api.publicnode.com, a third-party public endpoint, at 11:51 UTC on 7 November 2026:

head slot 15602357 epoch 487573 finalized epoch 487571 finality lag (epochs) 2
inactivity leak threshold: finality delay > 4 epochs
effective balance 32 ETH -> initial slashing penalty 0.0078125 ETH
effective balance 2048 ETH -> initial slashing penalty 0.5 ETH
EPOCHS_PER_SLASHINGS_VECTOR 8192 = 36.41 days; correlation penalty applied at half: 18.20 days
proportional multiplier 3 => if >= 1/3 of stake slashed in window, correlation penalty = full balance
ejection balance 16 ETH; max effective balance (0x02) 2048 ETH
gloas fork epoch (ePBS fork) on this network: 18446744073709551615 (FAR_FUTURE, not scheduled)

The first line changes every slot, so expect other numbers. The finality lag of 2 epochs is what a healthy chain looks like, and it is the figure to alert on. The spec counts the finality delay from the previous epoch, one less than this lag, so the leak starts at a lag of 6 or more. The last line matters later: on 7 November 2026 the Gloas fork epoch on mainnet was unset, the maximum 64-bit value. As a control, the same script against publicnode’s Sepolia endpoint printed 353024 for that line, so the reading is a real per-network value and not a default.

Slashing protection: local databases and EIP-3076

Every consensus validator client keeps a record of what its keys have signed and refuses anything that conflicts with it. The storage differs by client:

• Lighthouse uses an SQLite database at $datadir/validators/slashing_protection.sqlite, which is locked exclusively while the validator client runs.
• Teku keeps one YAML file per validator in <data-path>/validator/slashprotection/, holding the last signed block slot and the last attestation source and target epochs.
• Prysm keeps a validator.db file in the validator’s wallet directory by default.

EIP-3076, “Slashing Protection Interchange Format”, standardises how that history moves between them. The interchange file is JSON with a metadata block (the format version, currently 5, and the genesis_validators_root) and, for each public key, signed_blocks (slot and an optional signing root) and signed_attestations (source epoch, target epoch and an optional signing root). After an import, a client must refuse any block that is slashable against the imported blocks and any block with a slot at or below the lowest imported one, unless it is a repeat of a signing recorded by its signing root. Attestations follow the same rule for source and target epochs. The EIP also says to take the maximum slot and the maximum source and target epochs per validator when merging files, so a gap in the history never lowers the floor. Prysm’s documentation notes that its export works with Lighthouse, Teku and Nimbus.

The procedure is simple and the order matters:

1. Stop the old validator client. The EIP says to export only when the client or signer is stopped.
2. Export the history from the old client.
3. Import it into the new client while the new client is also stopped.
4. Start the new client only after you have confirmed the old one is stopped for good.

The database cannot protect you from everything. The Lighthouse documentation lists the cases where it is ineffective: two validator client instances running at once (“the slashing protection database cannot protect you in this case”), keys imported without their history and recreating a missing database with --init-slashing-protection. Teku’s documentation says the same about one key used by several nodes. A local database only knows about the process that owns it.

Doppelganger protection

Doppelganger protection covers the gap that a local database cannot: starting a validator client while another copy of the key is already signing somewhere you forgot about. On startup the client stays silent, listens for attestations from its own keys and stops if it hears any. The options differ by client:

• Lighthouse: --enable-doppelganger-protection. The client stays silent for 2 to 3 epochs after a start, and the documentation states that this always costs 2 to 3 missed attestations, also when you add a validator through the HTTP API. It must be connected to a Lighthouse beacon node.
• Teku: --doppelganger-detection-enabled=true, with --beacon-liveness-tracking-enabled=true on the beacon node. Validators stay inactive for at most two epochs and the client exits with code 2 if it detects a doppelganger. Teku’s own pages tag the feature as early access.
• Nimbus: on by default, switched off with --doppelganger-detection=off. It shuts down with exit code 129 if it sees activity.
• Prysm: --enable-doppelganger, off by default and described by Prysm as “not a foolproof method”.
• Lodestar: --doppelgangerProtection.

One epoch is 32 slots of 12 seconds, so 6.4 minutes. Two to three epochs of silence is roughly 13 to 19 minutes of missed attestations at each restart, which is why a planned restart is a different decision from an emergency one. The documentation is blunt on the limit. Lighthouse says it is not safe to run two instances of the same validator even with the feature enabled, and Nimbus says “You should never use it as a mechanism for running redundant setups!” Treat it as a seatbelt for mistakes, not as a failover design.

Remote signing with Web3Signer

Web3Signer is a signing service. Its documentation describes the purpose as letting the clients that need signatures, and the machines that host them, “run at a lower level of trust than the signer”. In eth2 mode (BLS keys, consensus layer) your validator client sends sign requests over a REST API and Web3Signer computes what it signs from the full payload, so a client cannot get a signature over data the signer has not checked. In eth1 mode (secp256k1, execution layer) there is no slashing protection to apply. Signing for both layers needs one instance per mode.

Keys can come from raw files, keystore files, HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager or Azure Key Vault secrets. A caveat is easy to miss: for consensus-layer signing, Web3Signer always loads the private key into memory. In the documentation’s words, a vault protects BLS keys “at rest and in transit”, but you should treat the host running Web3Signer as sensitive wherever the keys are stored. Azure Key Vault keys and AWS KMS keep the private key in the service and support execution-layer signing only.

The slashing protection database

In eth2 mode, slashing protection is on by default and uses PostgreSQL, the only supported database. You create and maintain it, load the schema files from the /migrations/postgresql/ folder in order and set the connection options on start. The database records each block and attestation signed by a validator. Disabling it takes an explicit --slashing-protection-enabled=false. Pruning is off by default, and the documentation says not to prune while you import or export.

What happens with more than one instance is the part operators get wrong. The current Web3Signer documentation says Web3Signer keeps no durable state of its own, so you can replace an instance at any time or run several behind a load balancer. Every instance is active and signs the requests the load balancer sends it. The instances never communicate with each other. The database provides the safety: when two instances load the same keys and get requests for the same validator, the database serializes them, each request is checked against the recorded history, a conflicting request is refused and an identical one is signed again because repeating a signature carries no slashing risk. The rule that follows is short: “Instances that load the same keys must share one slashing protection database.” Separate databases mean separate histories and possible conflicting signatures. Instances that load different keys do not need to share one.

Two failure behaviours belong in your design:

• The database is part of availability. If it is unreachable, block and attestation requests fail instead of being signed unchecked. The documentation does not describe how to make PostgreSQL itself highly available, so that design is yours.
• A key that fails to load is skipped. The instance still starts and looks healthy from the outside. Check /healthcheck, which reports key loading and database status (200 when healthy, 503 when not), and alert on the number of loaded keys.

Clients and hardening

Teku, Lighthouse, Prysm, Nimbus and Lodestar can all use a remote signer. The flags are --validators-external-signer-url and --validators-external-signer-public-keys in Teku, --validators-external-signer-url (alias --remote-signer-url) in Prysm, --web3-signer-url in Nimbus and --externalSigner.url in Lodestar. Lighthouse warns that remote signing is “generally only desirable for enterprise users or users with unique security requirements”.

Lighthouse has one trap to know. Because Web3Signer keeps its own database, Lighthouse’s local one is redundant for those keys, and you can turn it off with --disable-slashing-protection-web3signer. Its documentation says not to use that flag unless you are certain slashing protection is enabled on Web3Signer.

Web3Signer does not limit which loaded keys a client can use: a request that reaches the signing API and names a loaded key gets signed. The documentation’s best practices therefore start with the network. Implement mutual TLS, set --http-host-allowlist, disable or restrict the key manager API and connect to PostgreSQL over TLS. It also notes that Web3Signer does not encrypt keys in storage, a known limitation.

Client diversity

Client diversity is slashing protection at network scale. Finality needs two thirds of the validators. clientdiversity.org puts the consequence plainly: if a client with more than two thirds of the market has a bug and forks to its own chain, “it’ll be capable of finalizing”, and the validators then cannot return to the real chain without being slashed. A client above one third that forks only stops finality, which is a smaller disaster but still an inactivity leak for everyone. ethereum.org makes the same argument and adds that the size of the slashing scales with the number of culpable validators, giving a two-thirds majority as the case slashed maximally. The correlation rule above is why: three times the slashed stake, capped at the whole balance, so a third of the stake is already enough.

Four incidents show how this plays out, all from the clients’ own reports:

• 11 and 12 May 2023, Prysm. Some consensus clients, Prysm among them, struggled with valid attestations that had an old target checkpoint and ran into resource exhaustion. The chain stopped finalizing twice, from epoch 200,551 to 200,555 and from epoch 200,750 to 200,759. About 47 and 149 blocks were missed, an inactivity penalty started once the second event passed 5 epochs without finality, and Prysm v4.0.4 fixed it.
• 6 January 2024, Besu. Besu’s report says an estimated 70% of Besu nodes on mainnet halted, including recent releases, after the Bonsai trie log wrote an incorrect preimage for self-destructed storage. Besu was under the one third threshold, so there was no finality problem for the network.
• 21 January 2024, Nethermind. At 18:06 UTC, Nethermind versions 1.23.0 to 1.25.1 processed a valid block as invalid and every validator on those versions stopped attesting. The postmortem says a fix was deployed within 4 to 5 hours of the first report.
• 4 December 2025, Prysm. About five hours after Fusaka activated, nearly all Prysm nodes hit a resource exhaustion event on certain attestations. Over 42 epochs, 411,439 to 411,480, 248 of 1,344 slots (18.5%) had no block and participation fell as low as 75%. The workaround was --disable-last-epoch-target on v7.0.0, and v7.0.1 and v7.1.0 fixed it. Prysm’s postmortem credits client diversity: a bug client above one third would have cost finality.

No incident above finalized a second chain. The consensus shares are the hard part to pin down. On 7 November 2026 the three consensus datasets on clientdiversity.org disagreed: Miga Labs, which crawls beacon nodes, showed Lighthouse at 48.14%, Rated.Network showed Teku at 53.86% and the Sigma Prime Blockprint dataset showed one client above 99% with its own tooltip reading “accuracy: 0%”. Prysm’s postmortem quotes the same Miga Labs source at more than 56% for Lighthouse on 12 December 2025. On the execution side the page showed Geth at about half (50.13%) in the Ethernodes data it still displays, while the page itself notes that this data has been removed. Its other execution source, supermajority.info, showed Nethermind and Geth at 43% each from self-reported data. Even ethereum.org’s client diversity page, last updated on 23 February 2026, describes a different picture from today’s dashboards. The methodology page says there is “no inherent way to know exactly what client a validator is running”.

So do not plan around one number. Check more than one source, assume any client could be the large one next year and choose a minority client for both layers. A validator that runs a minority consensus client and a minority execution client is the one that survives the next bug in either of the big ones.

MEV-Boost and relay choices

Ethereum has no protocol-level separation between building and proposing yet, so MEV-Boost does it out of protocol. Flashbots describes it as open source middleware that validators run to access a competitive block-building market. Builders prepare full blocks and send them to relays. Relays aggregate them, identify the best bid and hand it to your proposer. The relay is trusted by builders for fair routing and by proposers “for block validity, accuracy, and data availability”.

How much of the network uses it? mevboost.pics showed 90.68% of blocks through MEV-Boost in data stamped 6 November 2026 (the tile does not state its time window), and relayscan’s day totals for that date give 6,524 builder blocks out of 7,200 slots, 90.61%. So the relays you pick are the path for most proposals.

Which relays are active

On 7 November 2026 relayscan listed seven relays active in its 24-hour table: Ultra Sound, Titan, Aestus, bloXroute Regulated, Flashbots, Agnostic and ethgas. Read its percentages carefully. They are shares of payload deliveries, not of blocks: the table adds up to 17,818 deliveries in 24 hours against 7,200 slots a day, because several relays deliver the same block. The top three by deliveries at 11:19 UTC that day were Ultra Sound at 33.44%, Titan at 31.66% and Aestus at 19.28%.

What each relay filters comes from two kinds of evidence, and you should keep them apart:

• Ultra Sound calls itself credibly neutral and permissionless and says it only validates blocks against consensus rules.
• Aestus calls itself a neutral, non-censoring relay.
• Titan documents two endpoints, a global non-filtering one and a regional filtering one. Relayscan shows a single Titan row and does not say which endpoint its share covers.
• bloXroute Regulated and Flashbots are classified as filtering OFAC-sanctioned addresses by third parties: the EthStaker relay list (last updated 22 November 2025) and MEV Watch, whose classification it calls editorial. We found no policy statement on Flashbots’ own relay page.
• Agnostic is listed as not filtering by the EthStaker list and as neutral by MEV Watch.
• ethgas: we found no filtering statement in any source we opened.

MEV Watch counted 12.9% of deliveries on 6 November 2026 through relays it classes as censoring, from 17,346 deliveries. Both the EthStaker list and relay pages age quickly, so check a relay’s own page before you add it. The mev-boost README tells validators to “only connect to trusted relays” and points to relay lists from EthStaker and Lido.

Settings that decide what happens when a relay fails

MEV-Boost is a middleware process between your beacon node and the relays. The settings that matter:

• Relay list. One -relay flag per relay. Fewer relays means less coverage, more relays means more parties to trust.
• Minimum bid. The -min-bid option sets a floor. If no bid delivers at least that value, MEV-Boost returns no bid and the beacon node falls back to local block production. Pick the value deliberately, since the README’s example is only an example.
• Timeouts. The defaults are 950 ms for -request-timeout-getheader and 4000 ms for -request-timeout-getpayload.
• Client fallback. Lighthouse queries the builder and the local execution engine at the same time and, if one fails, uses the other; if both succeed it compares their values and picks one. --builder-boost-factor and --prefer-builder-proposals tune that choice. Prysm’s beacon node tries local building when the builder path fails.
• Circuit breaker. Flashbots’ relay documentation describes clients that stop sourcing external blocks and fall back to local production when the builder network misbehaves.

The risk to plan for is the blinded block. Prysm’s documentation explains that after your validator signs the blinded block, it can no longer propose any block other than the builder’s, “or risk being slashed as the builder holds the validator’s signature”. A relay that fails before it releases the payload leaves you with a missed proposal. The documentation also warns of missed proposals, censored transactions and omitted ones, and says Prysm does not recommend relays.

Running MEV-Boost is optional, and a local block is always available. EIP-7870, the hardware guideline, notes the fallback: a validator may still build a local block if no relay responds or if the bid is below the minimum configured in MEV-Boost.

ePBS and Glamsterdam

Enshrined proposer-builder separation (EIP-7732, ePBS) is the headliner of the Glamsterdam upgrade, which would replace off-protocol middleware and relays with in-protocol mechanics. ethereum.org expects it on mainnet in Q4 2026 and says the date is not yet confirmed. The Sepolia testnet already runs it: its Gloas fork epoch, 353024, passed on 6 October 2026. On 7 November 2026 the mainnet Gloas fork epoch was unset, as the script output above shows. MEV-Boost and relays remain the mainnet path. Client documentation is already preparing: Prysm’s MEV-Boost page is titled “before Gloas” and says builders are configured on the validator client from the fork onward, and Lighthouse has a page on the builder setup after the Gloas fork.

Other operator settings

• Fee recipient. Set it in both the validator client and the beacon node. In Prysm the validator client’s value overrides the beacon node’s, so a stale value on the validator client wins. Per-key overrides go in a proposer settings file.
• Withdrawal credentials. 0x01 validators have an effective balance capped at 32 ETH. 0x02 compounding validators can hold between 32 and 2048 ETH and can be consolidated from several validators. Their partial withdrawals below 2048 ETH have to be triggered manually from the execution layer, which costs gas. The withdrawal address is permanent: it cannot be changed once submitted, so use an address whose keys you control and can recover.
• Exits. You can sign a voluntary exit with your validator key. Since EIP-7002 you can also trigger an exit from the withdrawal address on the execution layer, which needs a transaction and gas but not the signing key. Since Deneb (EIP-7044), pre-signed exit messages no longer expire.
• Automatic sweeps. ethereum.org’s table gives about 7 days to sweep at 800,000 validators, with at most 16 withdrawals per block. Plan around days, not hours.
• Hardware. EIP-7870 is a living, informational guideline. Its attester tier lists 4 TB NVMe, 64 GB of RAM, 8 cores with 16 threads and 50 Mbps down and 25 Mbps up. Other sources give smaller figures (Teku’s system requirements list a 2 TB SSD), so treat any such table as a starting point and cite which one you used.
• Monitoring. Watch missed attestations and proposals, finality lag, sync committee duty (a period is 256 epochs, about 27 hours) and, with Web3Signer, /healthcheck and the number of loaded keys. Teku can also stop itself when it detects that a validator was slashed.

A pre-flight checklist

1. One signer per key: write down where each key is allowed to sign and who can start a second instance.
2. Slashing protection is on, and you know where the database is stored and backed up.
3. Moves use an EIP-3076 export with the old client stopped, and an import before the new one starts.
4. Web3Signer instances that share keys share one PostgreSQL database, and you have decided how it stays available.
5. /healthcheck and loaded key counts are alerted on, not only the process being up.
6. Doppelganger protection is on for restarts, and no failover design relies on it.
7. A minority client runs on each layer, and you checked more than one diversity dataset today.
8. MEV-Boost relays, -min-bid and the local fallback are chosen on purpose, and you read each relay’s own policy.
9. The fee recipient is set in both places and the withdrawal address is one you can recover.
10. Finality lag, missed duties and exit procedure have an owner and a runbook.

---

Sources & References

Specs, documentation and dashboards were opened and beacon chain values read on 7 November 2026.

• Consensus specs, phase0 beacon chain (slashable offences, inactivity leak)
• Consensus specs, Electra beacon chain (slashing penalties, ejection)
• EIP-3076, Slashing Protection Interchange Format
• EIP-7251, Increase the MAX_EFFECTIVE_BALANCE
• EIP-7002, Execution layer triggerable withdrawals
• EIP-7732, Enshrined Proposer-Builder Separation
• EIP-7870, Hardware and Bandwidth Recommendations
• ethereum.org, Rewards and penalties (slashing section only)
• ethereum.org, Client diversity
• ethereum.org, Withdrawals
• ethereum.org, Network upgrades
• ethereum.org, Glamsterdam
• Web3Signer docs, Architecture
• Web3Signer docs, Slashing protection
• Web3Signer docs, Configure slashing protection
• Web3Signer docs, Store keys
• Web3Signer docs, Key best practices
• Lighthouse book, Slashing protection
• Lighthouse book, Doppelganger protection
• Lighthouse book, Remote signing with Web3Signer
• Lighthouse book, Builders and Gloas builder configuration
• Teku docs, Slashing protection
• Teku docs, Detect doppelgangers
• Teku docs, Use Web3Signer
• Teku docs, System requirements
• Prysm docs, Slashing protection
• Prysm docs, Web3Signer
• Prysm docs, MEV-Boost
• Prysm docs, Fee recipient
• Prysm docs, Parameters
• Prysm docs, Mainnet postmortems (May 2023 and December 2025 incidents)
• Nimbus guide, Doppelganger detection and Web3Signer
• Lodestar docs, External signer and Validator CLI
• Besu, Incident Report 2024-01-06 Mainnet Halting Event
• Nethermind, postmortem of the 21 January 2024 invalid block bug
• clientdiversity.org and its methodology
• Flashbots docs, MEV-Boost introduction and relays
• mev-boost README
• relayscan (24-hour table) and its day totals for 6 November 2026
• mevboost.pics
• MEV Watch
• EthStaker MEV relay list
• Relay pages: Ultra Sound, Aestus, Titan docs
• Beacon API reads on 7 November 2026 from https://ethereum-beacon-api.publicnode.com (/eth/v1/config/spec, /eth/v1/beacon/headers/head, /eth/v1/beacon/states/head/finality_checkpoints) and, as a control, https://ethereum-sepolia-beacon-api.publicnode.com

---

Work with Matrixed.Link

Matrixed.Link operates Chainlink oracle infrastructure, validator nodes and full-stack blockchain infrastructure for protocols and institutions that need institutional-grade reliability. Official Chainlink node operator running Data Feeds, CRE, SVR and Proof of Reserve. Matrixed.Link works under the ISO/IEC 27001:2022 certificate of its parent company MatrixedLabs. AAA-rated provider on StakingRewards.

Contact Matrixed.Link to discuss validator and staking infrastructure for your protocol.