DEV Community: Jack Chen

The retention treadmill behind volume-based partner tiers: a 20-line cohort model

Jack Chen — Mon, 27 Jul 2026 03:37:13 +0000

Most exchange partner programs price your tier on recent referred fee output, not on cumulative history. That single design choice turns a static-looking percentage into a control loop with feedback — and it's the part that surprises people who model the program as "get approved once, then collect a slice."

Here's the 20-line model I run before deciding whether a channel is worth building.

Three inputs

Symbol	Meaning	Value used here
`F`	exchange fees one active referred trader generates per month	$800
`c`	fraction of active traders lost per month	0.12
`T`	monthly referred fee output your tier is priced on	$30,000

F = $800 is a retail futures trader doing roughly $2M monthly notional at a ~0.04% blended maker/taker rate. T is your own estimate — exchanges don't publish tier thresholds, which is precisely why you should model the shape instead of chasing a number.

The model

F, CHURN = 800.0, 0.12      # fees per active trader per month, monthly churn

def ramp(new_per_month, months=24):
    active = 0.0
    for m in range(1, months + 1):
        active = active * (1 - CHURN) + new_per_month
        yield m, active, active * F

for m, a, fees in ramp(5):
    if m in (1, 3, 6, 12, 24):
        print(f"month {m:>2}  active {a:5.1f}  output ${fees:9,.0f}")

month  1  active   5.0  output $    4,000
month  3  active  13.3  output $   10,618
month  6  active  22.3  output $   17,853
month 12  active  32.7  output $   26,144
month 24  active  39.7  output $   31,783

Two results fall out of this, and both are counterintuitive if you've been doing the arithmetic in your head.

Steady state is new_per_month / c, not new_per_month × months. Adding 5 active traders a month at 12% churn doesn't build an ever-growing tree. It converges on ~41.7 active traders and ~$33.3k of monthly output. By month 24 you're at $31.8k — 95% of the ceiling. Everything after that is replacement, not growth.

The standing-still cost is T/F × c. Holding $30,000/month of output needs ~37.5 active traders, which means recruiting ~4.5 replacements every month, indefinitely:

churn / mo	active traders needed	new per month to stand still
5%	37.5	1.9
8%	37.5	3.0
12%	37.5	4.5
20%	37.5	7.5
30%	37.5	11.2

The tier isn't an asset you acquire once. It's a subscription you pay in acquisition, and the price is set by your churn rate — a variable most people never measure.

That's the real reason the fee-share layer behaves like an operating business rather than a link you paste. If you want the application steps, the ongoing volume and headcount gates, and the case where binding into a tree that already cleared those gates beats running the treadmill yourself, I wrote that up at how to become an OKX affiliate. The fee tables I use as model inputs live in crypto-exchange-fee-data.

Where this model is wrong

Three honest failure modes, because a model you can't break isn't a model:

Churn isn't a constant. It's front-loaded — a trader in month 1 is far likelier to quit than a six-month survivor. A single c overstates decay in mature cohorts and understates the month-1 bleed. If you have real data, fit per-cohort survival curves instead.
F is a mean over a very long tail. One high-volume account can carry the whole number while the median contributor sits near zero. That makes the tree fragile in a way the smooth curve above hides: lose the top account and output drops by more than 1/n.
T is unobservable. Tier thresholds are discretionary and mostly undisclosed, and split ranges are advertised as ceilings ("up to"), never guarantees. Treat every dollar figure here as a shape, not a forecast.

Not financial advice. I run an independent, non-official fee-comparison site, so read my framing as interested rather than neutral.

The crossover taker share: why the cheaper fee table is often the more expensive venue

Jack Chen — Fri, 24 Jul 2026 03:34:44 +0000

Every "Exchange A vs Exchange B fees" comparison does the same thing: it puts two maker/taker pairs side by side and declares the smaller maker number the winner. That comparison is only valid for a trader who never sends a market order.

What you actually pay is one blended number:

effective rate = total fees paid / total notional traded

Tier, token discount, fee share — everything else is a lever on that one number. And the blend has a property the fee tables never print: two schedules cross.

