DEV Community: Jack Chen

The payout math of running a trading community (a 3-variable model)

Jack Chen — Tue, 07 Jul 2026 00:52:19 +0000

Most people who run a trading group, a signals channel, or a bot community have never modeled what that audience is worth in fee flow. Not token-hype worth — boring, recurring, fee-flow worth. It's a three-variable problem, so let's model it.

The three numbers that matter

Every major exchange pays partners out of the same pool: the trading fees their introduced users generate. Which means your channel's monthly value is just:

Active traders you actually send (not subscribers — people who trade)
Volume per trader per month, in USD
Effective fee rate, in basis points (perps taker is the workhorse here)

Multiply, then apply whatever split the program gives you.

def monthly_payout(traders: int, vol_usd: float, fee_bps: float, split: float) -> float:
    fees = traders * vol_usd * fee_bps / 10_000
    return fees * split

# a 50-person bot community, $200k/mo each, 2 bps taker, 35% split
print(monthly_payout(50, 200_000, 2.0, 0.35))   # -> 700.0 USD / month

Why the naive estimate is usually wrong

Three corrections that move the answer by 2–5x in practice:

Bots trade more than humans. A grid or DCA bot at $200k/mo is a small bot. Communities built around automated strategies routinely average 5–10x the volume of discretionary-trader communities of the same size. If your 50 people run bots, the example above is closer to $3,500–$7,000/mo.

Fee tiers cut both ways. High-volume users climb VIP tiers, and their taker fee drops (say 5 bps → 2 bps). Your payout pool shrinks with it. Model the blended rate of your actual audience, not the headline rate.

The split itself is tiered. This is the part almost nobody prices in: the public self-serve rate and the negotiated partner tiers can differ by 10–20 percentage points for exactly the same audience. On a $10k/yr fee pool, that difference is rent money.

Sensitivity, quick and dirty

Traders	Vol/mo each	Blended bps	Split 20%	Split 35%
20	$100k	2.5	$100	$175
50	$200k	2.0	$400	$700
50	$1M (bots)	1.8	$1,800	$3,150
200	$500k	2.0	$4,000	$7,000

The lesson from the table: the split tier you land matters more than adding 30% more users. Negotiating (or qualifying into) a higher tier is the highest-leverage move available to a channel owner, and it costs nothing.

I wrote up a tier-by-tier breakdown of one major exchange's partner program — thresholds, what's negotiable, and the exact payout mechanics — here: OKX partner-tier breakdown, with numbers.

And the raw fee schedules I used (maker/taker per VIP tier, per exchange, as JSON) are open-sourced in this repo: crypto-exchange-fee-data — PRs welcome if a schedule drifts.

Not financial advice. Numbers current as of July 2026 — always check the exchange's live schedule before modeling anything on top of it.

I open-sourced every Binance and OKX 2026 fee tier as JSON (+ a calculator)

Jack Chen — Wed, 17 Jun 2026 07:36:15 +0000

If you've ever written a backtest or a fee-aware order router for Binance or OKX, you've hit this wall: the exchanges publish their fee schedules as HTML tables that change without notice, and there's no clean machine-readable source. So you end up hardcoding 0.0004 somewhere and forgetting about it until your live PnL doesn't match your sim.

I got tired of that, so I open-sourced the whole thing.

The repo

github.com/jack0752168/crypto-exchange-fee-data (MIT)

Every VIP tier for Binance (spot + USD-M futures) and OKX (futures), maker/taker, as JSON — plus the qualification rules and a small CLI calculator. No dependencies, stdlib only.

{
  "tier": "VIP 2",
  "futures_vol_min_usd": 75000000,
  "maker": 0.0140,
  "taker": 0.0350
}

Rates are in percent (so 0.0140 means 0.014%, i.e. 1.4 bps), which is the unit the exchanges themselves print. Pick whichever convention you want, just be consistent — mixing percent and fraction is the #1 fee bug I see.

The part most people get wrong

Your real per-trade cost isn't one number. It's a stack:

effective_fee = base_rate(VIP tier) x token_discount x (1 - rebate_share)

Three independent levers:

VIP tier sets the base rate. On Binance it's gated on 30-day volume plus a BNB-balance floor, recalculated daily at 00:00 UTC on a rolling window — so your tier can silently drop overnight. On OKX it's the better of 30-day volume or assets held, which means a high-balance/low-frequency account can sit at a tier it would never reach on volume alone.
Token discount — paying fees in BNB knocks 25% off spot / 10% off futures. OKB is woven into OKX's tier qualification instead of a flat toggle.
Rebate — an affiliate/sub-broker partner can pass back a slice of the fee. This one is multiplicative on top of the other two and most people leave it on the table.

The calculator models all three:

