The SSV Network DAO is excited to see SSV Labs release the WAD update for the SSV Node. This article was originally posted by the SSV Labs team. The SSV Network DAO will always highlight the community’s helpful contributions.

The Ethereum staking ecosystem is a very competitive space where every fraction of a percentage point in performance matters. With SSV network recently surpassing 4M ETH staked, the importance of optimizing validator performance at scale is ever-growing. The SSV Labs team is consistently researching ways to squeeze out every last drop of performance from Ethereum validators.

We’re excited to expand on a recently introduced feature in the SSV node that does exactly that — Weighted Attestation Data (WAD). In this post, we’ll explain what WAD is, the problem it solves, how it works under the hood, and the real-world performance gains we’ve observed.

Why Validator Performance Matters

In Ethereum’s proof-of-stake consensus, validators earn rewards (or are penalised) based on how well they perform their duties. At a high level, each validator’s attestation must:

• Be included on-chain (participation)
• Vote for the correct chain head and checkpoints (correctness on head, target, and source votes)
• Be included as quickly as possible (minimal inclusion delay)

When validators perform all these duties properly, they maximize their rewards and help keep the network secure and running efficiently. If they miss attestations, vote for the wrong block, or get included too late, they not only lose out on rewards but also contribute less to chain finality and security.

When talking about performance metrics, we like to refer to those set by Rated Network’s RAVER methodology. For example, attestation effectiveness combines a validator’s participation rate, vote correctness, and inclusion delay into a single score. A perfectly performing validator would score near 100%, whereas any missed or incorrect duties drag the score down. Rated’s overall effectiveness further includes block proposals, weighting attestation performance at 5/8 and proposal performance at 3/8 of the total score.

For permissionless node operators maintaining distributed validator setups on SSV Network, nurturing good performance is crucial. Performance acts as an on-chain reputation, as potential TVL may look at it before staking with you. DVT provides the benefits of decentralization and fault tolerance without compromising on validator effectiveness.

There are many challenges when dealing with large-scale staking infrastructure, and most of the time, it’s difficult to pinpoint where the bottleneck is. Over time, it became obvious to us that an inherent problem was the intermittent freshness of the attestation data that was being used to produce an attestation. That’s where WAD comes in…

The Challenge: Attestation Accuracy

Before WAD, an SSV node typically relied on a single beacon node’s attestation data at a time. Since the fallblack support we introduced in v2.2.0, many SSV operators configure multiple Beacon Node endpoints for redundancy — for example, one Prysm and one Lighthouse, or multiple endpoints from different cloud providers — which is a best practice for reliability. However, without WAD, the SSV node wasn’t fully leveraging those multiple sources. Originally, that feature only allowed the node to fall back to the next beacon node in the list if the first one failed to respond.

This means that if your chosen beacon node was slightly behind the chain tip or returned suboptimal attestation data, your validator could unknowingly make a less-than-ideal attestation. Even if a beacon node is just one block behind the latest head, your attestation’s head vote could be outdated. Head vote correctness directly affects your reward — an attestation with a wrong head yields a smaller reward.

Another challenge we identified was attestation inclusion delay. If the SSV node only uses one beacon node to publish attestations, a slow or overloaded node could delay broadcasting, resulting in a later inclusion slot. Ideally, you’d want to use the fastest one or even all of them in parallel. While WAD optimizes the “getting the freshest data” part, it doesn’t solve the “publishing the attestation” part. For that, we have also introduced parallel submissions in v2.3.0. Parallel submissions is a feature that allows the SSV node to publish attestations to all configured beacon nodes concurrently.

In summary, operators were not fully benefiting from multi-beacon-node configurations. For multi-node setups, the infrastructure was there (and possibly underutilized), but the attestation pipeline wasn’t optimized for accuracy or speed.

What is Weighted Attestation Data (WAD)?