Measure it, don't estimate it

If you have your fills, compute it directly instead of trusting the sticker:

def effective_rate(fills, maker, taker):
    """fills: [(notional, is_maker), ...]"""
    fees = sum(n * (maker if m else taker) for n, m in fills)
    volume = sum(n for n, _ in fills)
    return fees / volume

fills = [(50_000, True), (30_000, False), (20_000, False)]
print(f"{effective_rate(fills, 0.0002, 0.0005):.4%}")  # 0.0350%

Where the schedules cross

Two representative standard-tier schedules:

venue	maker	taker
A	0.0200%	0.0500%
B	0.0160%	0.0600%

B has the better maker sticker — 20% lower. Set the two blends equal and solve for taker share t:

A = (0.000200, 0.000500)
B = (0.000160, 0.000600)

blend = lambda s, t: s[0] * (1 - t) + s[1] * t
(mA, kA), (mB, kB) = A, B
t_star = (mA - mB) / ((mA - mB) + (kB - kA))
print(f"{t_star:.2%}")  # 28.57%

taker share	A effective	B effective	cheaper
0%	0.0200%	0.0160%	B
10%	0.0230%	0.0204%	B
28.6%	0.0286%	0.0286%	tie
55%	0.0365%	0.0402%	A
80%	0.0440%	0.0512%	A

Below 28.6% taker, B's better maker rate wins. Above it, A wins and the gap widens fast. At 55% taker on $3,000,000/month: A costs $1,095, B costs $1,206 — $1,332 per year handed over for picking the venue with the "cheaper" fee table.

Why this bites

Your taker share is not what you think it is. Count the is_maker flag in your own fill log rather than your recollection. Stop-markets that trigger, liquidations, and every get-me-filled click are taker fills, and traders who describe themselves as "mostly limit orders" routinely land in the 40–60% band once those are counted. That is on the far side of most crossovers.

Where this breaks

Three honest limits:

t* assumes fixed schedules. Cross a volume tier on either venue and it moves — recompute monthly, not once.
Funding and slippage are excluded, and both are usually larger than the 0.4bp being argued over. A venue that wins on t* can still lose on a thinner book.
If your taker share swings month to month, the cheaper venue swings with it. At that point the fee table isn't the deciding variable at all, and you should optimise order routing instead of venue choice.

The full derivation of the blend, plus the three levers (tier, token discount, fee share) that stack on top of it, is written up at effective fee rate explained. The schedules used above come from a small public repo I keep: crypto-exchange-fee-data.

I run an independent site on this topic and am not affiliated with any exchange. Figures are representative standard-tier examples, not guarantees — check your own tier. Not financial advice.

Same partner tier, 8x the payout: the fee base is what you should model

Jack Chen — Mon, 20 Jul 2026 03:33:56 +0000

Two operators can sit on the exact same partner tier at an exchange and collect payouts that differ by 8x. The percentage is identical. The base it multiplies is not.

This trips up a lot of people who evaluate a partner program by reading the headline number and stopping there. The number is a share of fees actually paid by the traders attributed to you — not a share of their volume, and not a function of how many of them there are.

The base is fees, not volume

Futures fees on the major venues run roughly 0.02% maker / 0.05% taker at entry tier. Spot is flatter, around 0.10% both sides. So the same notional produces wildly different fee dollars depending on how it was traded.

Worked at a 30% futures share:

Trader profile	Monthly notional	Maker share	Blended rate	Fees paid	Your split
Spot swing trader	$250,000	n/a (0.10%)	0.1000%	$250	$75
Futures scalper	$2,000,000	30%	0.0410%	$820	$246
Futures grid bot	$8,000,000	85%	0.0245%	$1,960	$588

The grid bot operator sends 32x the notional of the spot trader and pays only 7.8x the fees — maker-heavy flow is cheap per dollar moved. But it still pays out nearly 8x more, because volume scales faster than the maker discount shrinks the rate.

MAKER, TAKER = 0.0002, 0.0005

def monthly_split(notional, maker_share, share=0.30):
    blended = maker_share * MAKER + (1 - maker_share) * TAKER
    return notional * blended * share

