GoldRush: Lessons From Building Infrastructure for Hyperliquid

Hyperliquid is not a normal ecosystem to enter for an EVM-first data provider.

That matters to us because GoldRush has a simple north star: index all of the world's blockchain data and make it usable for builders. For years, that work has mostly meant making EVM data easier to access. We index chains, decode wallet activity, surface balances, transactions, token transfers, onchain price feeds, traces, and historical state through APIs that save developers from running their own infrastructure.

Hyperliquid stretches that mission in a new direction.

Its promise is much bigger than another trading venue. Hyperliquid is building toward a world where more of finance can live on open rails. If that vision plays out, builders will need more than basic API access. They will need production data infrastructure that can support trading, wallets, tax, analytics, accounting, risk, and eventually applications across both HyperCore and HyperEVM.

At first glance, Hyperliquid can look like another integration where we simply add the endpoints, expose the data, update the docs, and move on. But that is not how it played out.

The first signal came from builders who were not asking us for a new abstraction. They wanted the same Hyperliquid API interface their systems already used, backed by more history, more scale, more predictable infrastructure, production-level rate limits and in some cases lower latency than shared public infrastructure is designed to provide.

We entered Hyperliquid thinking about data coverage. We quickly found ourselves working on compatibility, historical datasets, Streaming API support, drop-in /info and /ws replacements, wildcard streams, batch patterns, latency benchmarking, and more structured accounting and financial data.

In other words, Hyperliquid pushed us beyond indexing and toward a more complete production data layer.

Why Hyperliquid changed how we think about onchain data

Most people say "Hyperliquid" when they mean the broader ecosystem: the exchange, APIs, builders, and infrastructure around it. We will use the term that way in this series too.

The more precise distinction matters for data:

• Hyperliquid is the flagship decentralized exchange (DEX) built on HyperCore

• HyperEVM is separate and brings EVM compatibility into the ecosystem.

HyperCore data looks more like exchange data: order books, fills, funding, liquidations, account state, vaults, builder activity, and per-market updates.

HyperEVM data looks more like the EVM data GoldRush has indexed for years: blocks, transactions, logs, token transfers, balances, contracts, and traces.

Builders increasingly need both. That is what makes Hyperliquid different from a typical chain integration. It has the speed expectations of an exchange, the transparency of onchain systems, and a builder ecosystem moving quickly around trading terminals, wallets, tax tools, analytics products, risk systems, and market data platforms.

The public Hyperliquid API is the natural starting point. It is simple, familiar, free to use and gives builders a direct way into the ecosystem. But production teams eventually run into a different set of needs: compatibility, depth, scale, and performance.

That is where a dedicated data layer starts to matter.

The journey started with customer pull

Our Hyperliquid roadmap came from builders asking for specific things:

• Can we track a large number of wallets without polling public endpoints?

• Can we use the same /info request shape but avoid public API limits?

• Can we get historical fills beyond what is easy to retrieve from public endpoints?

• Can one stream cover many markets?

• Can we handle thousands of orderbook streams concurrently with very low latency?

• Can we surface richer account details like wallet performance, PnL and other high value metrics?

These were practical questions from teams trying to ship products. That shaped how we built.

We did not want to hand Hyperliquid builders a generic blockchain API and ask them to reshape their workflows around us. In several cases, the better product decision was to meet them where they already were.

That meant building APIs that looked familiar to Hyperliquid developers, then backing them with GoldRush infrastructure, historical data, and production reliability.

Lesson 1: Streaming has to scale beyond polling

We started with our Streaming API.

Streaming decoded user activity is already one of GoldRush’s core strengths, so extending that model to Hyperliquid made sense. The format is different from native Hyperliquid WebSockets because our Streaming API uses GraphQL-over-WebSocket. But the goal is similar: help teams track user activity at scale without constantly polling public endpoints or maintaining their own indexing stack.

That matters more on Hyperliquid because the system moves fast. Hyperliquid block times are on the order of 70 ms. A polling loop that runs every few seconds is not close to live, and trying to poll faster turns wallet monitoring into a high-frequency request scheduler across every watched address.

This matters for wallets, tax platforms, accounting tools, portfolio products, and analytics systems.

If a team needs to follow activity across tens of thousands of users, polling does not scale cleanly. Builders need a stream that can watch a large account set and push decoded activity as it arrives, in a format their product can consume directly.

That is where the first part of our Hyperliquid work began: take what GoldRush already does well, then extend it to HyperCore-specific activity.

In the next post, we will go deeper into how this scaled to monitor 200K+ wallets through a single GraphQL-over-WebSocket subscription.

Lesson 2: Compatibility beats architectural purity

