You can get a good price and still pay the taker fee. There is no contradiction.

I develop software for automated trading. In the comments on my previous article, a reader corrected our explanation: a fill better than the limit can mean that the order took an offer already resting in the book. I agreed. Then I wanted to check the next question: what if the fill is not better, but exactly at the limit? How often do we still pay as takers?

For a bot, this is more than a terminology issue. It buys and sells repeatedly. Get the fee assumption wrong in a backtest, and the same mistake is repeated with every trade.

I Got My Price. Why Am I the Taker?

Suppose I am willing to buy at no more than 100. A seller is already offering 99 in the order book, the list of other participants' orders. My limit order buys from that seller at 99.

The price is fine: I was willing to pay up to 100 and got 99. But I did not post an order and wait for someone to trade against it. I traded against someone who was already there. That makes me the taker in this fill. The maker was the participant whose offer was waiting for me.

Now replace 99 with 100. The seller is already offering 100, and I buy at 100. The fill matches my limit, but my role has not changed. I am still taking an existing offer.

The limit says, "Don't pay more than this." It does not say, "Charge me the lower fee."

Instead of Debating the Terms, Check the Records

I took two exports from live accounts running our bots: Bybit perpetual futures, from August 29 to the morning of October 25, 2026, in UTC. Not demo trades or a backtest.

They contain 6,237 individual trade executions. Of these, 327 came from market orders and 5,910 from limit orders. The latter are what matters here. One order could fill in several parts, so we are counting fills, not orders.

The sources differ slightly. In the first, the exchange records each fill's role with the isMaker field. The second is a spreadsheet export without that flag, so I classified fills by their fee rate. Only two rates appeared: the account's 0.036% maker rate and 0.1% taker rate. That is a fee-based classification, not an explicit exchange flag. On the first account I also checked the fee rate against the exchange flag: there were no mismatches.

For a buy, a price below the limit was better; for a sell, a price above it was better. I compared against the order price in the exchange record, not an assumed market quote.

All 1,218 fills better than the limit were classified as taker under these two methods. But here is the row I wanted to investigate: of the 4,692 fills exactly at the limit, 3,435 were taker fills. Roughly three out of four.

The accounts show a similar pattern separately: 72.57% on the first, using the exchange's explicit flag, and 73.88% on the second, using fee-rate classification.

That is not a proportion for bots in general. It is what we found on two accounts over this period. The exports do not explain exactly how the bots produced that mix: they contain no order-book snapshot from when an order was submitted.

Now for the Money

To calculate the average fee, I added the trading fees paid and divided by the total traded value of purchases and sales in USDT. Not by the deposit or the number of trades: a small fill should not carry the same weight as a large one.

There is real money behind those small percentages. The exchange charged 483.56 USDT for the two accounts' limit-order fills. Apply the 0.036% maker rate to exactly the same turnover and the bill would be 219.85 USDT. The difference is 263.71 USDT.

This is why the check matters. Seeing Limit in a bot's settings is not enough reason to put the maker rate into a backtest. Otherwise, the savings exist only on paper.

This compares fees on fills that already happened. It is not a loss of account capital or the result of another backtest. A different order-placement method could also change which trades happened.

Our earlier backtests used 0.06%, not 0.036%. The maker-only assumption here is a hypothetical example. Those rates also apply to the accounts examined; another account's rates need to be checked separately.

Why Not Just Rule Out Taker Fills?

That is what Post-Only is for. On Bybit, such an order is cancelled if it would immediately take an existing offer when placed. It does not become a cheaper filled order: instead of a purchase, you may get a cancellation.

Trying again requires another order. Meanwhile, the market may move away. So "turn on Post-Only and keep the same trades at lower fees" is still a claim to test. The comparison needs prices, partial fills and trades that never happened, not just the fee rate.

I did not test that change here. We counted how the existing orders filled, rather than establishing that they should be placed differently.

You can check your own account without another backtest: take the execution export, check the roles and rates, add the trading fees and divide by the total traded value. Choosing between ordinary limit orders and Post-Only takes a separate test.

A good fill price is still a good fill price. Execution just has two separate characteristics: the price you got and what the exchange charged. One does not tell you the other.

The limit order did its job: it capped the price. It never promised the maker fee.

Method note: funding, the separate payments associated with holding perpetual positions, was excluded. The exports do not reconstruct order-revision history or time spent in the queue. No fills worse than the recorded limit were found; that is a consistency check, not evidence of zero slippage relative to the market. Bybit documents isMaker in its execution-history reference and Post-Only in its help centre.

Prepared with AI assistance; all figures checked against exchange records.

Originally published on DEV Community.

That looks like a small difference. But fees apply to every fill, and a bot can generate a lot of them. I wanted to answer two questions: where did the different rate come from, and how much would it change one backtest?

What the account actually paid

I took a Bybit crypto futures execution export covering August 29 to October 25, 2026. It contained 3,204 trade executions. Those are fills, not completed trades: a single order can fill in several parts.

The executed notional was about 323,731.67 USDT. Trading fees totalled about 259.44 USDT.

To calculate the average rate, I divided the fees paid by the executed notional:

259.44 / 323,731.67 × 100% ≈ 0.0801%.

Funding payments for holding futures positions were excluded from that calculation. I used the fees charged on exchange executions, rather than adding up selected fee-related fields in the bot's database.

This account had two rates: 0.036% for maker fills and 0.1% for taker fills. Maker executions add liquidity to the order book; taker executions remove it. Roughly 31% of the executed notional was maker and 69% taker. That mix produced the average fee rate.

A limit order does not necessarily pay the maker rate. If it executes immediately against orders already resting in the book, it can be a taker execution.

