Validator Tools downloads.

A run records what you’re trying to do and the evidence for it: selected validators, parameters, preflight checks, and the exact artifacts produced for approvals/signing/execution. It’s designed to replace “one-off commands + memory” with a repeatable, reviewable record.

• Inputs: network, validator set, limits, routing/policy choices.
• Checks: chain state, conflicts, eligibility, queue visibility, sanity rules.
• Outputs: unsigned payloads + a human-readable summary for reviewers.

Core workflows should run fully offline: build runs, validate inputs, generate exports, and keep history locally. Network access happens only when you explicitly query endpoints for live state.

• No hidden dependencies: the app shouldn’t require login to function.
• Telemetry: if ever present, it must be opt-in with a hard off switch.
• Airgap path: export run bundles to move prep → offline signing safely.

The safest default is local storage for templates, run history, and exports. That’s good for privacy — and it also makes backups straightforward: copy the data directory or export portable run bundles.

• Backups: snapshot the data directory (or export specific runs).
• Handoffs: move runs between machines without losing context.
• Audit: keep summaries + artifacts together for later review.

Idle usage should be light. Spikes happen only during explicit operations: scanning large validator sets, building batches, or fetching state from endpoints. Long tasks should show progress and support safe cancellation.

• CPU/RAM: dominated by scans and summaries, not background churn.
• Disk: run history + exports + bounded caches (configurable).
• Predictable: no surprise background jobs; you trigger the work.

A clean deployment is “ops box → beacon/EL endpoints”. Validators can run on servers or cloud, while the UI runs on a workstation. Signing can remain offline or in HSM/Safe, depending on your process.

• Separation: prep/review on ops machine, signing on trusted signer.
• Least privilege: prefer read-only endpoints where possible.
• Portability: run bundles move across machines without rewriting playbooks.

The intended model is endpoint-based: connect to beacon/EL APIs you provide. No shell access, no client restarts, and no “silent writes” to infra. Destructive actions should be gated behind export → sign → execute.

• Default posture: read state, prepare artifacts, don’t mutate infra.
• Explicit writes: only where your workflow demands it (and you approve it).
• Clear scope: show exactly which endpoints are used for each run.

If you use hosted beacon/EL providers, the app should support tokens/basic auth/custom headers and handle throttling predictably. The key is keeping credentials local and making access explicit.

• Throttling: bounded retries + backoff, with clear errors.
• Rotation: quick token updates without breaking other envs.
• Safety: never embed secrets into exported artifacts by default.

Operators usually have multiple contexts (mainnet/testnet, regions, clusters, customers). The safe pattern is separate profiles: each with its own endpoints, limits, and run history — to avoid cross-environment mistakes.

• Profiles: mainnet/testnet separation with obvious labels.
• Guardrails: show network + profile at the top of every run summary.
• Exports: include env identifiers in filenames/manifests.

Validator Tools should not require validator private keys, seed phrases, or keystore files for normal operation. It prepares unsigned artifacts and clear summaries so your existing signer flow stays in control.

• Signer separation: hardware wallet, offline box, HSM, Safe — your choice.
• Sensitive steps: if any exist, they must be explicit and opt-in.
• No surprises: avoid hidden “helpful automation” around keys.

A good ops flow is staged: prepare → review → sign → execute. Validator Tools should export artifacts that are easy to verify and safe to pass through your approval chain without copy/paste risk.

• Offline signing: export to removable media and sign on an airgapped machine.
• Team approvals: reviewers validate summaries/diffs before signatures.
• Safe/HSM: keep governance and custody tooling unchanged.

Most “operator incidents” are selection and process failures: wrong validators, wrong chain, duplicated actions, or assumptions not shared with reviewers. Runs help by forcing clarity and making reviews consistent.

• Selection visibility: show exactly which validators are affected (and why).
• Preflight checks: detect conflicts/incompatibilities before exporting anything.
• Previews: reviewers approve intent, not reconstructed shell history.

If you use tokens for RPC providers, they should be stored locally and never included in exports by default. A practical UI also supports “operator hygiene”: lock the app, redact sensitive fields, and keep logs clean.

• Local only: secrets never leave the machine unless you export them intentionally.
• Redaction: avoid leaking tokens into screenshots/logs where possible.
• Lock: optional app lock / inactivity lock for shared ops environments.

Exits should be boring: deterministic parameters, explicit ordering, and a readable preview before signing. A GUI removes ad-hoc JSON-RPC juggling and makes it easier for teams to review the same thing every time.

• Batches: group validators, apply limits, generate one coherent run.
• Queue-awareness: show estimated timing windows based on current conditions.
• Artifacts: exports designed for approvals/signers, not copy/paste.

Operators typically need: (1) confirm withdrawal credentials/destinations, (2) plan changes safely where applicable, and (3) output reports for finance/accounting and monitoring.

• Scanning: summarize current credentials and expected destinations.
• Routing: export lists/manifests for payout tooling and reconciliations.
• Consistency: keep outputs stable so dashboards don’t break.

Consolidations (MaxEB/EIP-7251) are high-stakes because they change validator structure. The tool should make source→target intent obvious, apply constraints, and produce artifacts that reviewers can validate quickly.

• Planning: clear mapping, expected outcomes, and “what changes” summaries.
• Controls: limits/order/maintenance windows to keep execution predictable.
• Exports: human-readable manifests plus machine-readable payloads.

Treat the app like any ops binary: verify installers (hashes/signatures) and verify exports (manifest + hash) before signing/execution. The goal is a boring, repeatable checklist.

• Downloads: checksums/signatures from a stable release page.
• Exports: include network, validator set, timestamps, parameters — then hash it.
• Process: generate → preview → verify → sign → execute.