RabbitStream now supports ALT (Address Lookup Table) resolution, Same coverage as yellowstone gRPC

The last major blind spot in RabbitStream’s transaction coverage is gone. ALT resolution now runs at the shred layer, closing a gap of up to 3x on programs like pumpAmm, with zero added latency. 99%+ similar coverage as Yellowstone gRPC.

This blog illustrates what RabbitStream is, what ALT resolution actually means, how Yellowstone gRPC has always handled it, and what changes for you now that RabbitStream supports it too.

TL;DR

  • RabbitStream reads transactions at the shred layer, before ALTs are resolved.
  • Filters like accountInclude previously only matched static account keys, missing anything referenced through a lookup table.
  • For ALT-heavy programs like Meteora DLMM, that meant coverage as low as 14.6% of Yellowstone gRPC.
  • RabbitStream now resolves ALTs independently at the shred stage — no client-side changes needed.
  • Post-fix testing shows 98.9%–99.9% parity with Yellowstone gRPC, with no added latency.

What is RabbitStream?

RabbitStream listens directly to raw UDP shreds as they propagate across the Solana network, independently of any RPC node. Reconstructs them server-side, and delivers the decoded transactions through a Yellowstone-compatible gRPC interface. Same SubscribeRequest format as Yellowstone gRPC, so no new client or decoding logic. The tradeoff for the speed: no meta – no logs, no inner instructions, no confirmed balances, since data arrives pre-execution.

What is Address Lookup Table (ALT) resolution

A Solana transaction needs to list every account it touches. For a long time, that meant every account pubkey – 32 bytes each – got written directly into the transaction message. Complex transactions that touch a dozen-plus accounts got expensive fast, just from account references alone.

Address Lookup Tables (ALTs) fix this. An ALT is an on-chain account holding a list of addresses. Instead of embedding a full pubkey in the message, a transaction can reference an ALT plus an index – a single byte pointing at position N in the table. A transaction’s address_table_lookups field carries the ALT’s pubkey and the writable_indexes / readonly_indexes it needs.

The catch: the transaction message alone doesn’t tell you which accounts those indexes point to. You have to resolve the ALT – fetch the table, look up each index, get the actual address back – before you know the transaction’s real account set. Any filter matching on accountInclude has to do this resolution correctly, or it’ll only ever match static keys and silently miss everything routed through a table.

That’s not an edge case anymore. Most swap and AMM traffic on Solana today – Raydium, Meteora, pump.fun AMM – routes through ALTs by default.

How Yellowstone gRPC handles ALT resolution

Yellowstone gRPC resolves this server-side. Alongside the raw transaction message, it returns loaded_writable_addresses and loaded_readonly_addresses – the actual addresses behind each ALT index, already resolved. Filters like accountInclude check these resolved fields as well as the static keys, so a transaction referencing your target account through a lookup table matches just like one that references it directly.

This works because Yellowstone taps the pipeline after Replay – by the time it emits a transaction, execution has finished and the runtime has already resolved every ALT reference as part of processing the block. The resolution is essentially free at that point; the data already exists.

RabbitStream doesn’t have that luxury.

Why ALTs were missing with Rabbitstream?

RabbitStream reads data at the shred layer – before a block is replayed, before lookup tables are fully resolved. That’s what makes it fast. It’s also what caused a coverage gap.

When you filtered on account_include, RabbitStream only checked static account keys in the transaction message. Any transaction that referenced your target account through a lookup table instead of a static key – which is most transactions routed through an AMM or aggregator – got missed.

The impact was worst on programs that live almost entirely behind ALTs. For pumpAmm, that meant roughly 3x fewer transactions than Yellowstone gRPC.

How RabbitStream fixed it

RabbitStream now resolves lookup tables at the shred stage. account_include: pumpAmm checks static keys and lookup table references. No client-side changes needed – same filters, same subscription, more matches.

We benchmarked the fix against Dragon’s Mouth (Yellowstone gRPC) before rollout, using a getBlock-style reconciliation tool across shared slot ranges. Three programs, three different ALT usage patterns:

ProgramDragon’s MouthRabbitStream (pre-fix)RabbitStream (ALT-resolved)Coverage before → after
Meteora DLMM40,4275,89740,36914.6% → 99.9%
pump.fun131,675106,349131,54880.8% → 99.9%
pump.fun AMM (pumpAmm)143,42951,061141,83135.6% → 98.9%

Same slot ranges, same accounts, run back-to-back against Dragon’s Mouth as the reference.

A few things stand out:

  • Coverage gap tracked directly with how ALT-heavy a program is. Meteora DLMM transactions almost always route through lookup tables – pre-fix coverage was 14.6%. pump.fun uses static keys more often, so it was already at 80.8% before the fix.
  • pumpAmm landed close to the number in the original bug report – pre-fix RabbitStream returned about a third of what Dragon’s Mouth saw, in line with the “3x fewer transactions” we’d flagged internally.
  • Post-fix, all three programs sit at 98.9% – 99.9% parity with Dragon’s Mouth. The remaining gap is normal cross-endpoint variance, not missed ALT resolution – expect small deltas like this even between two correctly-configured gRPC endpoints.

Latency

Resolving lookup tables at the shred stage adds a lookup, so it’s fair to ask what it costs. Short answer: nothing you’d notice. We tested this specifically before rollout, and RabbitStream keeps its shred-stage speed advantage over standard gRPC – you’re not trading latency for coverage.

Conclusion

ALT resolution closes the largest functional gap between RabbitStream and Yellowstone gRPC. You now get gRPC-equivalent filtering – including ALT-heavy programs like Meteora, Raydium, and pump.fun AMM – at shred-stage speed, with no meaningful latency cost. If you built filters around static account keys only, or ran a parallel Yellowstone subscription just to catch what RabbitStream missed, you can simplify back down to RabbitStream alone.

This is one of the last major differences standing between RabbitStream and full Yellowstone gRPC compatibility. No action needed on your end – the update is live now, in every region.

If you liked this article, feel free to checkout our other articles on what is RabbitStream or how RabbitStream differs from Solana Yellowstone gRPC to find out more.

Getting Started

RabbitStream uses the standard Yellowstone gRPC subscription protocol, so if you’re already familiar with gRPC streaming on Solana, the learning curve is nearly flat.

Resources

Related Posts