WAD is a feature that allows an SSV node to leverage all available Beacon Node endpoints. When enabled, the SSV node concurrently requests attestation data from each configured beacon node. It then scores each response and selects the one with the highest score. In vanilla Ethereum staking, there’s already a similar concept called Vouch, which we have used as inspiration for the scoring logic — we’d like to thank the Attestant team, as it served as a great inspiration.

Scoring Criteria

• Checkpoint correctness: Verifies that the source and target match the latest justified and finalized checkpoints.
• Head block proximity to slot: Evaluates how fresh the head block root is relative to the attestation slot. The most up-to-date one scores highest.

This allows the validator to always vote using the freshest and most accurate view of the chain. While this adds slight latency due to concurrent fetching, the built-in timeouts ensure it doesn’t noticeably slow things down. One slow node won’t hold things up.

Note: WAD requires at least two beacon node endpoints to be effective. Otherwise, it will auto-disable. We recommend using diverse clients (e.g., Lighthouse + Teku) to maximize freshness and redundancy.

Parallel Submissions can be paired with WAD to further optimize inclusion delay by broadcasting attestations via all nodes concurrently.

More Accuracy = More Resources

WAD is a great way to improve attestation accuracy; however, node operators should be mindful that WAD will consume more resources, as now the node will be fetching attestation data from all configured beacon nodes concurrently.

Operators are encouraged to closely monitor their performance to verify that the use of this feature is actually not detrimental to their validator’s performance, as there’s a possibility of overloading your node with too many requests.

Under the Hood: How WAD Works in the SSV Node

Here’s a simplified pseudocode-style breakdown:

1. 1. Concurrent Requests: The node sends a request to all configured Beacon Nodes using goroutines.
2. 2. Collect Responses with Timeouts: Soft and hard timeouts ensure no excessive delay.
3. 3. Score Each Attestation Data:
   • Check source and target epochs.
   • Evaluate the freshness of the head block.
4. 4. Select the Best: Use the data with the highest score.

Differences between responses don’t create conflicts. WAD just reduces the chance of head vote errors by relying on the best-informed node.

Real-World Results: P2P.org Case Study

The SSV Labs team partnered with P2P.org to test WAD; shoutout to Sergey, Artem, and Nick for providing us with the data. Over a two-week period, we compared metrics before, during the switching period, and after enabling WAD.

Performance Improvements

The following charts demonstrate the clear performance improvements achieved with WAD. Each chart shows three distinct phases: before WAD (blue), during the switching period (red), and after WAD implementation (orange).

Attester Effectiveness

Average Inclusion Delay

A decrease in inclusion delay is a good thing, as it means that the attestation is being included in the chain faster, which is a good thing for the validator and the network.

Head Vote Correctness

Head vote correctness shows the most dramatic improvement, with significantly higher and more stable correctness rates after WAD implementation.

Source Vote Correctness

Target Vote Correctness

Conclusion

The results are clear: WAD is a powerful tool for maximising validator performance, especially for those who have been underutilizing their infrastructure. In the highly competitive staking industry, the difference between average and near-perfect performance is only 1–2%, and the most optimized setups send a strong trust signal.

• Here are the full results:

Getting the Most Out of WAD: Adoption and Next Steps

WAD is available in SSV node version 2.3.1 and later. Here’s how to enable it:

1. 1. Update your node to v2.3.1+.
2. 2. Configure multiple Beacon Nodes: Use semicolon-separated HTTP endpoints.
3. 3. Enable WAD via config:

eth2.WithWeightedAttestationData: true

Or set the environment variable:

WITH_WEIGHTED_ATTESTATION_DATA=true

1. 4. (Optional but Recommended) Enable Parallel Submissions via config:

eth2.WithParallelSubmissions: true

Or set the environment variable:

WITH_PARALLEL_SUBMISSIONS=true

Then restart your node after enabling these settings. Monitor your performance with the SSV Explorer or services like Rated Network.

What’s Next

The SSV Labs team invites all operators to try WAD, especially those running multi-node setups. Reach out on the SSV Network Discord with any feedback you may have; the team would love to hear from you!

SSV2.0 | Whitepaper | Twitter | Discord | Youtube | Github