1. How the documentation is organised
Validator Tools documentation is structured around the same flows you see in the desktop app: exits, consolidations, MEV policy, migrations, safety and observability. Each guide is written as a runbook first – practical steps, assumptions and failure modes.
Most operators dip into the docs in two situations:
- when planning a one-off or rare operation (large exits, migration, re-keying),
- when they need a clear runbook for team members to follow without improvisation.
2. Core flows & overview
These pages map directly to the primary flows in the application and are the best place to understand how Validator Tools fits into your validator operations.
2.1 Large-scale exits & offboarding
How to plan and run exit and partial-withdraw flows over many validators with queue-aware scheduling and audit trails.
2.2 Pectra operations & combo runs
Combining 7002 exits, partial withdrawals and 7251 consolidations into structured runs, with rehearsal on Holesky before mainnet.
2.3 Provider migration & consolidations
Moving validators between hosting providers or clusters while keeping slashing protection and monitoring intact, and planning consolidations around MaxEB.
3. Safety, keys & slashing protection
Slashing risk on Ethereum is overwhelmingly an operational issue. The safety-oriented docs describe how to keep keys unique, avoid dangerous migration patterns and design redundancy without double-signing.
3.1 Key management & slashing protection
How to treat validator keys, withdrawal credentials and slashing protection databases as one coherent system – and how Validator Tools helps track it.
3.2 Redundancy, uptime & failure domains
Designing validator clusters, failover paths and maintenance windows so that redundancy improves safety instead of quietly introducing double-signing risk.
3.3 Withdrawal credentials & onboarding
Managing BLS→Execution (0x00→0x01) changes, onboarding new validators, and keeping withdrawal keys and payout targets auditable.
4. MEV policy, builder routing & operations
MEV-Boost and builder selection are now core operational decisions for many validators. The MEV docs cover how Validator Tools models and executes MEV policy while keeping runs documented.
4.1 MEV / MEV-Boost operations
Connecting to relays, shaping builder policy, handling fallback paths and integrating MEV decision-making into your broader validator operations.
4.2 Team operations & DVT / BYOV
Patterns for multi-operator setups, DVT stacks and bring-your-own-validator arrangements, including how to expose enough state to teams without over-exposing keys.
5. Monitoring, scaling & troubleshooting
Beyond individual runs, Validator Tools is meant to sit inside a wider observability and capacity planning setup. These docs describe how.
5.1 Monitoring & alerting at scale
Integrating Validator Tools with your monitoring stack, interpreting its health views and building alerts that surface real issues instead of noise.
5.2 Resource scaling & capacity planning
Understanding how validator count, MEV policy and exit / consolidation runs translate into CPU, memory, disk and network requirements over time.
5.3 Rewards, taxes & reporting
Using withdrawal scans, export formats and run history from Validator Tools to feed internal reporting, accounting and tax workflows.
5.4 Operational reliability & troubleshooting
A collection of shorter runbooks for common failure modes: beacon/API issues, stuck runs, inconsistent state between Beacon and execution nodes, or intermittent signer problems.
6. Getting started and keeping up to date
The docs evolve alongside the client and the protocol – especially around Pectra, 7002/7251 behaviour and MEV best practices.
6.1 First install checklist
If you are deploying Validator Tools into an existing validator stack, a good first-time pattern is:
- Install the app on an operator workstation or management host.
- Connect it to a small subset of validators and a non-critical environment.
- Run through one exit or consolidation rehearsal on Holesky.
- Review the run history and export to ensure it matches your expectations.
6.2 Where to look for changes
Release-specific notes and migration considerations live alongside the core docs referenced above. When a release changes how a critical flow behaves (exits, consolidations, MEV policy), the associated runbooks are updated in lockstep.