From the Streaming API, we moved into drop-in Hyperliquid API compatibility.

This was an important decision because it cut against one of our usual instincts. GoldRush has usually pushed toward unified APIs across ecosystems. That philosophy still matters. But Hyperliquid made the tradeoff obvious.

If a team already builds against Hyperliquid's public API, asking them to learn a new abstraction adds friction. That applied to both /info and WebSocket.

Our Streaming API uses GraphQL-over-WebSocket, which works well for decoded user activity at scale. But many Hyperliquid builders were already wired into the native WebSocket pattern. For trading products and market data consumers, drop-in compatibility mattered more than introducing a cleaner abstraction.

That is why we built compatible /info and /ws APIs, then backed them with our own data infrastructure where it made sense.

That lets us support historical datasets, batch access patterns, custom methods, enhanced streams, and rate limits designed for production use. It also lets builders move beyond some of the constraints that naturally exist in public infrastructure.

This is not a criticism of the public API. Public infrastructure has to protect itself. It cannot be optimized for every production workload, every historical query, every high-volume wallet sync, or every custom data access pattern.

A dedicated data layer can make different tradeoffs.

Lesson 3: Market data is only useful if it stays fresh

Once we had /info, the next pull was WebSockets. 

Market data and user streams are central to Hyperliquid. Builders asked for native-style WebSocket streams, wildcard support, and custom streams for trading workflows. So we expanded into /ws.

This included supporting familiar stream patterns, adding methods builders asked for, and improving how teams could subscribe across markets. It also pushed us into more specialized market data work, including streams like l2BookDiff.

That was where the problem became less about coverage and more about production behavior.

Correct but stale data is still broken for trading products. If the order book arrives too late, it does not matter that the payload is right.

In one benchmark, our earliest market-open runs exposed backlog behavior we were not happy with. A week later, the same benchmark looked radically different. That story deserves its own post, because it changed how we thought about the whole stack.

Lesson 4: Production infrastructure is measured, not assumed

Once we understood how much freshness mattered, benchmarking became part of the product.

Region mattered. Queueing mattered. Fanout mattered. Message shape mattered. Cloudflare configuration mattered. Dedicated node placement mattered. The underlying data stack mattered.

We had to benchmark, compare, tune, and measure again.

For l2BookDiff, the work was not just "do we have the stream?" It was: how fresh is it during market open, how much jitter is there, does backlog build, how does it compare to other providers, and what part of the stack is creating latency?

That is the kind of work production data infrastructure has to take on.

Hyperliquid builders are not all asking for the same thing. Tax platforms care about complete historical activity. Wallets care about user state and portfolio views. Trading terminals care about fast order books and WebSocket reliability. Market makers care about latency and coverage. Analytics teams care about normalized history. HyperEVM builders need indexed onchain data that connects back to the broader ecosystem.

A complete data layer has to serve these needs without forcing every team to build the same infrastructure themselves.

What we learned so far

Hyperliquid infrastructure has to be four things at once: compatible, deep, scalable, and fast.

• If it is not compatible, builders will not migrate.

• If it is not deep, production apps cannot reconstruct history.

• If it does not scale, wallets, tax platforms, and analytics teams hit limits quickly.

• If it is not fast, trading products cannot rely on it.

That combination is what pushed GoldRush from indexing into production market data infrastructure.

What this series will cover

This first post is the introduction. The rest of the series will go deeper into each part of the journey.

1. Scaling Hyperliquid wallet activity with GoldRush Streaming API
   How we extended our existing Streaming API to support HyperCore-specific events and monitor 200K+ wallets through a single GraphQL-over-WebSocket subscription.

2. Going beyond Hyperliquid's public API with a drop-in /info replacement
   Why we built a compatible /info API, why that meant breaking from our usual unified API model, and how historical data, batch endpoints, custom methods, and weight-aware rate limits help builders move beyond public API constraints.

3. Building low-latency Hyperliquid WebSockets for production trading
   How we built a drop-in /ws replacement, added enhanced and custom trading streams, benchmarked l2BookDiff, and iterated on the infrastructure to improve latency.

4. What it means to be the complete data layer for Hyperliquid
   Where GoldRush goes next with account performance, PnL, tax workflows, and other custom methods. This will also cover what HyperEVM support adds and our commitment to the early builder program.

Where we go from here

We entered Hyperliquid thinking we were adding coverage for another ecosystem.

We quickly learned it was a different kind of infrastructure problem.

This series is about what we learned, what we built, and where we think Hyperliquid data infrastructure goes next. Builders need more than a public API. They need compatible, historical, scalable, low-latency, production-ready infrastructure across HyperCore and HyperEVM.

That is the layer GoldRush is building.