Alchemy expands support on Stellar with Data APIs and Tier-1 validation

Since Alchemy launched Stellar support, with RPC, websocket support, and the same 99.99% uptime and SOC 2 Type II reliability we run across every supported network. Today that footprint goes deeper in two ways: Alchemy is now a tier-1 validator on Stellar, and we've added three indexed Data APIs for reading Stellar at scale.

We participate in Stellar consensus as a tier-1 validator, a trio of geographically dispersed full validators participating in consensus, public history archives, and the network's highest bar for uptime and quorum quality. Tier-1 validators are included in many quorum sets and help support network resiliency.

Alongside RPC and websockets, we now offer three indexed, address-centric Data APIs on mainnet and testnet: transfer history, token balances, and NFT holdings. You send an address and a network, and you get indexed history or state back, with no indexer of your own to run. This is what operating an integrated infrastructure full stack lets us hand a developer, and how that data gets from the chain to a single query.

Why operating the chain matters for reading it

Reading Stellar at production scale is an indexing problem. Soroban RPC serves only a short window of recent ledgers. Horizon gives you history, but answering a question as simple as "every asset this account has ever received" still means paging through a lot of primitives and keeping your own copy in sync. Most teams end up running an indexer just to back a portfolio screen.

Being a tier-1 validator changes what our answer to that problem sits on. Tier-1 orgs run full validators and publish public history archives, which is the same durable, complete ledger record any serious indexer needs. So our Data APIs are not a third party scraping the chain from outside. They run on infrastructure we operate end to end, on the same kind of history record that keeps the rest of the network in sync. Validators, RPC, websockets, and the Data APIs are one stack behind one API key, held to one standard of reliability.

What the Stellar Data APIs do

The surface is deliberately small. Each method takes an account address and a network and returns indexed data that would otherwise require your own backfill:

• Transfer history: the record of asset movements for an address, in paginated format
• Token balances: current asset balances held by an address, in one call
• NFT holdings: NFTs held by an address, covering both classic Stellar assets and Stellar smart contract (Soroban) tokens.

You ask what an address holds or what it has done, and the answer is assembled from indexed history. Exact request and response fields are in the Stellar API quickstart. The shape to keep in mind is address in, indexed history out.

Why Stellar needs a custom pipeline

A generic EVM indexer does not fit Stellar. The ledger has its own structure of operations, payments, trustlines, and classic assets. On top of that, Soroban adds smart-contract tokens with a different model again. An NFT on Stellar can be a classic asset or a Soroban contract token, and a correct holdings answer has to account for both.

So the Data APIs sit on a pipeline purpose-built for that model, in four stages.

How the pipeline works

It starts with Galexie, the Stellar network's official ledger-export tool. Galexie writes ledger metadata to object storage as ordered partitions, which gives us a durable, replayable source of truth for the chain without hammering a node. The chain is exported once, and everything downstream reads from those partitions.

A Stellar-specific ingestor then walks those partitions and writes normalized rows. Two things make it Stellar-aware. It runs one unified model instead of separate backfill and frontfill paths, so historical catch-up and staying at the tip are the same code, checkpointed per partition by highest ingested ledger. And it runs as distinct workloads: one classifies transfers and balances, while a separate NFT classifier walks the same partitions to resolve holdings across classic and Soroban assets. Workers run in parallel and scale per network, so mainnet and testnet are sized independently.

That normalized data lands in a dedicated Stellar ClickHouse cluster. ClickHouse is a columnar database built for analytical reads, which is exactly what these queries are: filter by address, scan, aggregate. Giving Stellar its own cluster isolates its query load, and thereby reducing cross-network latency.

The Data API service reads from ClickHouse and is exposed through the same gateway, authentication, rate limiting, and compute-unit accounting as every other Alchemy chain. Stellar is not a side system with its own login and its own quirks. It is one more network behind the same API key.

What a request looks like

All three methods share one shape. The input is an address plus a network. The output is indexed, paginated history or state, already resolved into the asset model a developer expects, classic and Soroban together. There is no separate "is this recent or historical" decision for the caller, because the unified ingestion model means the index is generally both current and complete.

That uniformity is the point. A team integrating transfers can add balances and NFT holdings without learning a new request pattern, and the same address that works for one method works for all three.

What Alchemy offers for Stellar today

Stellar runs as a first-class network on Alchemy, behind the same API key and tooling as every other chain:

• A tier-1 validator participating in Stellar consensus, with geographically dispersed full validators and public history archives
• RPC and websocket support with 99.99% uptime and global redundancy
• Three indexed Data APIs for transfer history, token balances, and NFT holdings on mainnet and testnet
• SOC 2 Type II certified infrastructure that processes over $1T in onchain transactions

Get started

• Create a key and call Stellar mainnet or testnet from the dashboard
• Find the transfers, balances, and NFT method references in the Stellar API quickstart
• For volume or enterprise needs, get in touch with us

Frequently asked questions

Does Alchemy run its own Stellar infrastructure?

Yes. Alchemy is a Stellar tier-1 validator, operating geographically dispersed full validators that participate in consensus and publish public history archives. RPC, websockets, and the Data APIs run on top of that same infrastructure, so you are reading Stellar from a provider that helps operate the network, not a third-party indexer.

Which networks are supported?

Both Stellar mainnet and testnet. Workers scale per network, so the two are sized independently and a load spike on one does not affect the other.

Do I still need to run my own indexer?

No. The APIs return fully indexed transfer history, balances, and holdings, so you do not need to run Galexie, maintain a backfill, or keep your own copy of the ledger in sync to back a portfolio or history view.

How are Soroban tokens handled?

A dedicated classifier resolves holdings across both classic Stellar assets and Soroban smart-contract tokens, so a single holdings query reflects both models without you reconciling them yourself.

How is this different from Soroban RPC or Horizon?

Soroban RPC exposes only a short window of recent ledgers, and Horizon returns history as raw primitives you have to assemble. The Data APIs return indexed, address-centric answers across the history in one call.