1. Why DVT, BYOV and team operations are a different kind of problem
In a single-operator setup, exits, updates and other operations are often driven by one person and one set of scripts. In a DVT or BYOV environment, the reality is more complex:
- several operators collectively control a validator or cluster,
- operations must respect shared governance or multisig policies,
- runbooks have to be clear enough for different teams to follow consistently.
Communities around Lido BYOV, Obol and others keep returning to the same question: how do we standardise exit and operations tooling for distributed setups, rather than each cluster reinventing its own scripts?
1.1 More stakeholders, same chain-level actions
Whether you are using DVT or a more traditional multi-operator arrangement, the chain still sees the same operations:
- exits and withdrawals (7002),
- consolidations and MaxEB changes (7251),
- credential changes, top-ups and reward routing.
The difference is that decisions and responsibilities are now split across teams, not centralised.
1.2 Scripts don’t scale well across organisations
Custom scripts and one-off tools are fine for one operator. Across several independent teams they become:
- hard to audit (“what does this script actually do?”),
- hard to coordinate (“are we all using the same version?”),
- hard to document for new operators joining a cluster.
This is exactly why larger protocols discuss the need for standardised operational tooling that can be adopted by different providers.
1.3 Team workflows need visibility and approvals
DVT/BYOV teams often need:
- clear roles (who can propose operations vs who can execute them),
- approval steps (e.g. multiple sign-offs or multisig confirmation),
- a shared view of state so everyone sees the same plan and progress.
A CLI-only world is not optimised for that kind of collaboration.
2. What DVT/BYOV teams actually need from an ops tool
When cluster operators and protocol teams discuss “standard exit tooling for DVT”, the requirements usually converge on:
- shared plans and runbooks – everyone operates from the same description of what will be done.
- role-based access – some team members propose operations, others execute, others only observe.
- traceable actions – who proposed an exit, who signed it, who actually sent it on-chain.
Validator Tools is designed to serve as that shared control plane – with the underlying 7002/7251/7702/6110 mechanics handled by the app, and the workflow clearly visible in the GUI.
The sequence below outlines how a cluster or team can adopt Validator Tools as a standard operations console for exits and day-to-day tasks across multiple operators.
- Install the desktop application. Each participating operator installs the latest version Validator Tools GUI for their operating system (Windows, macOS or Linux) on a workstation that has network access to the relevant beacon and execution endpoints (or to a shared RPC layer).
- Connect to a shared view of the validator set. Configure consistent beacon and execution RPC endpoints across the team where possible, so that Validator Tools shows the same inventory of validators and clusters to each operator. Label validators by cluster, client, provider and any DVT group identifiers you use.
- Define team roles and permissions. Inside the app, agree which operators will: propose operations (e.g. exits, consolidations, credential changes), review and approve proposals, and actually execute transactions. Use role-based access controls and, where relevant, dedicated session keys to enforce these roles.
- Create shared plans for cluster-level operations. For a DVT cluster or BYOV group, create a plan in the GUI that describes: which validators are in scope, what operations are intended (exit, consolidate, change credentials), and any constraints (time windows, queue limits). Make this plan visible to all operators.
- Attach approvals and, if needed, multisig workflows. If your process requires approvals or multisig (e.g. Safe), configure the plan so that: it can only move from “proposed” to “ready to execute” after a defined number of reviewers have signed off, and if using multisig, map the prepared transactions to the appropriate Safe flows.
- Execute operations from within the shared console. Once approved, the designated operators use Validator Tools to build, sign (or export for signing) and submit the corresponding on-chain transactions – exits, consolidations, credential changes – with the rest of the team able to observe progress live.
- Monitor and log outcomes as a team. Use the app’s history and status views to: track which operations completed and when, record which operator or key performed each action, and export logs that can be attached to incident reports or governance threads.
- Review and refine the shared runbook. After each major operation (e.g. cluster exit, migration, key rotation), review: what worked smoothly, where approvals or communication were unclear, and adjust your plans and roles in the GUI accordingly so the next run is cleaner.
4. How Validator Tools supports DVT/BYOV team workflows
4.1 Shared inventory and cluster labelling
Validator Tools lets you build a shared inventory of validators that includes:
- which validators belong to which DVT cluster or BYOV arrangement,
- which providers or teams are responsible for each group,
- which labels map to protocol-level concepts (e.g. “Lido BYOV set”, “Obol cluster A”).
Every operator looking at the GUI sees the same structure, which reduces confusion when coordinating work.
4.2 Plans instead of ad-hoc commands
Instead of running commands directly, teams define plans in the GUI:
- exit plans for specific clusters or groups,
- credential rotation plans,
- consolidation or migration plans that affect several operators at once.
Plans can be discussed, reviewed and approved before any on-chain operation is executed, making them much easier to audit and reason about than a set of shell commands.
4.3 Roles, approvals and session keys
With multiple teams involved, not everyone should have the same level of control. Validator Tools:
- supports role-based access so some users can only view or propose, not execute,
- integrates with session keys so that execution privileges can be narrowed and time-limited,
- tracks which user and which key executed each operation for later review.
This fits well with DVT/BYOV norms where operators often have their own internal controls and approvals.
4.4 Audit-friendly history across operators
Team-based setups benefit from a clear record of what happened. The history view in Validator Tools keeps:
- a timeline of proposed, approved and executed operations,
- per-plan and per-cluster summaries of actions,
- exportable logs that can be attached to protocol governance, risk reviews or incident analyses.
This history is especially valuable when clusters span multiple organisations and jurisdictions.
5. Practical recommendations for DVT/BYOV teams
5.1 Agree on a common toolset early
When multiple providers share responsibility for a cluster, agreeing early on a standard operations tool (and not just a set of scripts) avoids divergence later. Validator Tools can act as that standard, while still allowing each team to keep their own internal monitoring and automation.
5.2 Make roles explicit and visible
Document and configure who is allowed to propose, approve and execute operations. Use the GUI to reflect those roles so that everyone can see the governance model, not just read about it in a separate document.
5.3 Use test clusters to refine your runbooks
Before you run complex operations on production DVT/BYOV clusters, use test clusters or non-critical validators to:
- exercise your approval flows,
- verify that all operators can see and follow the same plan,
- identify any gaps in documentation or clarity.
Once the runbook works in test, you can apply it to production with more confidence.