White label DEX and DeFi: build, fork, license or buy?

A white label DEX or DeFi product is audited, working infrastructure that a provider deploys under your brand, with your fees, tokens and chain configuration. It is usually the fastest of four ways to launch. The other three are forking open-source code yourself, licensing code that sits under a business source licence, and building custom. Which one fits depends on three questions: what part of the product is actually yours, how much of the security work you want to own, and whether the code you want to start from is even legal to use in production.

We build all four for clients, and we also offer white-label DEX and lending infrastructure ourselves, so we have a stake in this answer. We'll try to be straight about when each one is the wrong choice.

The four routes compared

All time ranges here are our planning estimates for an MVP on one EVM chain, not quotes.

Forking: open code, closed bugs

Forking means taking public contracts and deploying your own copy. Many AMMs started as Uniswap forks and many lending markets as Compound v2 forks. It works because the base code is battle tested, and it is cheap because the expensive design work is already done.

Check the licence first. The licence on the repo you want to fork is not always the licence you can rely on in production:

• Uniswap v2 core is GPL-3.0, which allows commercial forks provided you meet GPL terms.
• Uniswap v3 started under a business source licence, which expired on April 1, 2023, after which the code became open for forks.
• Compound's v2 protocol repo is BSD-3-Clause.
• Morpho Blue is GPL-2.0.

The bigger issue is security. A fork inherits every known bug in the original code, plus every bug that only shows up under your configuration. Hundred Finance, a Compound v2 fork, was drained of about $7 million on Optimism in April 2023. According to Halborn's analysis, the attacker used an empty WBTC market, donated tokens to inflate its exchange rate, and exploited a rounding issue on redemption. BlockSec described it as the start of a wave of precision-related exploits in forked protocols. The rounding behavior came from upstream code. The deployment choice, an empty market nobody seeded, made it exploitable.

What that means in practice:

• An audit of the original does not cover your deployment. Get your diff and your configuration audited, including market listing and initialization steps.
• Read the upstream project's post-mortems and known issues. Most fork exploits repeat attacks someone already published.
• Plan who patches the fork when upstream discovers a bug. Nobody will do that for you.

If you are forking a lending protocol, our guide on building a DeFi lending protocol covers the risk parameters you will have to set yourself.

Licensing: reading a BUSL

Several leading protocols now ship new versions under the Business Source License 1.1. The terms vary by project, and the details decide whether your plan is legal.

Uniswap v4 is a good example to read in full. Its BUSL licence file grants the right to copy, modify and make non-production use of the code. Production use requires an Additional Use Grant, listed at an ENS record, or a commercial licence. The Change Date is the earlier of June 15, 2027 or a date set at a second ENS record, and the Change License is MIT. Uniswap's governance forum explains that UNI holders vote on who receives grants and whether to convert the licence early.

Aave takes a different approach. The aave-v3-origin repository is under BUSL 1.1 that allows any usage provided it respects the Additional Use Grant, which forbids any use case damaging the Aave DAO's interests. Integration interfaces are MIT. A competing lending market built from that code is the use case it is written to block.

Questions to answer before you build on licensed code:

1. Is your use "production" under the licence? Any mainnet deployment with real users almost certainly is.
2. Does a grant exist for your use, chain and entity, or do you need governance approval? How long does that vote take?
3. What conditions come with the grant? A grant can limit modifications, sublicensing or the chains you deploy on, so read it as closely as the licence.
4. When is the Change Date, and does waiting for it make more sense than negotiating?
5. Do any dependencies carry different terms?

Have a lawyer read the actual licence and grant text. We can tell you which code your product needs. We are not the right people to sign off on licence compliance.

White-label: buying time to market

White-label infrastructure is the route where a provider has already built, audited and run the contracts, backend, indexer and often the frontend. You get a deployment under your brand with your parameters: supported tokens, fee split, chain, UI, sometimes custom features on top.

When it fits:

• Your edge is distribution, community or a specific market, not the exchange or lending mechanism itself.
• You need to launch in weeks, for example to catch a new chain's early liquidity.
• You do not have, and do not want to hire, a smart contract security team.