Unchanged excerpt from my Bybit fee page, English interface, October 26, 2026: futures, standard crypto, Regular User. The average rate below was calculated separately from executions, August 29 – October 25. MNT discount display is off.

One account is not the whole exchange

Bybit says that rates may vary by region and VIP level, and directs users to their own fee page after identity verification. Bybit's fee schedule and explanation.

One more detail. Bybit's fee page shows rates in two places. The "My fee level" card for futures shows 0.036% maker and 0.1% taker for my account — the same rates recorded on the trade executions in the period I checked. But the general fee table in the English interface lists 0.02% and 0.055% for the same "Regular User" tier. It is easy to look at the wrong place, which is why I check my account's rate against executions.

My result does not mean that every customer pays 0.0801%. Another account, with a different fee schedule and execution mix, may pay less.

Freqtrade had not calculated some incorrect global average, either. We had explicitly supplied 0.06%, and it used that value. Custom backtest fees are documented in the Freqtrade manual. The question was whether the assumption matched the account, not whether the software could do the arithmetic.

One strategy, three fee rates

For the experiment, I used one strategy, a starting balance of 2,500 USDT and the same historical dataset with one-minute detail. The window ran from January 1, 2024 to December 31, 2024 at 00:00 UTC. The final day of December was not included.

Only the fee changed between scenarios. The 0.08% rate approximated the measured average for my account. I also tested 0.044% as a lower-cost scenario, not as a claim about the rate paid by everyone else. That is roughly what the same 31/69 split gives under Bybit's base futures table: 0.02% maker and 0.055% taker.

Return here means the test's final profit divided by its starting balance. The USDT column is the difference between final backtest results, not simply the extra fees charged. These percentages describe the stated historical window; they are not a forecast.

I also reran the original 0.06% case to check the baseline itself. All 3,936 trade records matched the old result exactly, including the nested order records.

All bars start at zero. The balance, data and settings were unchanged; only the flat fee changed. These are historical backtest returns, not live-account returns.

For completeness, the engine-reported drawdowns were 10.38%, 11.11% and 10.85%, respectively. That is its max_drawdown_account metric, not a separately reconstructed mark-to-market drawdown including all open positions. I am not using those three figures as a measure of the strategy's full risk.

Why subtracting extra fees was not enough

On a fixed list of fills, changing the fee rate gives a straightforward cost recalculation. But that answers a narrow question: what would those same fills have cost at another rate?

In our reruns, the trade set changed too: one scenario produced 3,790 closed trades and another 4,070.

So, in this experiment, subtracting a different fee bill from the old result would not have reproduced the new run. I did not trace why each individual trade changed here. The summary figures therefore do not establish, for example, that trades all closed later.

What to check in your own test

Start with the fee schedule for your account and instrument. Then check the fees actually charged on executions and compare them with the rate supplied to the backtest. Weight the average by executed notional; do not simply average the maker and taker rates.

If the rates differ, keep two checks separate: repricing the old fill list and rerunning the strategy. They answer different questions.

This experiment has limits. It covers one strategy and one historical window. Each run used a flat fee rather than a maker/taker classification for every simulated fill. The 0.08% scenario therefore does not recreate my account in every detail. It did not test slippage or order-book queue position. The strategy code is private, so readers cannot fully reproduce these particular runs without it.

The practical conclusion is specific: a 0.06% assumption is not automatically wrong because my account pays more, and my account's rate is not universal. What matters is whether the test's assumptions match the conditions of the account.

Prepared with AI assistance; all figures checked against exchange records and backtest outputs.

Originally published on DEV Community on October 26, 2026.

For closed beta participants, machines currently run only in demo mode, so the live-account checks in part 3 don't apply to them yet.

1. We check the amount you chose

You choose how much the machine will trade with. The server checks whether that amount fits the selected model and confirms the amount and the size of the first entry. Until then, the launch doesn't go ahead.

2. The market colour

The page shows the current market state as a colour: normal, heightened caution, unfavourable, or "data is stale". This is advice, not a ban. If the market is unfavourable, you're asked to confirm that you understand the risk before launching.

We call this layer Launch Guard. We explain what it covers, but keep its detailed rules and thresholds private.

3. The API key and the account (live mode)

A live machine trades on your own exchange account through an API key. Before it starts, the page checks six things:

• Withdrawals are disabled on the key. A key that allows withdrawals is refused.
• The balance covers the deposit you chose. If the account holds less, the machine doesn't start.
• The key is bound to an IP address. IP restrictions limit where the key can be used. Without one, you get a warning, not a block.
• The key isn't already used by another machine. In PelagiQuant, one API key can be assigned to one machine at a time.
• No open positions in this machine's coins.
• No open orders in this machine's coins.

Positions or orders in other coins lead to a separate confirmation. The machine won't touch them, but they use the same funds in the account, and you're asked to confirm that you understand this before launching.

Checks first, payment second

The paid version isn't open yet. The planned flow is simple: you choose a model and the capital it will trade with, we run the launch checks, and you review the results and confirm. Only then do we ask for payment.

After payment, we run the checks again. Your subscription period starts when the machine has actually started and the first records of its operation appear in its log. The wait between payment and the confirmed start doesn't count toward your subscription.

If a blocking check fails before payment, we don't issue an invoice. We'd rather wait than charge you for a machine that isn't ready to start.

Your trading capital stays in your own exchange account. You don't transfer it to PelagiQuant. We accept only API keys with withdrawals disabled.

What a passed check means

The checks help find problems before the first order, but they can't tell in advance whether the next trade will be profitable. The market keeps changing after launch, and leveraged futures trading can lose money.

I work on PelagiQuant.