Solana Keychain v2 Adds Python and Go, Fordefi and Ledger Signers, and an OtterSec Audit

The Solana Foundation released Solana Keychain v2.0.0, a new major version of its open-source library for signing Solana transactions from servers, on 1 October 2026. Python and Go builds reached their first stable release alongside the existing Rust and TypeScript packages, Fordefi joins as the 14th supported signing backend, and a Rust-only Ledger hardware-wallet signer arrives as an opt-in. According to the v2.0.0 release notes, OtterSec audited all four language implementations and all 27 of its findings are resolved.

What Solana Keychain does for backend transaction signing

Solana Keychain gives server-side code one signing interface that works across many key-management providers. Any service that signs Solana transactions on its own, whether it is paying fees for users, sending program transactions or running a treasury, has to keep a private key somewhere. Solana's Signing in Production guide tells those services to "use a dedicated key-management backend rather than a raw keypair."

Those backends come in very different shapes. Some are cloud key services (AWS KMS, GCP KMS, HashiCorp Vault). Others are custody and wallet-infrastructure providers such as Fireblocks, Turnkey, Privy, Dfns, Para, Utila, Crossmint, Openfort and Coinbase Developer Platform (CDP), and each has its own API. Keychain puts a single SolanaSigner interface in front of all of them. The Solana guide says this lets a team "develop locally with an in-memory key and switch to a production backend through configuration, without rewriting application code." It works much like a travel plug adapter: the application is written against one socket, and the provider behind it can change.

Python and Go builds, Fordefi and Ledger signers, and SIMD-0385 v1 transactions

Solana Keychain v2 adds two languages, two signers and support for Solana's newer transaction format. Before v2, only Rust and TypeScript had stable releases. Python and Go got their first stable tags on 1 October, and the release notes say both now "reach feature parity with Rust and TypeScript." The Python package is published on PyPI as version 2.0.0, installs with pip install solana-keychain and needs Python 3.10 or newer. The Go version ships as "one module per backend", as the library's maintainer, @dev_jodee, wrote in the announcement thread.

Fordefi, an institutional wallet provider, is the new 14th backend and works in all four languages. It runs in one of three modes, chosen when the signer is created: black box, native auto and native manual. In the native modes Fordefi can rewrite the transaction before signing it, and in native auto it also broadcasts the transaction to the network itself.

The Ledger signer is narrower. It is available only in Rust, sits behind an opt-in ledger feature flag, and is marked unaudited. Ledger signing has also been moving forward on the consumer side, where Jupiter brought readable Ledger signing to limit orders and DCA on 30 September. The Keychain signer serves a different user: an operator signing from code with a hardware device.

Version 2 also handles v1 transactions, the newer transaction format defined in SIMD-0385. The release notes say v1 transactions "now sign correctly across all backend implementations and programming languages." In Rust this needs the sdk-v4 feature, and Go needs solana-go v2.

OtterSec audit: 27 findings resolved across Rust, TypeScript, Python and Go

OtterSec reviewed the Rust, TypeScript, Python and Go code, and the repository's audit status page lists 27 findings: 4 medium, 15 low and 8 informational. All 27 are marked resolved, and the full report is published in the repo. The Ledger backend was excluded from the audit's scope. An earlier audit by Accretion covered only the Rust and TypeScript code, so v2 is the first release in which the Python and Go builds have been through a third-party review.

v2.0.0 breaking changes: capability-based signers, Kit 8 and Crossmint send-only

Upgrading from 1.x is not drop-in. "heads up, v2 has breaking changes, but we provided a migration guide to help you," the maintainer wrote in the release thread. The migration guide covers these changes:

• Every backend now declares exactly one transaction capability: sign the transaction it is given (TransactionSigner), rewrite it and then sign (ModifyingSigner), or sign and broadcast it itself (SendingSigner). The shared SolanaSigner keeps identity, message signing and health checks.
• TypeScript no longer exports backend classes. Signers are built with factory functions such as createPrivySigner(), and type guards like isSolanaTransactionSigner() tell code which capability it holds.
• TypeScript packages now require @solana/* version 8.1.0 or later, up from 6.0.1.
• Crossmint is now send-only. Sign-only calls and off-chain message signing are gone; integrations call sign_and_send_transaction instead.
• A new BROADCAST_UNCONFIRMED error covers cases where a provider that broadcasts for you fails but may already have landed the transaction on-chain. The error carries an idempotency key and transaction identifiers so code can check whether the transaction landed before retrying.
• Go module paths now end in /v2, and Rust signing methods take a VersionedTransaction.

The capability split is the change most integrations will feel. Under v1 every backend presented the same signing method, even a provider such as Crossmint that sends the transaction itself. In v2 the signer's type tells the developer up front what that backend will do with a transaction.

Installing Keychain v2 from crates.io, npm, PyPI and Go modules

Keychain v2 is aimed at teams whose servers sign Solana transactions, such as fee-sponsorship services, treasuries and apps that keep their keys with a custody or cloud key-management provider. Teams writing Python or Go can now use the same library, under the same audit, as Rust and TypeScript teams.

The code is open source under the MIT licence in the solana-foundation/solana-keychain repository. Rust developers get the solana-keychain crate, TypeScript developers @solana/keychain, Python developers the PyPI package, and Go developers the per-backend modules. The maintainer's launch post calls Keychain "your favourite way to sign your txns on Solana". For Solana builders, the practical result is that moving from a test key to a production custodian, or between custodians, has become a configuration change in four languages.