Uncapped: Hyperliquid Market Data on DoubleZero Edge

Oil trades on Saturday now. It just doesn't trade at CME.
That's the part of the Hyperliquid story most people skip past, and it's why there's a market data feed for the venue. Hyperliquid runs a central limit order book onchain, so it behaves like an exchange rather than a typical onchain venue. HIP-3 opened market deployment to outside builders, and real-world-asset perpetuals followed: WTI, Brent, gold, silver, S&P 500, Nasdaq 100. Those markets never close, and they've grown into a serious share of total volume. During the U.S.-Israel-Iran conflict earlier this year, TD Securities estimated that roughly 80% of the subsequent WTI move was priced in on Hyperliquid before CME reopened. If you're hedging crude and CME is the only screen you watch, the weekend didn't stop trading, you just found out about it on Monday.
Closing the signal to delivery gap starts with looking at how firms get this data today, and why both existing paths run out of room.
How firms get Hyperliquid data today
There are two ways to pull live Hyperliquid data today, and both fight you as you scale.
Run a node or buy an RPC endpoint, and you pay for throughput: requests, compute units, queries per second. You get everything, and you also inherit that node's latency floor, its placement, and the work of turning raw output into something a trading system can read.
Or use a hosted streaming API. You connect a WebSocket and pay per token or credit, against a hard cap on how many order-book streams you're allowed to open. Published tiers top out around 5, 30, or 100 streams. Hyperliquid has several hundred books. Full coverage breaks the pricing model before you've placed an order.
Both are unicast. The provider sends a separate copy to every client and eats a cost per client, per request, per stream. That's why they meter by token and cap stream counts. The economics force it. And every copy crosses the public internet, where the hop count between the source and your engine changes by the minute.
Traditional venues solved this decades ago. CME, Nasdaq and NYSE publish one canonical feed and push it over dedicated lines by multicast, so every subscriber in the building gets the same message at the same instant. Nobody had built that for an open, permissionless venue, until DoubleZero.
Building efficient market data delivery Hyperliquid participants starts with where the data comes from.
How the feed is sourced
This is the design decision that matters most, and it's the one that's hardest to copy.
The feed doesn't come from one node, and it doesn't come from one operator. Ten separate sources are live today, each reading block output off its own non-validating node peered into the active set, each publishing on its own set of channels, each with its own view of the network. Nobody sits in the middle of that. There's no central service collecting the data and redistributing it.
Multiple vantage points matter because block propagation isn't uniform. Which node hears a given block first depends on who it's peered with, where it sits, and what the network happens to be doing that second. Any single node has a great vantage point some of the time and a mediocre one the rest of the time. Picking one node and calling it the feed means accepting its bad seconds along with its good ones.
So ten sources publish the same venue, and they race.
The wire format was built for exactly this. There's no publisher ID field anywhere in it, and deduplication keys off the event's own content, so a subscriber that receives the same fill from two publishers keeps whichever arrived first and throws the second away. No primary, no backup, no failover logic, no leader election. First arrival wins.
Two things fall out of that. The feed's latency is the minimum across every vantage point instead of the average of one. And no single node is a point of failure, because if one falls behind or drops entirely, the other copies are already on the wire and the subscriber never notices the difference.
It's also why publishers read block output off their own nodes rather than reselling the public WebSocket gateway. That gateway is one more queue between the matching engine and you, and it's the same queue everyone else is standing in.
Sourcing solves the accuracy problem. Delivery solves the speed one.
How the feed is delivered
The publisher serializes each update once into a multicast group. Replication happens in switching hardware at line rate rather than in server software, and the update travels over dedicated links contributed by independent operators instead of over default public internet paths.
Speed is the part people ask about first, and it's the less interesting half. A feed that's quick on average and erratic in the tail is a feed you can't put in a model, because you end up budgeting for the worst case and the worst case is what sets your risk. Hardware replication over dedicated links doesn't just lower the number, it tightens the distribution. A dedicated path doesn't reconverge under you mid-session, and it doesn't queue behind somebody else's backup job. Fast is table stakes. Consistency is the product.
The consequence shows up in the economics. Replicating in hardware means delivery cost doesn't climb with subscriber count, and it doesn't climb with instrument count either. So coverage isn't capped per stream and isn't metered per message, per call, or per credit. Every book on the venue is in the feed.
What gets counted instead is destinations. Two receiving hosts come with each product, additional hosts add 8% of that product's price apiece, and the surcharge stops at 50%, past which that delivery site is unlimited. That's a different shape of meter from the ones in this market, and it's the honest one: the thing that actually costs money to add is an endpoint, not a symbol.
That's the infrastructure. Here's what it carries.
What's included at launch
Everything derives from one order book per instrument, held in memory in the publisher and updated event by event. Top of book and market by order both read off that same applied state, so the light feed and the deep feed can't disagree about the book. That kills an entire category of bug where your quote feed and your depth feed drift apart at 3am and you don't find out until the fills look wrong.
Four feeds, each named for what it covers:
edge-hyper-hl-tob — Hyperliquid native perpetuals, top of book and trades. Best bid and ask per instrument, plus every print with aggressor side and venue trade ID. Use it for pricing and signal generation when you need the fast, light view rather than full depth.
edge-hyper-hl-mbo — Hyperliquid native perpetuals, full market by order. A snapshot plus a continuous stream of per-order adds, cancels and executions, at order level rather than aggregated price levels. Use it to reconstruct true book depth and queue position, not just best bid/ask.
edge-hyper-xyz-tob — HIP-3 real-world-asset perpetuals (gold, silver, oil, equity indices), top of book and trades. Use it to price and signal on the RWA markets with the same top-of-book freshness as the native venue.
edge-hyper-xyz-mbo — the same RWA instrument set, at full market-by-order depth. Use it when a strategy on gold, silver, oil or the equity indices needs full book depth rather than best bid/ask.
A reference channel rides alongside at four or five kilobits per second, carrying the instrument list and the per-instrument decimal conventions and retransmitting about once a minute, so a subscriber cold-starts from the feed alone. Per-instrument snapshots cycle in band, and sequence numbers are per instrument, so a dropped packet costs you one instrument's state and nothing else. There's no side channel and no recovery API to integrate against.
Getting access to it comes down to two commands and a price list.
Pricing and onboarding
There's no circuit to provision. Install the DoubleZero CLI, take the products you want, and join the multicast groups. The connection to the nearest network device comes up on its own, and payment is in USD or USDC.
Feeds are priced flat per month, by product and by where the data is consumed:

