Solana Agent Kit: A Plugin-Based Toolkit for Wiring AI Agents to Solana Protocols

The Gap Solana Agent Kit Fills

An AI agent that can reason about a token swap still cannot execute one. Between the model and the chain sit wallet signing, transaction construction, protocol-specific instruction encoding, and RPC submission. Solana Agent Kit exists to absorb that layer. It is a TypeScript toolkit that turns Solana operations into callable tools an agent framework can invoke, so the model emits a structured call and the kit handles the rest. The README frames the audience broadly, from an "SF-based AI researcher" to a "crypto-native builder", and the framing is accurate in one respect: the kit assumes you bring your own agent and your own model. It does not ship a trading strategy, a risk engine, or a decision layer. It ships actions. If your problem is that your agent can describe a token launch but not perform one, this is aimed at you. If your problem is that your agent makes bad decisions, this kit does nothing for that.

Plugins as the Unit of Composition

Version 2 reorganized the project around plugins, and that reorganization is the main structural fact about the current branch. The core package is solana-agent-kit. The actions live in five separate packages: @solana-agent-kit/plugin-token for SPL operations such as transferring, swapping, bridging and what the README calls rug checking; @solana-agent-kit/plugin-nft for Metaplex minting, listing and metadata; @solana-agent-kit/plugin-defi for staking, lending, borrowing and spot or perpetual trading; @solana-agent-kit/plugin-misc for airdrops, price feeds, CoinGecko lookups and domain registration; and @solana-agent-kit/plugin-blinks for Solana Blinks such as arcade games. The README states you can install any subset or all of them. That is a real choice, not a cosmetic one: each plugin pulls in its own protocol dependencies, so a project that only needs token transfers can avoid the DeFi surface entirely. The registration mechanism is a chain of .use() calls on the agent instance, each returning the agent so calls compose. What the README does not document is the plugin interface itself. If you want to wrap a protocol the five plugins do not cover, the README gives you no contract to implement, so you are reading the plugin source. That is the sharpest documentation gap in the material.

The Wallet Interface and the Initialization Path

The agent is constructed with three arguments: a wallet, an RPC URL, and a configuration object holding API keys. In the README example the config object contains OPENAI_API_KEY, which tells you the kit expects provider credentials to be passed at construction rather than read from the environment by default. The wallet argument is the more interesting design point. The README example uses KeypairWallet, built from a base58-decoded secret key, which means the private key is in process memory. The README also states that you can use the wallet interface provided by the Solana wallet adapter for embedded wallets, so the key does not have to live in the process. That second path is the one to take for anything user-facing, and the README does not walk through it. Note also that the example imports Keypair and bs58 without showing those imports, and calls Keypair.fromSecretKey on a value that is never defined. The snippet is illustrative, not runnable. Treat it as a shape, not as code you paste.

From Agent Instance to Framework Tools

The kit does not implement its own agent loop. It adapts to one. After the .use() chain, the README calls createVercelAITools(agent, agent.actions) to produce tools for the Vercel AI SDK. The same import line notes that createLangchainTools serves LangChain and createOpenAITools serves OpenAI agents, so the kit presents the same action set through three adapters. The README's AI integration section also mentions autonomous mode with configurable action intervals and built-in error handling, and interactive chat mode for guided operations, though it does not show the configuration keys for either. The actions themselves are reached through agent.methods. The README example calls agent.methods.deployToken with name, uri, symbol, decimals, an authority options object, and an initial supply, and reads the mint address off the result. A second example calls agent.methods.deployToken2022 with a different argument shape: name, uri, and so on. That the two token deployment methods take differently ordered arguments is worth noticing before you assume the methods share a calling convention.

What the Action Surface Actually Covers

