These docs are the public adoption layer. They describe package install, scaffold setup, protocol verification, registry trust, and auditor checks without exposing private operator internals.
Bot quickstart
Install the SDK with npm install @svsprotocol/solana.
Scaffold a new agent with npm create svs-agent my-agent.
For Python bots, install svs-solana with python3 -m pip install svs-solana.
Run preflight, doctor, and certified submit through the generated project.
Ask the operator for the current handoff, registry profile, and production proof status.
Protocol gate
Protocols should accept an action only when official identity binding passes, the exact action proof shows signed bot request, human approval, broadcast, custom registry write, and action-record verification, and a deliberate mismatch is rejected for the correct action-binding reason.
The Solana Agent Registry establishes the agent asset and operational wallet. All four public SVS demo agents now have live official devnet assets. SVS pins the network, official program, asset, and wallet, requires the wallet to match the controller in the exact action proof, and can publish hash-pinned SVS validation evidence back through registry feedback.
Agent Skill
Agent runtimes can install the public SVS action-authorization skill directly. The skill teaches the fail-closed readiness, submit, and independent-proof checks without exposing operator internals or secret material.
The public standard gives the market common language for verified Solana agents. A valid SVS proof requires current approval-domain evidence, request signing, nonce protection, policy outcome, human wallet approval, on-chain registry proof, and portable auditor evidence.
An auditor imports a signed verification set, then independently checks signer trust, release readiness, action-record proof, receipt registry submission, browser export evidence, and cache-busted verifier evidence.
Security posture
SVS treats copied badges, stale proofs, unsigned bot requests, replayed nonces, missing registry anchors, and mismatched approval domains as failure states. Public docs show these warnings before a bot, protocol, or auditor treats a proof as acceptable.
SVS is seeking independent review and does not currently claim a completed third-party audit. The public review packet defines the exact claims, non-claims, reproducible checks, private-source scope, and disclosure route.
Bot teams can request a pilot, partner, or production registry review after they can show public agent identity, signed request proof, human approval, registry evidence, fee policy, credential lifecycle, host validation, and a revocation contact.
The public layer is packages, docs, registry pages, verifier demos, and protocol examples. The private operator dashboard, admin controls, release tooling, evidence directories, and secret material stay private.
Framework maintainers
SVS keeps upstream contributions deliberately small: one verified-action example with public dependencies, placeholder env values, copied-file hashes, and a local validator. Solana Agent Kit, GOAT, and Vercel AI SDK examples are open for maintainer review; ElizaOS is now an SVS-owned third-party plugin path after maintainer fit feedback.
Real-agent listings are reviewed before they appear next to demo profiles. Send the public agent name, website or repository, maintainer contact, target network, requested status label, safe controller identity, current proof status, host-framework validation signal, and revocation contact. Do not send secrets or raw private dashboard evidence.