Slv Validator
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is mostly aligned with Solana validator management, but it can drive privileged Ansible operations from external SLV template playbooks that were not included in the reviewed artifacts.
Install only if you trust the SLV toolchain and can verify the exact ~/.slv/template playbooks that will run. Inspect the templates, pin or record the version, use Ansible --check first, confirm every mutating action, and keep SSH and validator private keys out of agent-visible messages and logs.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The agent may run unreviewed local SLV templates that can change remote validator servers, identities, services, firewall rules, or ledger data.
The skill tells the agent to execute runtime Ansible playbooks from an external local template directory, while the reviewed manifest does not include those playbooks. Because those playbooks perform high-impact server administration, their provenance and contents matter.
All playbooks are stored in `~/.slv/template/{version}/ansible/` ... Do NOT use the skill's own `ansible/` directory for execution.Before use, verify how ~/.slv/template is installed, inspect or pin the exact template version, and run Ansible in --check mode before applying changes.
Mistaken or premature use could interrupt validator service, remove local ledger/snapshot data, or change active validator identity.
The documented command set includes broad operational actions that can start, stop, restart, clean up, and migrate validators. These are expected for the purpose, but they are high-impact administrative operations.
`slv v deploy` ... Full node initialization ... `slv v stop` ... `slv v restart` ... `slv v cleanup` ... Remove ledger/snapshot files ... `slv v switch` ... Zero-downtime identity migration
Require explicit user confirmation for every mutating action, confirm the target inventory and network, and prefer dry-runs before applying playbooks.
Anyone misusing the SSH key or validator key material could administer the server or affect validator identity operations.
The skill uses SSH credentials and validator identity/vote account information. This is necessary for validator deployment, and the artifacts also instruct not to expose private keys, but the access is sensitive.
`ssh_key_path` — Path to SSH private key (default: `~/.ssh/id_rsa`) ... `identity_account` — Validator identity pubkey ... `vote_account` — Vote account pubkey
Use least-privilege SSH keys, avoid sharing private key contents with the agent, keep validator private keys out of logs, and review any key-copy or identity-change playbook before running it.
Running the setup script can install or update packages on the user's machine.
The setup script can install local packages and may use sudo through the system package manager. This is a normal prerequisite flow for Ansible-based deployment, but it changes the local environment.
pip3 install --user ansible-core ... brew install ansible ... sudo apt-get update && sudo apt-get install -y ansible-core
Read the setup script before running it, execute it manually rather than automatically, and use a controlled environment if possible.
A wrong target, wrong network, or mistimed operation could cause validator downtime or require manual recovery.
The artifacts correctly acknowledge that stop, restart, cleanup, and identity-change operations are destructive or operationally sensitive. These actions are purpose-aligned but can have cascading effects on validator availability.
Confirm before destructive actions: Always confirm before stop, restart, ledger cleanup, or identity changes
Back up important state, verify inventory and validator identity, schedule maintenance windows, and do not let the agent run these operations without an explicit confirmation step.