AAlphaBot
← Blog

Why grid bots lose to fees: a fee-aware net PnL deep dive

2026-05-06 · ~7 minute read

A grid bot looks brilliant on paper. You quote both sides of a range, the price oscillates, and every round trip is a small profit. The dashboard shows green almost every hour. Then you reconcile your exchange statement at the end of the month and the number is smaller than the gross figure on the bot UI — sometimes negative, even though the chart never showed a losing day. The gap is fees, and most consumer-grade tools simply do not account for them honestly.

What the gross PnL chart is showing

A typical grid UI plots realised PnL as the sum of (sell price) minus (buy price) across closed grid pairs, multiplied by quantity. That number ignores three things that come straight off your account:

  • Maker and taker trading fees on every leg.
  • Funding payments on the perpetual position you carry between fills.
  • Slippage on the legs that fill aggressively rather than passively.

The fee math, with illustrative numbers

Suppose a grid bot turns over a perpetual contract 200 times per day with 0.02% taker fee and 0.01% maker fee. Even if every leg is a perfect maker fill (it is not), 200 fills at 0.01% per side is 4% of notional in fee drag per day. The bot would need a gross-PnL turnover above 4% of notional just to break even on fees, before funding or slippage. Numbers below are illustrative, not from a live account:

# Illustrative — single trading day, $10,000 notional grid
gross_PnL_realised        = +$84.20    # what the UI shows
maker_fees_paid           =  -$22.00   # 110 maker fills @ 0.01% * 10k * 2 sides
taker_fees_paid           =  -$36.00   # 90 taker fills  @ 0.02% * 10k * 2 sides
funding_paid_received     =   -$6.10   # 3 funding windows
slippage_aggressive_legs  =  -$11.40   # vs displayed top-of-book at decision
--------------------------------------
net_PnL_after_costs       =  +$8.70    # what hits your account

The same grid would have been advertised as a $84/day strategy on a $10,000 notional — an “0.84% daily” figure that looks great on a homepage. The honest figure is roughly one tenth of that.

Why volatility helps the marketing chart but hurts the net

Higher volatility produces more grid round-trips per day, which inflates gross PnL linearly. It also produces more aggressive fills, more funding-rate spikes, and wider effective spreads — all of which scale fee drag faster than the gross gain. The most honest test for any grid strategy is to plot net PnL against realised volatility, not gross PnL against time.

Maker rate is not the same as maker fill rate

Many grids set their orders “post-only” and then quietly cancel-and-resubmit on every tick to stay in the queue. Your post-only setting protects you from a taker fee on the initial entry, but every cancel-and-replace exposes you to the possibility that the next leg fills aggressively to keep the grid balanced — at the taker fee. Reading your own fill report and computing realised maker percentage is the only reliable check.

What an honest grid backtest looks like

A backtest worth trusting must include: per-fill maker/taker classification with realistic queue-position assumptions; tick-by-tick funding accrual; bid-ask slippage on aggressive legs; and a schedule of exchange fee tiers (your tier changes as your volume changes). If a backtest tool does not let you set those inputs, it is producing a marketing chart, not a research artefact.

What we do differently

We treat fees as a first-class input to the strategy itself, not as an afterthought subtracted at the end. The decision to send an order checks the post-fee expected value. If the expected value after fees is below the platform's configured floor, the order is suppressed even when the gross signal is positive. The cost is fewer trades and a less impressive activity dashboard. The benefit is a net PnL number that survives reconciliation against the exchange statement.

The proof page reports both gross and net PnL side by side, with the fee, funding, and slippage components broken out. If those numbers are not visible somewhere on a platform you are evaluating, assume the gap is being hidden, not closed.