The breadth is the selling point and the README lists it at length: Jupiter swaps, Pump via PumpPortal, Raydium pool creation across CPMM, CLMM and AMMv4, Orca Whirlpool, Manifest markets and limit orders, Meteora AMM, DLMM and Alpha Vault, Openbook market creation, Jito bundles, Pyth price feeds, Adrena perpetuals, Drift vaults and perps, cross-chain bridging through both deBridge DLN and Wormhole, SNS and Alldomains registration, zk compressed airdrops via Light Protocol and Helius, and CoinGecko Pro market data. Read that list as a map of third-party dependencies rather than a feature count. Every one of those names is an external protocol with its own program, its own failure modes, and its own upgrade schedule. When Raydium or Drift changes an interface, the corresponding plugin needs a release. The kit is a coordination layer over other people's contracts, and its reliability is bounded by theirs. This is not a criticism specific to this project, but it is the thing to internalize before you build a system that depends on it.

Where the Kit Is the Wrong Tool

The kit executes. It does not decide. Nothing in the supplied material describes a policy layer, a spending limit, a simulation step before submission, or a confirmation gate on high-value actions. An agent wired to the DeFi plugin has, by default, whatever authority the wallet you passed in has. The README's example wallet is a raw keypair, which means the blast radius of a bad model output equals the balance of that key. The README does mention built-in error handling and recovery, but error handling after a failed submission is not the same as preventing the submission. If your requirement is that no transaction above a threshold can leave without human approval, you are building that yourself, outside the kit. A second case: if you need one specific action, say a single Jupiter swap, pulling in the full plugin and the agent framework around it is more machinery than calling the underlying SDK directly. The kit earns its place when you want many actions behind one tool interface, not when you want one.

Licence, Releases and Upgrade Cost

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you retain the licence and notices, and it includes an express patent grant. That is the permissive end of the spectrum and it is a reasonable fit for a library meant to be embedded in other products. This is a description of the licence text, not legal advice; if you are redistributing or modifying, read the LICENSE file on the v2 branch and get your own counsel. On maintenance: the default branch is v2, the latest release in the supplied list is v2.0.9 from July 2025, and the last push to the repository is dated May 2026, so the project is active rather than archived. The upgrade cost is structural. V2 is a breaking reorganization from V1, and the README points to a separate MIGRATING.md rather than summarizing the changes inline, which tells you the migration is not a version bump you can absorb casually. Because actions are split across five independently versioned plugin packages, your dependency graph has more moving parts than a single-package library, and a plugin release can move without the core moving. Pin your versions.

Alternatives and the Difference in Approach

The closest comparison the material itself invites is Solana Agent Kit V1. The README states V2 is a major upgrade and defers the reasoning to MIGRATING.md, but the visible difference is the plugin split: V1's actions were not partitioned into separately installable packages, so V2 trades a simpler dependency story for a smaller default install. If you are on V1 and your build works, the upgrade buys you modularity and whatever the migration guide lists, at the cost of a dependency reshuffle. Outside the project, the meaningful alternative is not another agent kit but the underlying SDKs. Jupiter, Raydium, Drift and the rest all publish their own TypeScript clients, and the Solana web3.js library handles transactions. Calling those directly gives you exact control over instruction construction and no intermediate abstraction to debug. The difference is who writes the glue. Solana Agent Kit writes it once for 60+ actions and hands you a uniform tool interface; the SDK route makes you write it per protocol but keeps every failure inside code you authored. For a single-protocol agent, the SDK route is usually less to maintain. For an agent that needs to touch six protocols, the kit's uniform surface starts paying for itself.

Editorial conclusion

Adopt Solana Agent Kit if you already have an agent loop in LangChain or the Vercel AI SDK and want Solana actions as callable tools without writing protocol clients yourself. Do not adopt it if you need the kit to make trading decisions for you, or if you expect the README to be a complete runnable program. Verify three things first: that the plugin you need exists for your target protocol, that the method signatures in your installed version match the README, and that the wallet interface you pass in is the one the current release expects.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sendaifun/solana-agent-kit on GitHub