限價單成交價理想，手續費又如何？

A limit order. You bought at exactly the price you specified, or even a little cheaper. So far, so good. But there is another line worth checking: what did the exchange charge for that fill?

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.