Most people who set out to launch a crypto exchange start in the wrong place. They scope a matching engine, a custody system, a liquidity desk, and a market-making program — years of work and a permanent operational burden — before they have written a single line of the thing their users will actually touch. The exchange is the hard part. The brand, the community, and the front-end are the part that is genuinely yours. The opportunity is to keep the second and rent the first.
That is the premise of a white label crypto exchange built on shared on-chain infrastructure: you assemble a branded venue from a settlement layer, a liquidity source, and an onboarding stack that already exist, and you spend your effort on distribution and product design instead of core systems. This playbook walks through what the model gives you on Hyperliquid, the components you assemble, the revenue mechanism, and the sequence to go live.
Don't Build the Exchange — Build the Front-End
A crypto exchange is three things stacked together: a place to match orders, a place to hold and settle value, and a place where users sign in and trade. Building the first two well is a multi-year infrastructure project with regulatory and security stakes that punish mistakes. Building the third — the surface your users see — is product work, and it is where a brand actually competes.
White label DEX infrastructure splits that stack cleanly. The order book, the liquidity, and on-chain settlement live in shared infrastructure that every operator plugs into. What you own and control is the front-end: the domain, the design, the markets you choose to surface, the onboarding flow, and the relationship with the user. You are not bootstrapping a venue from zero — you are attaching a branded experience to one that already clears volume.
This is not a hosted "exchange in a box" where a vendor custodies funds and you resell their book under a skin. Settlement here is on-chain and custody stays with the user. You get the speed-to-market of a white-label arrangement without inheriting custody risk or becoming a black-box counterparty to your own users.
What Hyperliquid Gives You to Plug Into
Hyperliquid is a high-performance layer-1 blockchain with a fully on-chain order book. Unlike automated-market-maker DEXs that price trades against a liquidity pool, it runs a central limit order book — bids and asks, price-time priority — for perpetual futures and spot, with matching and settlement happening on-chain. For an operator, two properties matter most:
- Shared liquidity. You are routing orders into the same book as every other front-end on the network. You inherit existing depth rather than seeding your own from cold, which is the single hardest problem in launching a venue.
- Builder codes. Hyperliquid lets an approved builder attach their address — and a fee — to the orders they send on a user's behalf. The user approves a maximum builder fee, and from then on the orders that flow through your front-end can carry your code. That is the native hook that turns a front-end into a business.
Understanding builder codes is worth a dedicated read; see What Is a Hyperliquid Builder? for the mechanics. The short version: the network is designed to be fronted, and the fee-sharing is a first-class on-chain primitive rather than a side deal.
The Components You Assemble
A branded venue is a small number of parts wired together. Here is what each one does and where the work lives.
| Component | What it does | Where it lives |
|---|---|---|
| Branding & domain | Your name, theme, and URL — the venue users recognize | You own it |
| Onboarding & wallets | Email/social login, embedded self-custodial wallets | Infrastructure layer |
| Funding & bridging | Fiat and crypto deposits, cross-chain routing to the venue | Infrastructure layer |
| Markets | Perps, spot, tokenized RWAs, prediction markets | You choose which to surface |
| Settlement & custody | On-chain matching and settlement; keys stay with the user | Hyperliquid + user |
| Revenue | Configurable builder fee on taker orders | Paid to your wallet |
Branding and domain
This is the part that is fully yours: the domain, the visual identity, the copy, the market selection. To a user, it is your exchange. Nothing about the underlying infrastructure needs to be visible.
Web2-grade onboarding with embedded wallets
The largest drop-off in crypto onboarding is the wallet. Seed phrases, browser extensions, and gas-token chicken-and-egg problems lose users who would otherwise fund and trade. The fix is an embedded, self-custodial wallet provisioned from an ordinary email or social login — no seed phrase to write down, no extension to install. Critically, self-custodial means the private key never leaves the user; signing happens through scoped, revocable agent permissions, so the venue can submit orders on the user's behalf without ever holding their keys. The experience reads like a Web2 app while custody stays with the trader.
Fiat and crypto funding with cross-chain routing
A user funds with what they already have. That means card payments and regional rails — Pix, SEPA, UPI — alongside Apple Pay, Google Pay, and direct crypto deposits. When the deposit lands on a different chain than the venue, the bridging is orchestrated for them: funds route from any supported source chain to the trading venue without the user manually bridging or thinking about which network they are on.
The markets you can offer
You decide which markets to surface. The on-chain stack spans four (covered in depth in the on-chain trading stack guide):
- Perpetual futures — leveraged, no-expiry derivatives, the deepest-volume product on the network.
- Spot — direct token trades against the on-chain book.
- Tokenized RWAs — perps on stocks, commodities, FX, and indices, brought on-chain.
- Prediction markets — event contracts powered by Polymarket liquidity.
A focused launch might surface only perps; a broader one might offer all four under one login and one balance.
On-chain settlement and self-custody
Every trade matches and settles on Hyperliquid's order book. There is no internal ledger to reconcile and no omnibus account you custody for users — positions and balances live on-chain, and the user holds their own keys. This removes an entire category of operational and trust burden a traditional exchange carries, and it is what lets a small team run a credible venue.
The Builder-Fee Revenue Model
The revenue mechanism is a configurable builder fee on every taker order routed through your front-end. You set the fee; the user approves a maximum when they first authorize your builder code; and at settlement the fee transfers on-chain directly to the operator's wallet. There is no invoicing and no payout cycle to wait on — the fee is collected as part of the trade and arrives where you point it.
A few things to keep in mind:
- The fee applies to taker orders — the flow you bring to the book is what you monetize.
- The user consents to a maximum builder fee up front, and that consent is visible and revocable; this is a permissioned relationship, not a hidden markup.
- Hyperliquid sets the ceiling on how high a builder fee can go, and that ceiling can change. Set your fee deliberately against current network parameters rather than hard-coding a number you read once. Keep it competitive — your fee is part of the price your users pay.
Because the fee is per-order and on-chain, your revenue scales directly with the volume your brand drives. The growth lever is distribution, not infrastructure.
The Launch Sequence
A realistic path from decision to live venue:
- Register as a builder and approve your code. Establish the builder address that will carry your fee and have it approved on the network.
- Stand up branding and domain. Theme the front-end, point your domain, choose which markets to surface.
- Wire onboarding. Configure email/social login and embedded self-custodial wallet provisioning.
- Connect funding and bridging. Enable the fiat and crypto rails your audience uses and the cross-chain routing into the venue.
- Set your builder fee. Choose a fee against current network limits and confirm the approval flow users will see.
- Define your compliance policy. Decide your KYC posture and provider before you take real funding (see below).
- Test, then open. Run real deposits and trades end to end on the production stack, then launch to your community.
PropHub provides this as white-label DEX infrastructure on Hyperliquid — onboarding, funding, the four markets, and the builder-fee layer assembled behind your brand. The platform overview and developer API cover how the pieces connect.
KYC and compliance as policy
Compliance is not one-size-fits-all, and it should not be hard-wired into the infrastructure. Treat KYC as a per-tenant policy with a pluggable provider: each operator configures the verification posture their jurisdiction and risk appetite require, and the chosen provider plugs in behind the onboarding flow. A venue serving one market can run a different policy than one serving another, without forking the underlying stack. Decide this early — it shapes your onboarding funnel and your funding rails — and treat it as a deliberate product decision.
The Takeaway
The reason launching an exchange has historically meant a multi-year build is that the model conflated two very different jobs: operating market infrastructure and running a branded trading venue. Hyperliquid's on-chain order book and its builder-code mechanism separate them. The infrastructure — liquidity, matching, settlement, custody — is shared and on-chain. The venue — brand, onboarding, market mix, and the fee you earn on the flow you bring — is yours to design and own.
What changes for a founder is the shape of the work. You are no longer choosing between a credible exchange and a fast launch; the depth and the settlement are already there. The questions that remain are the ones worth answering: who you serve, which markets you surface, how you onboard them, and how you earn from the volume you create. That is a distribution problem, and a focused team can solve it.