What to check before you sign:

• Upgrade keys and admin rights. Who can change contracts or parameters after launch? Can the provider pause or upgrade your deployment without you? Ideally admin rights move to your multisig at launch.
• Audit coverage. Which audits cover the exact version you will deploy, and when were they done? A two-year-old audit of an earlier version does not count.
• Track record. Has the same code run on mainnet with real volume? Ask for contract addresses and check the history yourself.
• Custody. Users should keep custody. No admin function should be able to move user funds.
• Exit terms. What happens if you part ways? You want the deployed contracts, frontend code or at least a migration path, and clear IP terms.
• Pricing model. Upfront fee, revenue share, or both. A revenue share that looks small at launch matters more at scale.

The honest downside: you build on someone else's roadmap. If the provider does not support the pool type, chain or feature you need next year, you wait or you rebuild.

Our own white-label offer comes out of Hyperbloom, the DEX aggregator and yield platform we built on HyperEVM. It has processed more than $300M in total volume, routes across 12 exchanges, and vaults audited by Pashov. We point to it because it is code that has handled real volume, which is the bar you should hold any white-label provider to.

Custom: when the mechanism is the product

Build custom when the thing that makes you different lives in the contracts. Examples: a new AMM curve, a lending market for an asset class nobody supports, a novel liquidation mechanism, a chain where none of the existing code runs, or a non-EVM environment.

Custom costs the most and takes the longest. You also own every line of security. On the plus side, there is no licence risk from third-party code, no revenue share, and nothing stops you from changing direction.

Many good products are hybrids: a fork or white-label core with custom contracts on top, such as a Uniswap v4 hook, a routing layer, a vault strategy or a points system. That keeps the audited core untouched and limits new code to the part that differentiates you. If you go this way, treat the custom layer as fully new code for audit purposes. See our smart contract security ROI post for how to size the audit budget.

A decision sequence

Work through these in order and stop at the first clear answer:

1. Is your differentiation in the mechanism? If yes, build custom, or custom on top of an open core.
2. Do you need mainnet in under two months? If yes, white-label, unless the providers you can find fail the checks above.
3. Is there open-licensed code that does what you need? If yes, a fork with an audit of your diff is often the best value.
4. Is the best code under BUSL? Check whether a grant is realistic for you and how long it takes. If not, compare waiting for the Change Date with building on an older open version.
5. Do you have in-house security capacity? If not, forking and custom both carry more risk than they appear to, and white-label or a studio partnership closes that gap.

For the exchange side specifically, our crypto exchange MVP guide and DEX aggregator guide go deeper on scope.

FAQ

What is a white label DEX?

A white label DEX is a decentralized exchange built and audited by a provider, deployed under your brand with your fees, tokens and chain settings. You run the business; the provider supplies and often maintains the core contracts and infrastructure.

Is it legal to fork Uniswap?

Uniswap v2 is GPL-3.0 and v3's business source licence expired in April 2023, so forking those versions is allowed under their open licences. Uniswap v4 is under BUSL 1.1 until June 15, 2027 or an earlier date set by governance, so production use needs an Additional Use Grant.

What does BUSL mean for DeFi forks?

Business Source License code can be read, copied and modified, but production use is restricted until the Change Date unless the licensor grants an exception. After the Change Date the code converts to the named open licence.

How long does it take to launch a white label DEX?

By our planning estimates, 2 to 8 weeks for a white-label deployment on a supported chain, depending on custom features and frontend changes. A fork usually takes longer because you own the audit and deployment work.

Is a forked DeFi protocol safe if the original was audited?

Not automatically. The original audit does not cover your changes, configuration or deployment steps. Several Compound v2 forks were exploited through issues that only became dangerous under the fork's own setup.

Get a second opinion

If you are weighing a white-label launch against a fork or a custom build, we can review the options for your chain and product and tell you which one we would pick and why. Contact 23studio or read more about our DeFi product development.