Stellar Horizon TxMeta removal: what builders need to do
Quick answer: On December 18, 2024, the Stellar Development Foundation’s hosted Horizon API (horizon.stellar.org) stopped returning transaction metadata by default. The result_meta_xdr field on the transaction resource is now nullable, so applications that read ledger changes from it can get null. Builders who need that data should query the getTransactions method on Stellar RPC instead.
Updated 07/17/2026. By Jake Claver. Educational content, not investment advice.
This is a plumbing change, not a token story, but it broke real integrations, so it is worth understanding precisely. Stellar is a payments-focused blockchain, and Horizon has long been the main REST API developers use to read the ledger and submit transactions. Part of what Horizon exposed was transaction meta: the detailed record of every state change a transaction produced.
What TxMeta is and why it was on Horizon
Transaction metadata describes the changes a transaction made to the ledger: balances moved, entries created or deleted, offers filled. On the Horizon transaction object it appeared as result_meta_xdr, documented as “a base64-encoded representation of the raw TransactionMeta XDR struct” (see the transaction object reference). Horizon had served this since its inception in 2015, so a lot of tooling, indexers, and effect parsers were built to read it straight off the REST response.
What actually changed, and when
The change was originally slated for a Q3 2024 protocol window and then postponed. Per the Protocol 22 upgrade guide: “On December 18, Transaction Meta (tx meta) will no longer be returned by SDF’s hosted Horizon API by default.” Responsibility for serving that data shifted to Stellar RPC and Stellar Core.
Concretely, two things happened for anyone pointed at horizon.stellar.org:
- The
result_meta_xdrfield became nullable. If Horizon runs withSKIP_TXMETA=true, the field returnsnull; with the flag off it still carries the base64 XDR. - The listing and single-transaction endpoints under /transactions stopped guaranteeing that field on the public instance.
If you run your own Horizon, you keep control. The upgrade guide notes operators “can emulate this behavior by configuring the SKIP_TXMETA flag, should they also choose to stop serving Transaction Meta.” So self-hosters can keep serving meta by leaving that flag off, at the cost of storing and indexing it.
From the source
How to read transaction meta now
The supported path is the getTransactions method on Stellar RPC. Its API reference returns resultMetaXdr as a base64-encoded XDR string alongside envelopeXdr, resultXdr, and diagnostic and contract events. You decode it with the same XDR types you already used for Horizon’s result_meta_xdr, so the parsing logic mostly carries over. What changes is where you fetch it and how far back you can reach.
The retention catch
RPC is designed for recent data, not deep history. RPC serves transaction metas within its retention window, which the Protocol 22 guide describes as roughly seven days, and the exact depth depends on how each RPC provider configures its node. If you need meta for older transactions, you go to Stellar Core’s history archives or run ingestion that stores meta as it streams. In practice that means account histories, tax exports, and analytics that reach back months cannot lean on a single RPC call the way they may have leaned on Horizon.
Why this matters
For most end users nothing visible changed: payments still settle. The impact lands on builders. Wallets that showed itemized effects, block explorers, accounting and compliance exporters, and any indexer that read result_meta_xdr off Horizon had to either repoint to RPC, run their own Horizon with meta enabled, or build an ingestion pipeline for historical meta. If a service silently assumed the field was always present, it would start seeing null and, if it did not handle that, break. The fix is straightforward once you know the cause: handle the nullable field, move recent-meta reads to getTransactions, and decide deliberately how you will source anything older than the RPC window.
Common questions
Was TxMeta removed from the Stellar protocol itself?
No. Transaction metadata still exists and is still produced by the protocol. What changed is that SDF’s hosted Horizon API stopped serving it by default as of December 18, 2024. The data now comes primarily from Stellar RPC and Stellar Core.
Is result_meta_xdr gone from Horizon completely?
Not necessarily. The field became nullable. On the public horizon.stellar.org it returns null, but an operator running their own Horizon with SKIP_TXMETA off can still serve it.
How do I get transaction metadata now?
Use the getTransactions method on Stellar RPC. It returns resultMetaXdr as a base64-encoded XDR string that you decode with the same XDR definitions you used before.
How far back can RPC give me meta?
RPC serves metadata within its retention window, described as about seven days, with the exact depth set by each RPC provider. For older transactions you use Stellar Core history archives or your own ingestion store.
Does this affect the tokens or price of Stellar?
This is a developer API change about how metadata is served. It does not by itself change tokenomics, and this article makes no claim about price. Treat it as infrastructure information, not an investment signal.
This content is educational only. It is not tax, legal, or investment advice. Check primary sources and speak with a qualified professional before making financial decisions.
