Smithnode
PassAudited by ClawScan on May 10, 2026.
Overview
SmithNode is a disclosed P2P validator skill with shell, network, local key storage, and optional credentials; no artifact-backed malicious behavior was found, but it is only appropriate if you intend to run a long-running blockchain node.
Install only if you intentionally want to run a P2P AI validator. Build from trusted source, avoid curl-piped installers when possible, keep your validator keypair private with restrictive permissions, prefer local-only RPC unless you understand public exposure, and do not provide GitHub or paid AI-provider credentials unless you explicitly need those optional workflows.
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.
Running the skill can start network services, store validator state and keys locally, and execute build/run commands.
The skill openly requires shell, filesystem, and network authority to build and run a validator; this matches the purpose but gives the agent meaningful local and network control.
Runtime Permissions ... Network | P2P gossipsub (port 26656), RPC server (port 26658), outbound AI API calls ... Filesystem | Data directory (`~/.smithnode/`), keypair storage ... Shell | Build from source, run validator process
Run commands only after review, keep RPC bound to localhost unless you intentionally expose it, and use firewall or reverse-proxy protections for public endpoints.
If you choose the contributor workflow, an agent with GitHub credentials could create issues, push branches, open PRs, or modify repositories within the token's scope.
The contributor workflow may use GitHub credentials with repository write authority, but the guide clearly labels this as optional and separate from validator operation.
This guide requires GitHub credentials (tokens or SSH keys) which grant write access to repositories ... Not Required for Validators: Running a SmithNode validator does NOT require any GitHub access
Do not provide GitHub credentials unless you explicitly want contribution actions; use least-privilege tokens, prefer human review for pushes/PRs, and revoke tokens afterward.
Using curl-piped installers runs third-party code on the user's machine.
The guide includes a third-party curl-piped install command; it also warns users and offers a manual install option, so this is a disclosed supply-chain consideration rather than hidden behavior.
curl -fsSL https://ollama.ai/install.sh | sh
Prefer manual installs from official release pages, review scripts before running them, and build from trusted source revisions where possible.
Peer messages and governance proposals can influence validator behavior and be broadcast across the network.
The validator participates in peer-to-peer agent communication and exchanges challenges, votes, and messages with other nodes, which is core to the project but exposes the agent to untrusted network inputs.
Every validator is a full P2P node ... connected via libp2p ... All nodes gossip blocks, challenges, heartbeats, and governance votes directly to each other.
Run the node in an isolated/trusted environment, monitor logs and network exposure, and avoid sending private keys or unrelated sensitive data through P2P messages.
The validator may continue running in the background and be restarted by monitoring scripts, while accessing the local keypair.
The heartbeat guide documents autonomous operation and background restart behavior. This is expected for a validator but creates persistence that users should deliberately approve.
Your SmithNode validator runs autonomously ... If process died: restart it ... nohup ./target/release/smithnode validator ... > ~/.smithnode/validator.log 2>&1 &
Use heartbeat/restart scripts only on machines you control, keep keypair permissions locked down, and document how to stop or disable the service.