Introducing the Golang Stellar SDK
Author
Molly Karcher
Publishing date
TL;DR:
We’re consolidating our Golang developer tools - including the Horizon and RPC clients, Ingest SDK, and key utilities - into a single, unified Go SDK for Stellar. This change simplifies the developer experience, improves discoverability, and aligns the Go ecosystem with the structure of other Stellar SDKs.
Why we’re making this change
For years, developers building on Stellar in Go have worked within a single, sprawling monorepo. That repository housed nearly everything, but it wasn’t always clear where the boundaries were.
In practice, this meant developers often had to:
- Dig through the monorepo to find usable SDK components, since they lived alongside service code.
- Guess which packages were safe to depend on, by relying on weak conventions such as packages being named “internal”.
- Import the RPC client from a separate repository, breaking the otherwise unified experience.
- Miss out on powerful tools like the Ingest SDK, simply because they weren’t clearly surfaced as part of the SDK ecosystem.
- Navigate an extensive CI setup, even to make the smallest of changes.
This structure blurred important lines: it wasn’t obvious which Go packages were part of the Composable Data Platform paradigm (and therefore designed for reuse) versus which were tightly coupled to Horizon or other services. That lack of clarity made it harder for the community to adopt or extend our data tooling, even though much of it was built with reuse in mind.
Meanwhile, developers in other languages enjoyed a simpler, clearer setup. Most Stellar SDKs (JavaScript, Python, Java, etc.) already co-locate their Horizon and RPC clients in a single, well-scoped repository, with explicit entry points and documentation.
The new Go SDK fixes this. It means only reusable developer-facing packages stay in the monorepo, making it clear what’s part of Stellar’s official SDK surface. It’s about discoverability, maintainability, and giving Go developers the same cohesive experience enjoyed elsewhere in the Stellar ecosystem.
What’s changing
The Go repo - previously stellar/go - will be renamed to stellar/go-stellar-sdk to align with the naming conventions adopted by most other Stellar SDKs and make its intent clearer to end-users. This means that any developers currently using any of the below clients, libraries, or utilities will need to rename all package import statements from github.com/stellar/go/* to github.com/stellar/go-stellar-sdk/*.
The new Go Stellar SDK contains:
- Horizon API Client (horizonclient): for querying a deployed Horizon instance.
- RPC API Client (rpcclient) : For interacting with a deployed Stellar RPC instance.
- Transaction Builder (txnbuild): library that helps construct transactions.
- Ingest SDK: For parsing raw ledger data from Captive Core or Galexie data lakes.
- Foundational utilities: Useful common packages like xdr and strkey.
- Reusable data abstractions: Processors or transforms for ETL-style workflows (such as the Token Transfer Processor).
At the same time, several structural changes are being made to simplify the Go ecosystem and clarify ownership:
- Horizon, Galexie, and Friendbot moved into their own dedicated repositories.
- Developers building these services from source should begin relying on releases from these new repositories.
- Distribution of pre-built Debian packages and Docker images will remain unchanged.
- Legacy services that are no longer actively maintained by SDF have been deprecated and removed. These remain available in Git history for anyone who wishes to fork or maintain them independently. Services affected include:
- recoverysigner
- webauth
- market-tracker
- regulated-assets
- ticker
- keystore
- federation
What comes next
This reorganization isn’t just a cleanup, it’s a step toward a clearer, more unified developer experience across the Stellar ecosystem. With this new SDK structure, we can:
- Help developers transition from Horizon’s indexed APIs to Stellar RPC or Stellar’s raw data model.
- Enable integrations with data products like Galexie or other components of CDP.
- Introduce more high-level abstractions (a la “processors”) in a way that’s modular and consistent across languages.
- Encourage more external contributions to all of the above components, with a repository that’s less intimidating and more modular.
If you’re a Go developer currently using Horizon, RPC, the Ingest SDK, or any other Golang utilities maintained by SDK, we’d love your feedback (or contributions!) as we continue shaping this unified SDF experience. Share your thoughts in our Developer Discord or participate in the Github Discussion.