print(round(monthly_split(8_000_000, 0.85), 2))   # 588.0
print(round(monthly_split(2_000_000, 0.30), 2))   # 246.0

Why this changes what you optimize

If you publish content, your growth lever is headcount — more readers, more clicks, more sign-ups. Each one is a small, mostly-spot, high-churn base.

If you run a bot community or a signals group, headcount is almost irrelevant. One member running a grid strategy at $8M monthly notional is worth roughly eight casual spot traders, and they don't churn the same way — an automated strategy keeps trading while its operator is asleep or bored.

So the fee table isn't a marketing detail. It's the thing that tells you which audience to go get. A creator reads the table to estimate income. An operator reads it to decide what kind of member to recruit, and the answer is usually "fewer, with API keys."

Full breakdown of the tier structure and what it resolves to: Binance affiliate commission table. Raw fee schedules I keep versioned here: crypto-exchange-fee-data.

Three caveats worth stating plainly

Headline rates are ceilings, not entitlements. Published tiers are "up to" figures gated on volume and account tests. Assume the entry tier until a backend says otherwise.
Attribution windows are the silent failure mode. A trader who registers through one path and funds weeks later may not bind to you at all. Check the binding rule before you model anything.
Fee tiers move underneath you. As a member climbs VIP levels their own fees drop, which shrinks the base your split multiplies. Growth in member sophistication can flatten your payout curve.

Model the base, not the percentage. The percentage is the easy part and it's the part everyone quotes.

Independent write-up, not affiliated with or endorsed by any exchange. Rates and tier rules change — verify current terms at the source. Not financial advice.

Modeling the pass-through gap: what an exchange's headline partner rate actually resolves to

Jack Chen — Sat, 18 Jul 2026 03:34:20 +0000

If you run a trading community, exchanges court you with one number — a headline "up to X%" of the fees your community's users generate. On paper it reads like a flat cut. In practice, the amount you keep is the output of a small pipeline, and most people never model the stages between the sticker rate and their actual payout.

Here are the three stages that decide your take-home.

Stage 1 — the ceiling is conditional

"Up to 40%" is a maximum, not a rate. It resolves upward only when your team's monthly volume clears higher bands. A partner tree doing $2M notional a month usually sits two bands below the top.

30d team volume (USDT)	Applied fee share
< 5,000,000	~20%
5M – 20M	~30%
20M+	up to the ceiling

Stage 2 — the base the % applies to

The share is taken on net trading fees, after the venue's own maker/taker discounts and any VIP reductions your users already earn. A user on a 0.02% maker tier produces a far smaller fee base than the 0.10% sticker implies. A high headline % on a thin base often pays less than a modest % on a full one.

Stage 3 — timing and clawbacks

Payout lands on the venue's official backend, typically on a daily or rolling settlement, and reverses if a trade is later voided. None of the headline math is contractual — it's a model, not a promise.

A back-of-envelope calculation:

take_home = team_net_fees * applied_share
          = (volume * effective_fee_rate) * band_share

# 10M USDT volume, 0.04% blended net fee, 30% band
= 10_000_000 * 0.0004 * 0.30
= 1,200 USDT / month

Swap in your own numbers and the headline usually lands 30–50% below what a naive reader assumes, because both the band and the fee base pull it down at the same time.

I keep the raw venue fee schedules I use for these models in a public repo — maker/taker tables by tier, updated as exchanges change them: https://github.com/jack0752168/crypto-exchange-fee-data

The full split modeling for OKX's partner-tree structure, and how the bands actually apply, is written up here: https://www.jacktrader.xyz/en/blog/okx-sub-broker-affiliate-program.html

Model your own base before you pick a venue on its headline. Not financial advice.

Modeling the blended fee rate of a mixed-tier trading community

Jack Chen — Mon, 13 Jul 2026 03:34:27 +0000

If you run a trading community — a Discord of grid-bot operators, a signal group, a small prop pod — every member sits at a different exchange fee tier. A few clear enough monthly volume to hit VIP 2 or 3; most sit at Regular. When you try to reason about "what does our group actually pay," a single headline number is useless. What you want is the blended rate: the volume-weighted average fee across everyone.

