Reading a public API does not generate revenue by itself. Revenue comes from flow, capital, or services. This page models the two cleanest flow-based models: builder codes and referrals.
Builder economics / monthly estimate
Builder revenue uses the selected venue cap. Referral revenue assumes the standard 10% referral share. This is a gross estimate before infrastructure, support, and compliance costs.
Builder
$7,500
/ month
Referral
$2,000
/ month
Total
$9,500
$114,000 / year
- Effective fee
- 0.03%
- Volume
- $25,000,000
- Referral share
- 10%
Where the money comes from
| Model | Revenue source | Capital required | Main risk |
|---|---|---|---|
| Builder code | A fee on fills routed through your app | Low | Users must approve the fee; competition |
| Referral | 10% of referred users' fees | None | Volume cap; users must use your code |
| Market making | Spread + maker rebates | High | Inventory and adverse selection |
| Vault | Profit share | Medium | Drawdown and counterparty risk |
| Data / analytics | Subscription or API access | Low–medium | Data licensing and differentiation |
| Execution SaaS | Setup or bps fee | Medium | Integration and support load |
| Arbitrage | Price/funding dislocations | High | Latency and competition |
Gross estimates only
The calculator does not include infrastructure, support, chargebacks, compliance, legal, or taxes. It is not a forecast or a guarantee of revenue.
Builder codes
Hyperliquid builder codes let an application attach a fee to fills it sends on behalf of a user.
| Rule | Value |
|---|---|
| Perps fee cap | 0.1% (10 bps) |
| Spot fee cap | 1% (100 bps) |
| Fee unit | Tenths of a basis point; 10 = 1 bp |
| User approval | ApproveBuilderFee, signed by the user's main wallet |
| Builder requirement | ≥ 100 USDC in the perps account, standard account mode |
| Active approvals | Maximum 10 per user |
| Fee claim | Through the referral reward claim process |
Example order payload:
{
"type": "order",
"orders": [
{
"asset": 0,
"isBuy": true,
"limitPx": "74363.0",
"sz": "0.01",
"reduceOnly": false,
"tif": "Gtc"
}
],
"builder": { "b": "0xBuilderAddress", "f": 10 }
}The user must see the builder fee before signing. A hidden or misleading fee is a trust and compliance problem, not a growth tactic.
Referrals
| Rule | Value |
|---|---|
| Referrer share | 10% of referred users' fees, less discounts |
| Volume cap | Referred users' first $1B in volume |
| Referee discount | 4% for the first $25M in volume |
| Eligibility | Referral code requires $10k in volume |
Referral rewards are paid in the quote asset and can be claimed once above $1.
Reality check
- Volume is the hard part. A calculator is not distribution. You need a product, trust, and a reason for users to route through you.
- Fees are competitive. A builder fee that is too high loses flow; too low may not cover support.
- Referral rewards are capped. Do not model infinite referral income.
- Market making is not passive. It needs capital, risk limits, and infrastructure.
- Regulation applies. A derivatives frontend can trigger licensing, KYC/AML, marketing, and geo-blocking obligations. See the compliance checklist.
- Check the venue's terms. API usage, data redistribution, and builder-code rules can change.