nodius.xyz for Solana Agent Kit

Add nodius.xyz launch monitoring, guarded Pump buy/sell workflows and confirmed submission to an existing Solana Agent Kit application. The plugin uses the application's existing wallet interface; private keys remain with that wallet.

This is an independently maintained nodius.xyz plugin, not a SendAI endorsement or framework default. It is tested against the published solana-agent-kit@2.0.10 package.

Install

npm install @nodiusxyz/solana-agent-kit@0.1.1 solana-agent-kit@2.0.10

Download the source, tests and read-only example. The source release includes a dependency lockfile; run npm ci --ignore-scripts, then npm run build and npm test.

Add to an existing agent

import { createNodiusPlugin } from '@nodiusxyz/solana-agent-kit';

// `agent` is your existing SolanaAgentKit instance.
const withNodius = agent.use(createNodiusPlugin({
  apiKey: process.env.NODIUS_API_KEY,
  endpoint: 'https://rpc.nodius.xyz',
  journalDir: './private/nodius-journal',
  allowExecution: false,
}));

const launches = await withNodius.methods.nodiusRecent({ limit: 5 });
console.log(launches);

Expose the registered actions through your existing framework adapter, for example:

import { createLangchainTools } from 'solana-agent-kit';
const tools = createLangchainTools(withNodius, withNodius.actions);

The plugin adds its own namespaced methods/actions. It leaves the agent's existing connection, wallet and other plugins in place. decodeBuilderUnsigned(base64) is exported for consumers that need to normalize older builder responses; current builder responses use the standard versioned-transaction wire format. The recent-launch preview and pricing are public. Authenticated reads and streams consume service credits; create an API key and buy credits using the Quickstart.

Observation and trading

Use bounded launch monitoring first. nodiusRecent({ limit: 5 }) returns at most five recent events; the public preview accepts GET /signals/recent?limit=5, with a maximum of 50. A launch event is an observation, not a token recommendation. The plugin does not copy trades automatically or select a strategy.

Buy/sell requests default to a read-only plan. The host application must enable execution before any charged construction, signing or submission, and each request must opt in with explicit limits. Signing uses the wallet's signTransaction method after the documented transaction-policy checks. It does not delegate automatic broadcasting to the wallet.

The plugin checks known trade, account-rent and fee requirements before requesting a charged buy build. Authenticated account reads used for admission consume RPC credits. A successful builder call is charged before its response; changed account state or a post-build policy rejection cannot undo that charge. Pricing is fetched at runtime from live pricing; estimates are not price locks. Network fees, account rent and program-side charges are distinct from service credits. amountSol is the buy position size; maxSol is the wallet-side SOL policy limit, not a second position-size input. New token accounts require additional rent funding, and current-v2 buys may create both token and wrapped-SOL accounts. The SOL headroom depends on which accounts already exist, token-account size and transaction fees; it is not a fixed multiplier of the position. Keep enough wallet balance for rent and fees, and use the admission details returned by the plugin when setting limits.

Confirmation and recovery

Submission calls sendAndConfirm once from the client with automatic SDK retries disabled. The server may resend the same signed bytes within its bounded confirmation workflow.

Keep the private journal on persistent storage. An unknown result must be reconciled by the original signature; it is not permission to build or submit a new trade. The journal's duplicate protections are local, not a cross-machine exactly-once guarantee.

Policy boundaries

Solana Agent Kit 2.0.10 has upstream dependency advisories, including high-severity findings. Run npm audit in the consuming application and review those dependency paths before enabling wallet signing. Functional qualification does not constitute a full-stack security audit.

The transaction guard checks the documented classic/current-v2 instruction layouts, payer, signer and budget constraints. It is not a complete proof of program state, dynamic recipients, CPI behavior, aggregate spending or profitable execution. Host acknowledgement of the partial policy is required for signing. Use a separate limited-budget bot wallet and review the policy before unattended use.

See the package README for the exact method inputs, execution controls, journal recovery and runnable examples. For standalone command-line workflows, use the trading integration packs.