# solana-go: Go SDK and RPC client for Solana applications > solana-go is a Go library for interacting with Solana JSON RPC and WebSocket endpoints. It covers RPC and streaming clients, transactions, built-in program helpers, encoding, and selected Solana Program Library clients, with compatibility and safety trade-offs that adopters should assess. **solana-foundation/solana-go** — Go SDK library and RPC client for the Solana Blockchain - Repository: https://github.com/solana-foundation/solana-go - Stars: 1,588 · Forks: 441 - Language: Go - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/solana-foundation-solana-go ## What solana-go covers for Go services solana-go addresses the problem of building Go software that talks directly to Solana without implementing JSON RPC serialization, transaction structures, account handling, and WebSocket subscriptions from scratch. Its intended users are Go developers working with blockchain data, sending transactions, decoding instructions, or integrating selected Solana programs. The repository describes the project as a Go library for Solana JSON RPC and WebSocket interfaces. The feature list is broad but uneven. The project marks the full JSON RPC API and full WebSocket JSON streaming API as available. It also provides clients for the system program, BPF Loader, compute budget, SPL token, and associated token account programs. Metaplex support is listed through the separate metaplex-go repository. This is not a complete Solana wallet or application SDK in the broadest sense. Wallet, account, and key management are marked incomplete. Clients for config, stake, vote, Secp256k1, memo, and name-service are also incomplete in the README feature list. That distinction matters for teams evaluating the module as a dependency rather than merely as an RPC client. The README also points users developing or using Anchor programs to anchor-go for generated Go clients. ## RPC, WebSocket, and transaction data flow The library follows Solana's RPC model. An application creates an RPC client for a cluster endpoint, then calls methods such as transaction retrieval and other JSON RPC operations. The RPC client accepts request context and options, including transaction encoding and the maximum supported transaction version in the README example. Returned data is represented through the library's transaction and account types rather than raw JSON values. WebSocket support covers the streaming JSON API. The documented transaction confirmation flow combines the RPC client with a WebSocket client and sends the transaction through `sendAndConfirmTransaction`. In the README's wording, the call sends the transaction and waits for its confirmation. This is materially different from merely obtaining a signature: an application that needs confirmation must provide the additional client and handle the returned error. Transaction construction is also part of the data flow. The library provides `solana.NewTransaction`, takes a slice of `solana.Instruction` values, accepts a recent blockhash, and configures a payer. It can serialize and pretty-print a transaction through its `String()` method, or encode a tree through `EncodeTree`. The transaction package therefore covers both request-side construction and inspection of the resulting object. The repository layout supports a modular Go package design. Top-level files contain transactions, messages, accounts, keys, signatures, native types, and encoding helpers. Subdirectories such as `rpc/`, `programs/`, `base58/`, `bip39/`, and `text/` isolate transport, program integrations, and utility behavior. This separation is useful when an application only needs RPC access, but it also means the supported program surface is organized into specific packages rather than being uniformly available. ## Installing solana-go and creating a first RPC call The README requires Go 1.25 or later. Its installation example adds the module to an existing Go project. The `$` characters are shell prompts and are not required commands. ## Installation and a first real use The README requires Go 1.25 or later. Its installation example adds the module to an existing Go project. The `$` characters are shell prompts and are not required commands. ```bash $ cd my-project $ go get github.com/gagliardetto/solana-go@latest ``` After the command succeeds, the module is available to the Go project. The README then documents building a transaction from instructions, using a recent blockhash, and printing it. The following is the documented transaction construction shape, with the surrounding application-specific variables omitted. ## Building and confirming a Solana transaction A first real application flow needs more than the RPC client. The library's transaction example composes instructions, sets the recent blockhash, and names the payer. The exact transfer instruction and wallet setup are presented in the README as separate examples, so an application must supply the account keys and RPC endpoint appropriate to its own environment. For confirmation, the README shows the dedicated `confirm.SendAndConfirmTransaction` package and the call below. The `rpcClient` and `wsClient` must already exist, and `tx` must be a transaction built by the application. ## Program clients and unsupported areas solana-go has useful coverage for common transaction operations, but the feature checklist makes the boundaries visible. System transfers, compute-budget transactions, BPF Loader interactions, SPL token operations, and associated token accounts are listed as supported. The README also says that V1 transactions use an inline `solana.TransactionConfig` for compute-budget handling. Other areas are not complete. The project does not claim finished clients for stake, vote, config, Secp256k1, memo, or name-service. Metaplex functionality is documented as living in `github.com/gagliardetto/metaplex-go`, which means applications using those clients may need to depend on and evaluate a separate library. This partial coverage can be a practical advantage when an application needs a narrow integration. It also increases adoption risk when a service needs a broader set of Solana programs. A team should inspect the specific package it plans to call rather than infer complete SDK coverage from the existence of the repository's `programs/` directory. The README also warns that the code is unaudited and should be used at risk. That statement applies to library code as a whole, particularly where applications handle signing keys, serialize transactions, or interpret account data. It is a reason to review code paths and test against controlled environments, not evidence of a defect in any particular method. ## Versioning, maintenance, and upgrade cost The repository presents two parallel branches. `main` is described as the v1 line and the recommended default, with backward-compatible improvements. The `v2` branch is opt-in and contains the same content plus breaking API cleanups. The README specifically tells most users to remain on v1 and choose v2 only when the listed API changes are wanted. The release information associated with the repository includes `v1.25.0` and `v1.24.1` on 2026-10-06, and `v2.1.0` on 2026-09-15. The README text also refers to earlier v1 and v2 release labels, so version documentation should be checked against the repository's release and changelog files before an application pins a dependency. The `CHANGELOG.md` entry is the relevant project-specific place to review for recorded changes. The repository is not archived, and its last push was on 2026-10-09. That supports describing the project as recently pushed, but it does not remove the README's warning that APIs may change. The practical upgrade cost is therefore tied to API compatibility, dependency updates, and program-specific behavior. Teams that value a stable interface should select a major version deliberately and review `CHANGELOG.md` before changing the module version. The repository is licensed under Apache-2.0. That license is relevant to distribution and compliance obligations, but this review does not provide legal advice. The license file should be reviewed for the project's actual obligations in the intended deployment model. ## Conclusion Adopt solana-go when a Go service needs direct Solana RPC, WebSocket, transaction, or supported program integration and can accept an unaudited library with changing APIs. Do not choose it as a complete wallet or program SDK, because key management and several native and SPL clients remain incomplete. Verify the chosen major version, required program coverage, endpoint limits, and confirmation behavior first, then pin the module version used by the application. ## FAQ ### What Go version does solana-go require? The README lists Go 1.25 or later as the requirement. ### How do I install solana-go in a Go project? The README uses `go get github.com/gagliardetto/solana-go@latest` from the project directory. ### Does solana-go support Solana WebSocket APIs? Yes. The feature list marks the full WebSocket JSON streaming API as supported, and the confirmation example uses a WebSocket client. ## Sources - [Issues](https://github.com/solana-foundation/solana-go/issues) - [License: Apache-2.0](https://github.com/solana-foundation/solana-go/blob/main/LICENSE) - [README](https://github.com/solana-foundation/solana-go/blob/main/README.md) - [Releases](https://github.com/solana-foundation/solana-go/releases) - [solana-foundation/solana-go on GitHub](https://github.com/solana-foundation/solana-go) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/solana-foundation-solana-go