Caching

Caching Web3 data isn’t just hard, it’s uniquely complex. Blockchain state is constantly changing, and individual nodes or providers may return slightly different results depending on network conditions and timing. A system like this can’t just be fast - it also has to be right.

That’s why we built something more than just a cache. At the heart of our infrastructure is a read layer with real-time revalidation, powered by our RPC Agents. These agents continuously monitor, analyze, and propagate fresh data at scale. It delivers with the same reliability you’d expect from a blockchain node, but is purpose-built to serve just your data, fast.

This read layer is the foundation of our multi-tiered caching system. From the Direct Client in your app to the distributed layers of our infrastructure, everything is designed to support and extend this shared, real-time source of truth, delivering consistent results with speed.

This is a feat of engineering we’re proud of. It’s built to handle massive global scale across projects and networks, without ever compromising on correctness.

Caching Architecture

The caching architecture consists of:

🧠 Global read layer with real-time revalidation
⚡ Direct Client local cache
🔒 Inflight Uniqueness
🌐 Peer-to-Peer cache

🧠 Global Read Layer with Real-Time Revalidation

Our read layer is a distributed system that delivers blockchain data in real time, with performance and consistency built in.

It’s powered by RPC Agents, which detect traffic patterns, validate results, and coordinate caching across our infrastructure, including 300+ edge locations. Data is constantly revalidated and made available close to your users, so responses are fast and correct.

Each response is tied to a consistent blockheight, ensuring cached and dynamic results can be safely used together without introducing mismatches.

This system is what allows the majority of requests to be resolved instantly, without hitting your provider, while still reflecting the true state of the network.

To learn more about the RPC Agents that power this system, see the RPC Agents page.

⚡ Direct Client Local Cache

Direct Client maintains a local cache directly in the browser or runtime, giving your app instant access to frequently used and predicted data.

It’s automatically populated using:

Starter Pack: a bundle of essential data sent at startup
Predictive Prefetching: data anticipated based on live traffic patterns
Peer-Assisted Delivery: data relayed securely between users

Because Direct operates in both the client and infrastructure layers, we’re uniquely positioned to coordinate caching - including in the client itself. Traditional RPC requests are bound by network latency, with data needing to travel between your app and your provider’s infrastructure. With Direct Client, the most important responses are often already in place locally and can be delivered with near-zero latency.

🔒 Inflight Uniqueness

Inflight Uniqueness ensures that when multiple users or apps request the same data at the same time, only one request is actually sent - the rest wait for the shared result.

This behavior is coordinated regionally across our infrastructure. Within each region, we guarantee that only one unique request is active at any moment. Everyone else asking for the same thing gets the same response without triggering extra load.

The result is fewer unnecessary requests, faster performance under pressure, and more efficient use of your provider and Direct infrastructure.

🌐 Peer-to-Peer cache

Peer-Assisted Delivery is a peer-to-peer cache layer powered by Direct Client that lets your users share data directly with each other, offloading infrastructure entirely.

Using WebRTC, nearby users can securely relay cached responses in real time. It helps deliver data faster while easing load on the backend, keeping commonly requested responses readily available between nearby users.

Especially useful in high-traffic environments, it allows your app to scale more efficiently. The more users, the better the performance.