VALR x Hydromancer: The Data Infrastructure Behind Africa's Largest Exchange Going Onchain

What is VALR

VALR was founded in Johannesburg in 2018 and has become Africa's largest crypto exchange by trading volume. It serves more than 1.9 million registered users and over 1,900 institutional clients. It is regulated by South Africa's FSCA, holds a provisional licence from the Cayman Islands Monetary Authority, and is backed by Pantera Capital, Coinbase Ventures and F-Prime Capital.

VALR has integrated Hyperliquid

In July 2026, VALR launched more than 200 perpetual markets powered by Hyperliquid's on-chain liquidity. They cover:

• Global equities and indices: NVIDIA, Tesla, Apple, Palantir, the S&P 500, plus pre-IPO names like SpaceX
• Commodities: crude oil, natural gas, gold, silver, copper
• FX: major currencies
• Crypto: hundreds of tokens

Users trade in the VALR app they already know, but every position is verifiable onchain on Hyperliquid.

An exciting merger between CeFi and DeFi

This is the first time a major regulated exchange has natively integrated an onchain protocol as the liquidity source for cross-asset perpetuals. The synergy in the combined product is evident:

• VALR handles what a regulated exchange does best: onboarding, customer support, local fiat rails, and a simple interface.
• Hyperliquid handles what onchain markets do best: deep, transparent liquidity, margining, and a range of markets, including equities and commodities through HIP-3, that no single venue could list alone.

A trader in Africa can take a leveraged view on NVDA or gold from one account. They never need to touch a wallet, a bridge or a private key.

VALR integrates Hyperliquid using Hydromancer

Routing orders to Hyperliquid is the easy part. The hard part is keeping an exact, real-time picture of every user's onchain account state:

• positions and margin
• fills, including liquidations
• funding payments
• deposits and transfers

Considering that Hyperliquid markets are 24/7, VALR infrastructure has to monitor user account and position state at all times.

Here is how a trade works under the hood:

1. A user chooses how much to risk on a market, with optional take-profit and stop-loss.
2. VALR funds the user's Hyperliquid address, approves VALR's builder fee, and sets leverage and isolated margin.
3. VALR places the trade and its TP/SL as a single batch order.
4. From there, the user can add margin, adjust TP/SL, or scale the position up or down.

Every step changes the onchain state that VALR must track. Doing that through Hyperliquid's public API means polling each user one by one, and that doesn't scale to an exchange's user base. Besides that, large businesses like VALR also require SLAs, support, and an ability to submit feature requests. Public APIs have neither.

VALR's engineering team replaced its direct Hyperliquid data calls with Hydromancer. After a testnet phase spent building a production-like setup together, they went live on mainnet.

VALR's architecture now utilizes a lot of unique WebSocket streams and endpoints built previously by Hydromancer team, such as leverage updates and builder order updates streams. Market data for all Hyperliquid markets arrives in a single allActiveAssetCtx stream.

Custom endpoints, built for how a CEX actually works

At Hydromancer, our core value is designing and delivering a single best possible solution for our customers. One unique thing about the VALR-Hyperliquid integration made us rethink a core assumption in Hyperliquid tooling.

On Hyperliquid, a builder only "owns" the orders that carry its builder code. Most data tools, ours included until now, are designed around that self-custodial model. A wallet belongs to its user, and the same wallet might trade through the Hyperliquid UI and a builder frontend in one day. So a builder-level data feed can only show fills tagged with that builder's code.

That leaves big gaps, because a lot of what happens to an account never carries a builder code:

• Liquidations never have a builder code embedded.
• Funding payments never have one either.
• Deposits, withdrawals and transfers never have one, as these are non-trading actions.

A builder that wants the full picture has to fall back to per-user polling: fills per user, open orders per user, and funding per user every hour.

VALR's setup removes that assumption. VALR users cannot export their Hyperliquid wallets, so every action on an address that has approved VALR's builder fee is a VALR action. That let us build a new family of endpoints scoped to builder approval instead of builder codes:

• builderApprovedFillsByTime (REST) and builderApprovedFills (WebSocket). These return every fill by users with an active fee approval for the builder at the time of the fill, liquidations included.
• builderApprovedFundingEvents. This gives funding payments across all of a builder's users in one feed, replacing an hourly loop over every account.
• builderApprovedNonFundingLedgerUpdates. This covers deposits, withdrawals and transfers for all approved users.

We also added supporting pieces:

• a builderLiquidations stream that uses last-touch attribution
• multi-DEX subscriptions on allActiveAssetCtx, so the main DEX and HIP-3 markets come through one subscription

And we reworked pricing so that frequent account-state polling is viable at exchange scale: clearinghouseState is now 40x cheaper.

The result: VALR needs a handful of builder-level streams instead of one request per user per data type. Adding a new user no longer adds a new polling loop.

What's ahead

Distribution and trust will increasingly come from regulated, local platforms, while liquidity lives on open, onchain rails. As HIP-3 brings more equities, commodities and new asset classes onto Hyperliquid, every exchange that plugs in opens global markets to users who couldn't reach them before.

The builder-approved endpoint family is available to any team running a custodial or embedded-wallet integration on Hyperliquid.

Building a CEX or embedded-wallet integration on Hyperliquid? Talk to Hydromancer
Trade 200+ perps markets on VALR