@voightxyz/nosana SDK detects the job from inside the container, correlates it with its on-chain account, and Voight’s public explorer shows the agent as Nosana-Powered, with an entry in the MPL Agent Registry. Verifiable compute in, verifiable agents out.
Auto-detection
One call reads the job id a Nosana node injects into every container. Zero dependencies.
On-chain correlation
The job id IS a Solana account: state, GPU market, node, price, and timings, verifiable by anyone.
Nosana-Powered badge
The agent’s explorer profile carries the badge, linked to the job for independent verification.
How it fits together
Two ways in, same pipeline: agents that embed the SDK report themselves with live telemetry, and the read-only scanner discovers agents straight from public chain + IPFS data, no integration required.Quickstart
nosana.* attributes and the pipeline does the rest: the agent’s profile is stamped at ingest, the badge renders in the public explorer, and the ecosystem stats count it under nosanaPowered.
Detection reference
A Nosana node injects the job id into everycontainer/run operation. Grounded in the nosana-ci/nosana-cli source, not guessed:
detectNosana() validates the id as a base58 pubkey before producing any link: a malformed value still detects (the env var is the signal) but never renders a broken URL.
On-chain correlation
fetchNosanaJob() reads the job account over plain JSON-RPC and decodes it locally, no web3.js, no anchor. What comes back:
Decoding guarantees
Decoding guarantees
- The account owner must be the Nosana Jobs program (
nosJhNRqr2bc9g1nfGDcXXTXvYUmxD4cVwy2pMWhrYM). - The 8-byte Anchor discriminator must match
JobAccount: the program owns several account types (markets, runs), and an owner check alone would decode a market queue into garbage. Anything else is rejected. - The layout is taken from the program source (
nosana-programs→nosana-jobs/src/state.rs), and the decoder is validated against live mainnet accounts, including IPFS CIDs that resolve to the actual job definitions. correlateNosana()never throws on RPC failures: an observability hiccup must never break an agent. Voight can also enrich server-side from the same public account.
What shows up in Voight
- Explorer badge. The agent’s card and profile show Nosana-Powered in Nosana green; the profile badge links straight to the job on Nosana’s dashboard so anyone can verify the GPU workload.
- Ecosystem stats.
GET /v1/statsreportsnosanaPowered, and the agents API accepts anosana=truefilter. - Agentic Registry. Nosana-powered agents get registered in the MPL Agent Registry (Metaplex) with a public
agent_uricarrying the job linkage: on-chain identity pointing at on-chain compute, with the Voight × Nosana card as its image.
Framework identification
Voight recognizes the agent’s framework two ways. Active always wins:
Passive signals recognized today: ElizaOS (
eliza images, --character commands), Mastra (incl. Nosana’s agent-challenge starter), LangGraph/LangChain, CrewAI, Hermes, and custom agents (agent in the image name). Model servers and GPU infra (vLLM, Ollama, ComfyUI, Folding@home) are classified out, and anything ambiguous is skipped: the classifier never lists a random training job as an “agent”. Full signal table and how to make your agent identifiable: frameworks spec.
Proven live on mainnet
The full loop ran on a real Nosana GPU job (July 22, 2026). Every artifact is public and independently verifiable:
What the agent printed from inside the GPU container, verbatim:
Job definitions are public on IPFS: anything you put in a job’s env (like an ingest API key) is world-readable. Use scoped, revocable keys and rotate them after a run.
Links
- npm:
@voightxyz/nosana - Source, probe, and scanner: github.com/Voightxyz/Nosana-SDK
- Nosana: nosana.com · dashboard.nosana.com