1. Preconditions and safety model

Large-scale offboarding touches technical, operational and governance concerns at the same time. Before using Validator Tools for exits, we recommend making the following assumptions explicit inside your team.

Phase 1 · Prepare

Define scope, policies and roles. Make sure node health and data are not in doubt.

Phase 2 · Execute

Build, sign and schedule 7002 requests, respecting queues and rate limits.

Phase 3 · Close out

Verify completion, export histories and attach evidence to governance records.

1.1 Clarify what you are exiting and why

Define the scope of the offboarding as a concrete set of validators and accounts, not as a vague goal. Typical triggers include:

a protocol decision to reduce or rebalance a validator set,
a migration from one infrastructure provider to another,
a controlled unwind of a product line or region.

For each group, decide whether you intend to fully exit or perform a partial withdrawal first and exit later. Validator Tools can model both, but the operational risk profile differs.

1.2 Separate roles and access

In many teams one group designs and approves exit campaigns, another operates nodes and transaction infrastructure, and key management may be separate again. The tool is designed to support this split:

the desktop GUI runs on an operator workstation connected to beacon and execution RPC endpoints,
transactions can be built in the app and signed offline if your policy forbids online signing for exit-related keys,
resulting signed payloads are then imported back into the GUI for scheduling and sending.

1.3 Make node health and data quality non-issues first

Exiting at scale is not the right moment to discover storage or networking problems. Before starting:

ensure beacon and execution nodes are fully synced and monitored,
verify you have an accurate mapping of validator index → withdrawal address,
freeze configuration changes that could affect withdrawal credentials during the campaign.

Goal of this section: reduce surprises. The more of this you decide and document up front, the more the rest of the process becomes execution instead of firefighting.

2. Typical failure modes without a structured tool

Operators who exit large fleets via ad-hoc scripts usually run into a similar set of problems:

Uneven offboarding: some subsets of validators finish quickly, others are stuck in the queue for days with no clear explanation.
Opaque transaction behaviour: gas and fee handling are “whatever the script did”, with little visibility into failed or dropped transactions.
No clean history: it is hard to reconstruct after the fact which validators were targeted when, with which parameters.
Weak communication to stakeholders: explaining progress to clients or governance forums becomes a manual status-collection exercise.

Validator Tools is designed to replace this with a single structured workflow that covers planning, execution and evidence.

Step by step

Large-scale exits: from plan to completed offboarding

The sequence below shows how to run a complete exit campaign for a large fleet using the Validator Tools GUI. It assumes you already operate beacon and execution nodes.

Install the desktop application. Download and install the latest version Validator Tools GUI for your operating system (Windows, macOS or Linux), then start the app on an operator workstation with access to your beacon and execution nodes.
Connect and sync your validator inventory. Configure the beacon and execution RPC endpoints in the settings, import validator indices or withdrawal addresses, and verify that balances and labels match your internal records.
Define the exit campaign. In the “Campaigns” view, select the validators you want to offboard, group them logically (by client, pool, customer or region) and specify whether they will perform partial withdrawals first or exit directly.
Generate EIP-7002 requests. Let the app build the corresponding exit and partial-withdraw requests, configure gas and fee limits for the campaign, and export unsigned payloads if you need to sign them offline.
Sign and import transactions. Use your preferred signing environment to sign the 7002 transactions, then import the signed payloads back into the GUI so they can be scheduled and sent.
Configure queue-aware scheduling. Set rate limits (for example, maximum new exits per hour), maintenance windows and pause conditions. The scheduler will then submit transactions while monitoring withdrawal queue conditions.
Monitor progress in the GUI. Track each validator’s state (planned, request sent, included, fully exited) and watch campaign-level progress by group. Pause the scheduler if external conditions change and resume when it is safe.
Export the final state. When the campaign is complete, export CSV/JSON reports from the app showing which validators were exited, when their exits were included, and which parameters were used. Attach these to internal runbooks, client updates or governance threads.

We recommend running this sequence end-to-end on Holesky first with a small test set of validators, using the same settings you intend to apply on mainnet.

4. Operational recommendations and common pitfalls

4.1 Rehearse on a test network

Large-scale exits should be rehearsed. We recommend running a full dry-run of your planned campaign on Holesky:

create a synthetic set of validators that mirrors your production grouping,
run through the same campaign creation, request building, and scheduling steps,
verify that monitoring and exports contain the information your stakeholders expect.

Only after this rehearsal should you reproduce the plan against mainnet, adjusting only parameters that must differ (such as fee limits).

4.2 Keep exit campaigns focused

Avoid mixing unrelated business decisions in one campaign (for example, migrations and risk-driven exits). Keeping campaigns focused makes:

progress easier to interpret,
post-hoc analysis more straightforward,
communication with clients and governance clearer.

4.3 Document your policies alongside the tool

The tool can enforce rate limits and fee caps, but it does not decide what “safe” means for your organisation. We suggest writing down a few simple rules and aligning the GUI with them:

maximum fraction of the fleet allowed to be “in exit” at any time,
conditions that require pausing all campaigns (e.g. incident in the withdrawal mechanism),
who may initiate, modify or cancel an exit campaign, and how approvals work.

Validator Tools then becomes the implementation of that policy, not a substitute for it.

This guide covers only the exit and offboarding side of Validator Tools. The same desktop application also supports credential changes and withdrawal mapping, consolidation (EIP-7251) in the Pectra flow, and reward routing. To start experimenting with all of these flows, you can simply download the app and connect it to a test environment.

Turn large-scale exits into a predictable runbook.