Hyperliquid changed the default answer to a question every trading-app founder eventually faces: do you build your own exchange, or plug into one that already works? For years, launching a derivatives venue meant building a matching engine, bootstrapping liquidity, recruiting market makers, and praying the order book filled up before the runway ran out. Hyperliquid collapses that problem. It lets you run a front-end that taps a shared, on-chain order book — and get paid for the flow you route there.
This guide explains what a Hyperliquid "builder" actually is, how builder codes and builder fees work, and why this model lets a small team ship a credible perp DEX without operating an exchange. If you are weighing whether to build on Hyperliquid or against it, start here.
What Hyperliquid Is
Hyperliquid is a high-performance Layer 1 blockchain purpose-built for trading. Its defining feature is a fully on-chain central limit order book (CLOB): every order, cancel, and fill is processed by the chain's consensus, not by an off-chain server that settles to a smart contract afterward. That distinction matters. On most "on-chain" derivatives platforms, the order book lives on a private server and only the net result touches the chain. On Hyperliquid, the book itself is the chain's state.
The L1 runs both perpetual futures and spot markets natively, with a custom consensus optimized for the latency a serious order book demands. Alongside it sits HyperEVM, an Ethereum-compatible execution environment that lets developers deploy standard smart contracts and compose with the same liquidity and state that the order book uses. So you get two things in one system: a fast native exchange, and a general-purpose programmable layer that can talk to it.
For a builder, the practical takeaway is simple. The hard parts of running a derivatives venue — the matching engine, the liquidity, the settlement guarantees, the risk engine — already exist, are shared across every app on the network, and are maintained by the protocol rather than by you.
What a "Builder" Is
A builder, in Hyperliquid's vocabulary, is a team that operates a front-end or application that routes order flow into the protocol's shared order book. You build the interface — the trading screen, the onboarding, the wallet experience, the analytics, the brand — and Hyperliquid provides the venue underneath it. Your users' orders rest in the same book as everyone else's, matched against the same liquidity, settled by the same chain.
This is fundamentally different from running a white-label of a traditional exchange, where each deployment is an island with its own thin order book that has to be filled independently. On Hyperliquid, every builder draws from and contributes to one common pool of liquidity. A new front-end launched today can offer tight markets on its first trade because it is not bootstrapping depth — it is borrowing the network's.
What a builder typically owns:
- The interface and brand — the actual product users see and trust.
- Onboarding and wallets — how users get in and hold custody of funds.
- Distribution — the audience, the marketing, the community.
- Configuration — which markets to surface, fee structure, UX decisions.
What the protocol owns: matching, liquidity, settlement, custody guarantees, and the risk engine. You compete on product and distribution, not on infrastructure.
How Builder Codes and Builder Fees Work
The mechanism that turns "running a front-end" into a business is the builder code. The flow looks like this:
- A builder registers an on-chain address. This address becomes the builder's identity on the network and the destination for any fees it earns.
- The user approves a builder fee. Before orders from a given front-end can carry that builder's code, the user signs an on-chain approval authorizing the builder to charge an additional fee, up to a maximum the user consents to. This is an explicit, user-side action — the builder cannot set or raise it unilaterally beyond the approved ceiling.
- Orders carry the builder code. Once approved, trades the user places through that interface are tagged with the builder's code. On each such trade, the builder fee is applied on top of the protocol's own trading fees.
- Fees accrue on-chain to the builder's address. The builder fee settles directly to the registered address as part of trade execution. There is no invoicing, no off-chain reconciliation, no trust that a partner will pay out later — it is enforced by the protocol.
Two properties are worth emphasizing because they define the trust model. First, the fee is user-consented and capped: a user explicitly approves a maximum, and nothing can charge above it. Second, the approval is revocable — a user can withdraw their consent, after which the builder can no longer apply the fee to that user's orders. The arrangement is transparent and on-chain on both sides.
The result is an incentive structure that aligns the builder with the protocol and with users. Builders are paid in proportion to the real, settled flow they bring. They monetize by being a good front-end that attracts and retains traders — not by capturing spread off an opaque internal book, and not by running their own matching engine or liquidity program at all.
Note on numbers: builder fees are bounded by protocol-defined limits, and those limits — like the protocol's own fee schedule — can change over time. Treat the exact caps as a parameter to read from the current documentation, not a constant to hard-code into your assumptions.
Building on Hyperliquid vs. Running an Exchange
The clearest way to understand the builder model is to compare it to the traditional path.
| Concern | Traditional exchange / white-label | Hyperliquid builder |
|---|---|---|
| Matching engine | You build and operate it | Protocol provides it |
| Liquidity | You bootstrap it per venue | Shared across all builders |
| Settlement | Your servers; you are the counterparty of record | On-chain, by consensus |
| Custody | Usually custodial; you hold user funds | Self-custodial; users hold keys |
| Risk engine | You design margin, liquidation, oracle logic | Protocol-level, shared |
| How you earn | Spread, internalized flow, fees you set | Transparent, user-approved builder fee |
| Time to a credible book | Long — depth has to be built | Immediate — depth is inherited |
The strategic difference is where your effort goes. Running an exchange means most of your engineering and capital go into infrastructure and liquidity that users never directly see. Building on Hyperliquid frees that effort to go into the things users actually choose you for: a faster, clearer, more trustworthy front-end, better onboarding, and a brand they want to trade through.
There is also a custody and trust upgrade. Because settlement is on-chain and users hold their own keys, a builder is not a custodian of user funds and is not the counterparty to their trades. That narrows your regulatory and operational surface dramatically compared with a venue that holds balances and books trades internally.
Put together, the model rests on four reinforcing properties: shared liquidity, so a new app is competitive on day one instead of after months of liquidity mining; on-chain settlement, so trades are final and auditable rather than dependent on a builder's solvency; self-custody, so builders move from "holder of funds" to "provider of an interface"; and aligned monetization, so builder fees pay you for genuine flow automatically. That is what makes a perp DEX viable as a product decision rather than a multi-year infrastructure commitment. The question stops being "can we build an exchange?" and becomes "can we build a front-end people want to trade through?"
Where PropHub Fits
Routing flow to Hyperliquid still leaves real work on the builder's side: onboarding non-crypto-native users, managing wallets and custody, moving funds across chains, and configuring the builder fee correctly. PropHub provides white-label DEX infrastructure on Hyperliquid that handles this layer. It ships configurable markets across perps, spot, real-world assets, and prediction markets, with embedded self-custodial wallets and Web2-style onboarding so users without a wallet can still get in. It orchestrates funding and bridging across chains, and it pays a configurable builder fee directly to the operator's wallet at settlement — so the monetization described above is wired in rather than rebuilt.
If you want the broader picture of how these pieces compose, see our guides on launching a white-label crypto exchange and the on-chain trading stack across perps, spot, RWAs, and predictions.
The Takeaway
A Hyperliquid builder is not a smaller version of an exchange — it is a different category. The protocol absorbs the parts that used to define an exchange operator: the matching engine, the liquidity, the settlement, the risk logic. Builder codes turn the act of routing flow into a transparent, on-chain, user-consented revenue stream, with fees that users approve up to a cap and can revoke. That arrangement keeps incentives honest in both directions: you are paid for the flow you genuinely attract, and users can always see and control what they are paying. The model rewards teams who are good at product, onboarding, and distribution — and quietly retires the assumption that you need to own an order book to run a trading venue. For most founders, that is the whole point: ship the front-end, inherit the exchange.