python3 calculator.py --exchange binance --market futures \
    --volume 10_000_000 --maker-share 0.7 --rebate 0.4

Binance futures — tier Regular (maker 0.02% / taker 0.05%)
Blended rate: 0.0290%
Gross monthly fee on $10,000,000: $2,900.00
After 40% rebate: $1,740.00  (rebate back: $1,160.00)

A worked detail that surprises people: at $10M/month futures, Binance is still Regular tier (its futures gate is $15M) while OKX already auto-qualifies VIP 2 ($10M gate). Same volume, different base rate — your fee model has to branch per-exchange, not share one tier table.

Why I care about this number

I run JackTrader, an independent fee-rebate channel for Binance and OKX (not affiliated with either — I'm a sub-broker partner). The repo is the same data I use to reconcile rebate statements, so it's in my interest to keep it accurate. If you want the deep-dive write-ups, the tier mechanics are here:

Contributions welcome

If you spot a stale rate — exchanges revise these a few times a year — open a PR against the JSON and I'll merge it. The whole point is one source of truth the community can keep current instead of everyone hardcoding their own.

Star the repo if it saves you a fee bug: github.com/jack0752168/crypto-exchange-fee-data

Disclaimer: fee schedules change; always confirm against the exchange's own page before trading. "Up to 40%" rebate is a maximum reference, not a guarantee, and depends on platform policy and account status. Nothing here is investment advice.

The Fee Assumption Quietly Wrong in Most Backtests

Jack Chen — Mon, 15 Jun 2026 04:02:57 +0000

If you've written a crypto backtester, there's a decent chance one line in it is quietly wrong. It's not the slippage model, not the funding rate, not the fill logic. It's the fee.

I've reviewed a lot of grid-bot and market-making backtests over the past couple of years, and the fee handling falls into three buckets, roughly in order of how common they are:

fee = 0.0              # "I'll add fees later" (you won't)
fee = 0.001            # 0.1%, the spot default everyone copies
fee = taker_rate       # better, but still missing two layers

For a low-frequency swing strategy, getting the fee wrong by a few basis points is noise. For anything that churns — grids, scalpers, MM, anything with a high turnover ratio — the fee assumption is one of the largest single error terms in the whole backtest. And it's wrong in a direction that flatters your results, which is the worst kind of wrong.

Let me break down the four things a realistic fee model needs, then show what happens to net PnL when you actually wire them in.

1. Maker/taker asymmetry is not a rounding error

The 0.1% default comes from Binance spot, where maker and taker are symmetric at the Regular tier. But most bot volume lives in USDT-M perpetual futures, where the schedule is asymmetric. Per Binance's official fee schedule, USDT-M futures at the Regular tier are roughly:

Maker: 0.02%
Taker: 0.05%

That's a 2.5x difference between the two. If your grid uses post-only limit orders for entries and exits (as most well-built grids do), you're paying the maker rate on the bulk of your fills — which means a backtest hardcoded at 0.1% is overcharging you by 5x, and a backtest hardcoded at the taker rate is overcharging you by 2.5x.

Either way, the point stands: a single fee constant cannot represent reality. You need to model your maker share — the fraction of fills that rest on the book versus cross the spread:

def blended_rate(maker_rate, taker_rate, maker_share):
    return maker_rate * maker_share + taker_rate * (1 - maker_share)

# A tight grid running post-only exits, ~90% maker:
blended_rate(0.0002, 0.0005, 0.90)   # -> 0.000230  (2.3 bps)

Your maker share is a real, measurable property of your strategy. Pull it from your fill logs. Don't guess it, and definitely don't assume 100% — even post-only grids eat taker fills when the market gaps through a level.

2. The BNB / token discount

If you pay fees in BNB on Binance, futures fees drop by a further 10% (spot gets 25%), per the exchange's official schedule. OKX has an equivalent mechanic. This is a flat multiplier on the blended rate:

def after_token_discount(rate, discount=0.10):
    return rate * (1 - discount)

Small, but it stacks, and stacking is the whole game here.

3. VIP tiers — model the tier you're actually in

Exchange fee schedules step down as 30-day volume climbs. The trap in backtesting is assuming the VIP-9 maker rate while testing a strategy that will never do VIP-9 volume. Model the tier your live volume actually qualifies for. If you're a $20M/month desk, that's roughly VIP 1 territory on Binance futures — meaningful, but not the rebate-on-fills fantasy of the top tiers. Be honest about where you sit.

4. The rebate layer almost nobody models

This is the one that's genuinely absent from most backtests, because most devs don't know it exists. A meaningful slice of the fee you pay can come back to you as a rebate.

Exchanges run affiliate / sub-broker programs that pay a share of the fees your account generates. If your account is bound to such a channel, you get a slice back — single-level referral, paid on your own trading volume, typically settled weekly. The headline figure is up to 40% of the affiliate's fee share (the exact number depends on the exchange's official schedule, your account status, review, and your jurisdiction — it's a maximum reference, not a guaranteed return).

The key insight for a quant: this is not a marketing perk, it's a term in your cost function. It applies after the discount, on the fees you've already paid:

def effective_fee(notional, blended, token_discount, rebate):
    gross = notional * blended
    after_discount = gross * (1 - token_discount)
    net = after_discount * (1 - rebate)
    return net

# $20M monthly notional, 90% maker, BNB discount, up to 40% rebate
effective_fee(20_000_000, 0.000230, 0.10, 0.40)   # -> $2,484
# vs the naive 0.1% model on the same notional:
20_000_000 * 0.001                                # -> $20,000

The naive model says you'll pay $20k/month in fees. The realistic model says ~$2.5k. That's not a tweak — it's an 8x difference in your single largest controllable cost. A strategy that looks marginal at 0.1% can be solidly profitable once you model the fee correctly; conversely, a strategy that looks great at 0-fee can be dead on arrival.

Worked example: a 5-bot grid desk

Take a desk running five grid bots at $20M combined monthly notional, split $16M maker / $4M taker. Working it through the official Binance futures schedule:

Layer	Monthly cost
Gross fees (0.02% / 0.05% blended)	~$5,200
After BNB discount (−10% futures)	~$4,680
After rebate (up to 40% back, weekly)	~$2,808 net

Roughly $1,872/month recovered that a naive backtest would have silently expensed — about $22k/year. On a strategy whose edge might be a few hundred bps annually on deployed capital, that rebate layer can be the difference between green and red. The full grid-specific breakdown, including how maker-share optimization interacts with VIP tiers, is laid out here: grid-bot fee optimization.

The practical takeaway

Replace your fee constant with an effective-fee function:

effective = blended_rate(m, t, maker_share) \
            * (1 - token_discount) \
            * (1 - rebate)

Then sanity-check it against your real account: pull a month of fills, sum what you actually paid net of any rebate, and reconcile it against what your model predicts. If they don't match, your backtest's PnL is fiction at the margin — and for a high-turnover strategy, the margin is the whole business.

Two honest caveats. First, rebate eligibility and exact rates depend on the exchange's official program, account review, and your local regulations and KYC — model it as "up to," never as a guaranteed number. Worth noting the channels are single-level referral on your own volume, not anything multi-tier. Second, none of this is investment advice; it's cost modeling. A correctly modeled fee can turn a losing strategy profitable on paper, but it doesn't change the strategy's actual edge — it just stops you from lying to yourself about your costs. If you want the mechanics of how the rebate is structured and settled, the reference I used is here: OKX rebate / sub-broker.

Model your real effective fee. It's the cheapest alpha in your stack — you're already paying for it.

Grid Bot Fees Are Quietly Eating Your Returns: The Quant Fee Checklist

Jack Chen — Wed, 10 Jun 2026 10:20:34 +0000

If you run a grid bot or any automated strategy, you've optimized the spacing, the range, the rebalance logic. But the fee side often goes unexamined — and on a high-churn bot it can quietly eat 20-30% of your gross returns. Here's the checklist I use.

1. Know your effective fee, not the headline

The exchange shows 0.02% maker / 0.05% taker on futures. Your real cost is the blend:

effective_fee = maker_share * maker_fee + (1 - maker_share) * taker_fee

Most bot operators assume they're mostly maker. Verify it. If your grid uses post-only orders you should be 90%+ maker. If you cross the spread to guarantee fills, you're paying taker on those, and it adds up fast.

2. Three levers that cut the effective fee

Maker share — switch limit orders to post-only (rejected if it would take, so you never accidentally pay taker).
VIP tier — your 30-day volume already discounts your base fee; concentrate volume on one venue to climb faster.
Fee rebate — a referral / sub-broker channel passes back a percentage of the fee you pay. It stacks on top of the VIP tier and token discount (BNB / OKB); it does not replace them.

3. The rebate is the most-overlooked lever

The standard referral code caps the rebate at ~20%. A sub-broker channel pushes it toward 40%. For a bot doing $5M/month that's a few hundred dollars a month back — pure margin, no strategy change.

Full grid-bot fee math (worked examples for $5M / $20M / $50M desks, Binance vs OKX vs perp DEX): https://www.jacktrader.xyz/en/blog/grid-bot-fee-optimization.html

Free calculator for the effective-fee math on both exchanges: https://www.jacktrader.xyz/en/

Up to 40% is a maximum, not guaranteed. Independent referral / sub-broker partner, not affiliated with Binance or OKX. Not financial advice.