Read that Tokyo column carefully, because the split is the whole pricing argument. Price attaches to where the data lands, not to where the firm is incorporated, and a Tokyo package delivers to Tokyo receivers only. If you're already sitting at the venue edge in Tokyo, what you're buying is the feed. If you're consuming it in Chicago or London, you're buying the feed and the distance, and the distance is the part nobody else can sell you.
If raw UDP multicast isn't how your stack wants to eat data, Edge Connect bridges a multicast session to a local WebSocket with one command, in a shape your terminal, your backtester, or an agent-driven trading loop already speaks.
The Edge feed specification
The wire format doesn't know it's carrying Hyperliquid. Every price message carries a numeric source ID naming the upstream venue, so a desk that has integrated one Edge feed has effectively integrated the next. Integrate once and the venue after that costs you a group join.
Solana was the first venue to ship on this format. That it's a prediction market rather than a blockchain is the point. The format doesn't care what sits on the other end as long as there are two sides to a book. Hyperliquid is the next venue on the same format, and one integration covers both.
Solana shreds ride the same network but not this format, because shreds are block fragments rather than a two-sided book. That's the cleanest way to see what the feed specification actually does. The network moves bytes fast. The spec is what makes one venue's book look like the next one's.
Subscribe now: doublezero.xyz/hyperliquid.
Explore the Docs: docs.doublezero.xyz/hyperliquid
Read the Full Announcement: https://doublezero.xyz/journal/doublezero-announces-launch-of-real-time-hyperliquid-market-data-on-edge