Here's how I model it.

The inputs

OKX USDT-perp taker fees by tier (published schedule, current after the April 2026 update):

Tier	30-day volume gate	Maker	Taker
Regular	< $5M	0.0200%	0.0500%
VIP 1	≥ $5M	0.0160%	0.0450%
VIP 2	≥ $10M	0.0150%	0.0360%
VIP 3	≥ $50M	0.0100%	0.0280%

Most retail communities are a long tail: a handful of high-volume members and a large base at Regular. The blended rate is dominated by where the volume sits, not by headcount.

The model

# members: (monthly_notional_usd, taker_rate)
members = [
    (2_000_000,  0.0500 / 100),   # Regular
    (2_500_000,  0.0500 / 100),   # Regular
    (6_000_000,  0.0450 / 100),   # VIP 1
    (12_000_000, 0.0360 / 100),   # VIP 2
    (55_000_000, 0.0280 / 100),   # VIP 3
]

total_vol = sum(v for v, _ in members)
# volume-weighted blended rate
blended = sum(v * r for v, r in members) / total_vol
# naive headcount average (the wrong way)
naive = sum(r for _, r in members) / len(members)

print(f"total monthly volume: ${total_vol:,.0f}")
print(f"blended (volume-weighted): {blended * 100:.4f}%")
print(f"naive (headcount avg):     {naive * 100:.4f}%")

Output:

total monthly volume: $77,500,000
blended (volume-weighted): 0.0329%
naive (headcount avg):     0.0418%

The naive average says 0.0418%. The real blended rate is 0.0329% — about 21% lower — because the single VIP 3 member carries most of the volume at the cheapest rate. If you price a group fee split or a community payout off the headcount average, you misjudge the pool by a fifth.

Two levers that move the blend

Migration up the tiers. Moving your Regular base to VIP 1 barely dents the blend — they're small volume. Moving a mid-tier member from VIP 2 to VIP 3 moves it a lot. Effort should follow volume, not headcount.
A flat fee share on paid fees. A partner-tier split applies the same fraction to everyone's paid fee regardless of tier, so it lowers the blended net rate uniformly — often a bigger, more predictable lever for the low-volume majority than chasing a tier they'll never reach.

I keep the underlying tier tables and a few community fee models in a public repo: https://github.com/jack0752168/crypto-exchange-fee-data — pull requests with other venues' schedules are welcome. The full OKX VIP tier breakdown (spot + futures, and the asset-vs-volume qualification rule) is here: https://www.jacktrader.xyz/en/blog/okx-vip-fee-tiers-2026.html

Model your community off the volume-weighted number, not the member count. The distribution is almost always more lopsided than it feels.

Not financial advice — educational modeling only. Fee schedules reflect published rates at time of writing and can change.

Default fee configs in Hummingbot, Freqtrade, and OctoBot are all wrong — differently

Jack Chen — Sat, 11 Jul 2026 03:33:18 +0000

If you run a market-making or grid bot, the single number that decides whether your backtest survives contact with a live account is the fee assumption baked into your config. I pulled the default fee settings out of three popular open-source frameworks and compared them against what the venues actually charge in mid-2026. All three are wrong — but they're wrong in different directions, and that matters.

The defaults, side by side

Framework	Default maker	Default taker	What it assumes
Hummingbot	0.10%	0.10%	Flat symmetric fee, no tier logic
Freqtrade	0.10% (single `fee`)	0.10%	One value applied to both sides
OctoBot	0.10% / 0.10%	reads from ccxt	Pulls venue defaults, ignores your tier

The common failure is symmetry. Every one of these treats maker and taker as equal by default, but a post-only grid on a major venue in 2026 is paying maker rates that can be negative to +0.02%, while taker is closer to 0.04–0.05%. If your bot fills 80% maker, a flat 0.10% assumption overstates cost by roughly 3–5x on the side that dominates your fills.

Why each one bites you differently

