The Fee Assumption Quietly Wrong in Most Backtests

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.