Skip to content
Get started

Developer tool · Review

beaconcha.in: the half of Ethereum Etherscan does not show

Ethereum has been two chains stitched together since the Merge. Most explorers show you one of them, which is fine until you stake — and then the other one is the only one that matters.

Updated 17 September 2026 · How we test · 10 min read
Free tier, key required Open source Self-hostable 1 chain

At a glance

Operator
Bitfly
Launched
2020
Layer
Ethereum consensus
Covers
Validators, attestations, slashings, withdrawals
Open source
Yes
Self-hostable
Yes
API
Free tier with key
Pairs with
Etherscan

The verdict

beaconcha.in is the reference explorer for Ethereum’s consensus layer and there is no serious alternative. Validator performance, attestation effectiveness, proposal history, slashing events and withdrawal tracking are all covered properly. It is open source, self-hostable, and largely useless if you are not staking — which is the correct scope.

What it does well

  • The only thorough view of validator performance, attestations and proposals
  • Withdrawal tracking since Shapella, including partial and full exits
  • Slashing events with the reason, which is otherwise very hard to establish
  • Open source and self-hostable, unusual for a tool of this depth
  • Alerting on validator downtime, genuinely useful if you run one

Where it falls short

  • Of little use unless you stake or study consensus
  • Assumes fluency with consensus-layer vocabulary
  • Free API tier is modest
  • Some views are dense enough to be intimidating

Why it scored what it scored

Six criteria, each out of five, weighted as set out in our methodology. A score without a reason is just a number, so here is the reason for each one.

Coverage 2.0
Ethereum consensus layer only. Narrow by design, and the narrowness is why the depth is what it is.
Data depth 5.0
Attestation effectiveness, proposal history, slashing detail, withdrawal tracking and exit queue position. Complete on its subject.
Speed 4.0
Quick, and the validator dashboards hold up with large sets.
Privacy 3.0
Open source and self-hostable against your own beacon node, which removes the third party entirely if you already run one.
API 4.0
Free tier with a key, adequate for a personal dashboard and tight beyond it.
Interface 4.0
Dense but well organised, and the alerting is the most useful two minutes of configuration a solo staker can spend.

Ethereum is two layers, and explorers mostly show one

Since the Merge in September 2022, Ethereum has had an execution layer, which processes transactions and runs the EVM, and a consensus layer, which decides which blocks are canonical and is secured by staked validators.

Almost every explorer shows you the execution layer, because that is where transactions live. Etherscan will tell you everything about a transaction and nothing about the validator that proposed the block containing it, whether that validator has been attesting reliably, or whether anyone was penalised for anything in that epoch.

beaconcha.in covers the other half. For the roughly one million validators securing the network and the far larger number of people staking through them, that half is the one that determines returns.

Validator performance, and the metric that matters

A validator's job is mostly attesting — voting on what it believes the head of the chain to be, every epoch. Occasionally, roughly once every few months at current validator counts, it is selected to propose a block.

Rewards come mainly from attestations, and specifically from attestation effectiveness: attesting correctly and promptly. An attestation submitted late still counts but earns less. This is the number that separates a well-run validator from a poorly-run one, and it is the number beaconcha.in puts front and centre.

The common causes of poor effectiveness are unglamorous and fixable: a slow or unreliable connection, an overloaded machine, clock drift, or an execution client lagging its consensus client. The explorer will show you the symptom; the cause is on your hardware.

Proposal history matters less statistically but more financially in the moment, since a proposed block carries priority fees and any MEV payment. Missing a proposal because your node was down is the most expensive single failure available to a solo staker.

Slashing, which is rarer than people fear

Slashing is the penalty for provably malicious behaviour — signing two conflicting blocks, or two conflicting attestations. It results in a penalty and forced ejection.

It is worth being clear, because the fear is out of proportion to the risk: slashing is rare, and it is essentially never caused by downtime. Being offline costs you the rewards you would have earned, roughly the amount you would have gained, and nothing more. Slashing requires signing contradictory messages, which in practice almost always means running the same validator keys on two machines at once.

The single most reliable way to get slashed is a badly executed failover — moving a validator to new hardware without ensuring the old one is truly stopped. beaconcha.in records every slashing event with its reason, and reading a few of them is an education in what actually goes wrong.

A useful habit

If you stake, set up the downtime alert. Missed attestations accumulate quietly and a solo validator can be offline for days before anyone notices. The alert is free and it is the highest-value two minutes of configuration available to a staker.

Withdrawals since Shapella

The Shapella upgrade in April 2023 enabled withdrawals from the consensus layer, which changed staking from a one-way commitment into something with an exit.

Two kinds exist. Partial withdrawals sweep the balance above 32 ETH automatically and periodically, with no action required — that is your accumulated rewards arriving. Full withdrawals require exiting the validator, which puts it in a queue whose length depends on how many others are exiting at the same time.

beaconcha.in tracks both, including the exit queue position. For anyone planning to unstake, that queue is the answer to "when", and it is not a fixed number — it lengthens sharply during periods when many validators exit together.

One prerequisite catches people out: withdrawals only work if the validator has withdrawal credentials pointing at an execution-layer address. Validators set up in the early days often used the older BLS credential format and must be updated first. beaconcha.in shows the credential type on the validator page, and checking it before you need it is considerably better than checking it afterwards.

API and self-hosting

A free API tier with a key covers validator status, performance and rewards — enough for a personal dashboard, tight for anything larger. Paid tiers exist.

It is also open source and self-hostable, which is unusual for a tool this specialised. If you run a beacon node already, running the explorer against it is a natural extension and removes the third party from your monitoring entirely.

For a solo staker that combination — your own beacon node, your own explorer, your own alerting — is the setup that depends on nobody. It is more work than a browser bookmark, and it is the difference between monitoring your validator and asking someone else about it.

If this is not the one

Nothing replaces beaconcha.in for consensus data. These cover the execution layer it deliberately ignores.

beaconcha.in: common questions

What is beaconcha.in for?

Ethereum’s consensus layer — validators, attestations, block proposals, slashings and withdrawals. For transactions and contracts you want Etherscan instead.

Will I be slashed if my validator goes offline?

No. Downtime costs you the rewards you would have earned, roughly symmetrically. Slashing requires signing conflicting messages, which almost always means the same keys running on two machines at once.

How long does it take to exit a validator?

It depends on the exit queue, which lengthens when many validators exit together. beaconcha.in shows the current queue and your position in it.

Why have I not received staking rewards?

Partial withdrawals sweep automatically but require withdrawal credentials pointing at an execution-layer address. Validators set up early may still use the older BLS format and need updating first. The credential type is shown on the validator page.

Can I run beaconcha.in myself?

Yes, it is open source. Running it against your own beacon node removes the third party from your validator monitoring entirely.