Hummingbot hardcodes the symmetric 0.10% in the connector config. It's honest that it's a placeholder, but most people never edit it. Your PnL curve looks conservative — which feels safe until the strategy that "worked" in sim was only profitable because the fake fee drag hid overtrading.
Freqtrade collapses both sides into one fee field. There is no maker/taker split at all, so a maker-heavy strategy is systematically punished and a taker-heavy one flattered. Same number, opposite bias.
OctoBot does the smart thing and reads fees from ccxt — but ccxt returns the public default tier, not your account's actual schedule. If you're on a higher volume tier or a partner-linked account, the real number your account settles at can be materially lower than what the sim used.

A quick sanity check

Before trusting any of them, print the effective rate your bot is actually using per side:

mkt = exchange.market("BTC/USDT")
print("maker:", mkt["maker"], "taker:", mkt["taker"])
# then reconcile against a real settled fill:
# fee_paid / notional  ==  effective_rate

If that ratio doesn't match your config, every equity curve you've drawn is fiction on the fee axis.

What I did about it

I keep a small dataset of the fee schedules I actually settle at per venue and per tier, so the number in the config is the number the account pays, not a framework placeholder. The raw tables are here: https://github.com/jack0752168/crypto-exchange-fee-data — and I wrote up how the maker/taker split and tier attribution actually flow through a bot's PnL here: https://www.jacktrader.xyz/en/blog/hummingbot-fee-rebate.html

The tools aren't wrong to ship a placeholder — they just can't know your tier. That's your job to fill in.

None of this is financial advice; verify current schedules against your own account before trading.

Maker-taker economics for grid bots: when post-only actually pays

Jack Chen — Fri, 10 Jul 2026 03:36:14 +0000

Grid bots don't win by predicting direction — they win on fee bps. Every rung you fill is one leg of a round trip, and a grid that trades 400 times a day turns a 1 bps fee gap into real money. The question isn't "maker or taker" in the abstract; it's whether forcing post-only actually earns its keep once you count the fills you miss by insisting on being a maker.

Here's the trade-off in one line: post-only guarantees the maker rate but rejects any order that would cross the book, so in fast markets some rungs never fill and you lose that grid step. A taker order fills every time but pays the higher rate.

The break-even is easy to model. Let:

m = maker fee (bps)
t = taker fee (bps)
p = probability a post-only rung actually fills before price walks away
g = grid step captured per successful round trip (bps)

A post-only rung's expected value per attempt is p * (g - 2m). A taker rung's is g - 2t (it always fills). Post-only wins when:

def post_only_wins(g, m, t, p):
    ev_maker = p * (g - 2 * m)   # fills with prob p, pays maker both legs
    ev_taker = (g - 2 * t)       # always fills, pays taker both legs
    return ev_maker > ev_taker

# 5 bps grid step, maker 2 bps, taker 5 bps
for p in (0.6, 0.72, 0.9, 1.0):
    print(p, post_only_wins(5, 2, 5, p))
# 0.60 False
# 0.72 True (right at the edge)
# 0.90 True
# 1.00 True

With a 5 bps step and a 2/5 maker-taker split, post-only stops paying off once your fill probability drops below ~0.72. On a tight, liquid pair where post-only fills 90%+ of the time, maker-only is clearly correct. On a thin pair during a move, where half your post-only rungs get rejected, you're better off just taking.

Net cost per round trip (both legs) at a few fee tiers:

maker/taker (bps)	maker round trip	taker round trip	crossover fill-prob (g=5)
2 / 5	4 bps	10 bps	0.72
1 / 4	2 bps	8 bps	0.60
0 / 5	0 bps	10 bps	0.50

The practical takeaway: measure your actual post-only fill rate per pair — most bot frameworks log rejected orders, so count them — plug it in, and stop assuming maker-only is free. It isn't; the hidden cost is the fills you never got.

I keep the raw per-exchange fee tiers I use for this in a public dataset: https://github.com/jack0752168/crypto-exchange-fee-data

A longer write-up on grid fee optimization with worked examples is here: https://www.jacktrader.xyz/en/blog/grid-bot-fee-optimization.html

Not financial advice — just the arithmetic. Your fill rates and fee tiers are yours to measure.

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.