Vault Performance
A Vault's performance score measures how reliably its validators carry out their on-chain duties: attestations and block proposals. It is not an arbitrary rating. The Beacon Chain rewards and penalizes every validator according to exact protocol rules.
For each validator, the Beacon API ↗ reports two numbers: ideal_rewards (what flawless performance would have earned) and total_rewards (what the validator actually earned, after any penalties). StakeWise reads these values and calculates a single score across all of a Vault's validators over the last 7 days.
Each Vault gets one of four grades depending on the score:
Excellent
Good
Moderate
Bad
Ethereum: [99.61, 100]% · Gnosis: [98.1, 100]%
- No missed blocks, or a very small percentage of them
- Validators attest with near-perfect accuracy
- Less than 0.5% missed attestation rewards
Ethereum: [99.21, 99.61)% · Gnosis: [97.5, 98.1)%
- No missed blocks, or a very small percentage of them
- Validators perform well in attestations
- Less than 1% missed attestation rewards
Ethereum: [97.09, 99.21)% · Gnosis: [96.2, 97.5)%
- The Vault has issues
- Up to 3% missed attestations and/or blocks
Ethereum: [0, 97.09)% · Gnosis: [0, 96.2)%
- Validators are not performing correctly
- Missing blocks or poorly handling attestations
Read on to see what makes up this score and how it is calculated.
Attester Performance — 80%
Attester performance is 80% of the Vault score.
Most of a validator's work is attesting. Once per epoch, the validator publishes a signed attestation that contains three votes1:
- Source vote: a timely vote for the correct source checkpoint.
- Target vote: a timely vote for the correct target checkpoint.
- Head vote: a timely vote for the correct head block.
These votes keep the network in agreement and are a validator's primary source of income. Each vote carries a certain weight toward the reward, and together the three make up 84.4% of total rewards. Missing the source or target vote carries a penalty, while a missed head vote only forgoes its share.
The Beacon API provides ideal_rewards for an epoch — the most a validator could have earned with optimal performance. The attester score compares actual to ideal:
Where:
total_rewards– sum of the Vault's validator rewards, from the Beacon APIideal_rewards– sum of the corresponding ideal rewards
How Attestations Secure Ethereum
New to attestations? Each one is a validator's vote on the state of the chain.
The chain runs in epochs split into slots (32 on Ethereum, 16 on Gnosis), and each validator attests once per epoch. The first slot of an epoch is its checkpoint, a shared reference point the network justifies and finalizes.
An attestation's three votes do two jobs:
- Keep growing — the head vote names the current tip to build on (fork-choice rule LMD-GHOST).
- Lock in history — the source and target votes finalize old blocks (Casper FFG). The source is the latest checkpoint already justified; the target is the one being justified next.
When two-thirds of staked ETH back the same source→target link, the target is justified; once the next checkpoint is justified too, it becomes finalized. Reversing a finalized checkpoint would take a third of all staked ETH being slashed, and that cost is the finality guarantee.
For more, see Ethereum's Gasper overview ↗.
Proposer Performance — 20%
Proposer performance is 20% of the Vault score.
Every so often, a validator is randomly chosen to propose a block. Because the payout — transaction-fee tips and MEV (maximal extractable value: extra value from how transactions are ordered) — swings wildly from block to block, the score ignores how much a block earns and counts only whether an assigned block was proposed. This keeps the metric about reliability, not luck.
Where:
proposed_block_count– Number of blocks the validator successfully proposedmissed_block_count– Number of blocks the validator was assigned but missed
A missed proposal only forgoes its reward; there's no extra penalty. A block also counts as missed if its fees or MEV go to the wrong address, which lowers the Vault's score.
Final Scoring Formula
The overall Vault score combines the two components by weight:
The 80/20 split is StakeWise's own choice, not the protocol's exact reward split. It keeps the metric simple while still reflecting reality: attestations do most of the work and are the steadiest signal of real performance, whereas proposals — and the MEV attached to them — are unpredictable, since a validator can be offline for five minutes and miss its only block of the week.
This is a deliberate simplification of beaconcha.in's BeaconScore ↗, which is reward-weighted across three duties, with each weight set by that duty's share of ideal reward over the window. Long-term, those shares track the protocol's reward budget:
- ~84% attestation duties (54/64)
- ~13% block proposals (8/64)
- ~3% sync committee duties (2/64)
StakeWise uses just two components — attester (80%) and proposer (20%) — and leaves sync committee duty out of the score entirely, so a Vault's grade comes down to the two duties that dominate day to day and are most within an operator's control.
MetaVaults
A MetaVault has no validators of its own — it spreads deposits across several Sub-vaults. Its performance score is the share-weighted average of its Sub-vaults' scores, so each Sub-vault influences the grade in proportion to how much stake sits in it:
Where:
- – the performance score of Sub-vault , computed with the 80/20 formula above
- – Sub-vault 's total shares (its size)
Larger Sub-vaults move the MetaVault's score more than smaller ones. A MetaVault is scored only once all of its Sub-vaults have a score; if any is still unscored, it stays unscored rather than showing a partial average. Nested MetaVaults resolve bottom-up: the innermost are scored first, feeding into their parents.
1. The three votes differ in how quickly they must be included. The source vote must be recorded within 5 slots (its inclusion deadline), and the head vote in the very next slot. Since EIP-7045 ↗, the target vote has no separate inclusion deadline; it counts anywhere within the valid inclusion window, which the EIP extended to the end of the next epoch. ↩