Synapse RPC Update: Fixing What Others Worked Around
Most Solana infra breaks at scale, so we rebuilt core RPC queries to handle large data properly with native pagination and consistent results that actually hold up under real load.
Why?
Most infra updates don’t actually change anything.
They look good, they sound technical, but nothing really improves.
This one does.
If you’ve built on Solana properly, you’ve already hit this wall. getProgramAccounts starts breaking when programs get large. getSignaturesForAddress becomes messy to paginate. You end up dealing with timeouts, oversized responses, or just inconsistent results depending on load.
So what happens? People build around it. They patch things, add their own indexing, or just accept that it’s unreliable at scale.
That’s not a real solution. That’s just working around broken infrastructure.
What we shipped
We replaced it.
getProgramAccountsV2 and getSignaturesForAddressV2 are now live on Synapse RPC, running on us-1-mainnet.oobeprotocol.ai.
This isn’t just a tweak or optimisation. The way these queries work has been rebuilt so they actually hold up when you use them in real conditions.
What actually changed
The core issue was simple. These methods were never designed to handle large amounts of data cleanly.
So instead of forcing everything into a single response, we made them properly paginated from the ground up.
Each request now returns a controlled amount of data, and gives you a continuation key to move forward. That key is signed and tied to the request, so it can’t be tampered with or misused. You’re not guessing where to continue from, and you’re not relying on fragile client-side logic.
On top of that, responses are consistent across pages, and errors are handled cleanly. You’re not dealing with random upstream failures or unclear behaviour anymore.
It just behaves the way you expect it to.
What it looks like in practice
From our live node, you can pull around 1000 accounts in roughly 1.57 seconds. If you narrow things down with filters, that drops significantly, sometimes to around 0.65 seconds. Signature queries sit around 0.98 seconds initially and improve once caching kicks in.
But the important part isn’t just speed.
It’s that you can keep going. Page after page, without things breaking, duplicating, or silently failing.
What this means
For builders, this removes a layer of friction that shouldn’t have been there in the first place. You don’t need to build custom systems just to make basic queries reliable. You can focus on your product instead of fighting your infrastructure.
For agents and anything automated, this is even more important. They rely on consistent data. If reads are unreliable, everything on top of them becomes unreliable too. With this, you get deterministic behaviour. No missing data, no duplicated reads, no silent failures halfway through a process.
For the community and holders, this is the part that usually gets overlooked. This isn’t just a backend improvement. This is what makes it easier for builders to choose OOBE, and for real products to run on it without issues.
That leads to more usage. And real usage is what drives everything else.
Why it matters for OOBE
We’ve been clear about what we’re building.
SAP handles coordination. Synapse RPC handles execution. The SDK handles development. The Explorer gives visibility.
If the execution layer is unreliable, the entire system is.
So we fixed it properly, instead of layering more fixes on top.
What’s next
These methods are being integrated into the Synapse Client SDK, with the next release moving to v2.2.0. They’ll also be available in the Playground, and over time this becomes the default way of querying.
Final point
Most infrastructure works fine until it’s actually used at scale.
That’s when it breaks.
The goal here is simple. It should keep working when it matters.