Maker and taker fees: a fill-level arithmetic check
By DX Research Group · · Execution mechanics
Calculate mixed maker and taker fees without mistaking an order type for an execution classification.
The execution classification belongs to the fill
We use a mixed-fill example here to make the fee calculation inspectable before it enters an agent evaluator.
An autonomous trading agent can submit one limit order and receive executions with different economic properties. A fee calculation based only on the original order label can therefore produce an incorrect cash ledger. The useful unit of analysis is the execution, together with its quantity, price, fee amount, and fee currency.
Bybit's execution stream exposes execution identifiers, prices, quantities, maker classification, fee rates, and fee currency. Those fields provide a concrete example of the information an adapter can preserve. Fee schedules remain specific to venues and account tiers.
An illustrative mixed execution
Suppose an agent buys ten units of a hypothetical asset. Four units execute at 100 quote units with an illustrative taker rate of 0.10%. Six execute later at 99 with an illustrative maker rate of 0.04%. These numbers are teaching inputs; current exchange rates and DXRG measurements require separate evidence.
The first fill has notional 400 and fee 0.40. The second has notional 594 and fee 0.2376. Total gross spend is 994; total quote-denominated fees are 0.6376; total cash spent is 994.6376. Gross average execution price is 99.4. Including these particular quote fees gives an effective acquisition cost of 99.46376 per unit.
Applying the taker rate to the entire order would produce a 0.994 fee. Applying the maker rate throughout would produce 0.3976. Neither reconstructs the example. Taking a simple average of the two rates also fails because execution notionals differ.
A reusable ledger procedure
Create one durable row per execution identifier. Store the venue, account, instrument, order identifier, side, quantity, execution price, fee amount, fee asset, and source timestamp. Sum quantity and notional independently. Aggregate fees by asset before converting them to a reporting currency.
If the fee is charged in the acquired asset, reduce the received asset balance rather than adding a fictitious quote payment. If it is charged in another token, keep that token's debit separate. A reporting conversion needs its own price source and timestamp; it does not change the original debit. Rebates also need an explicit sign convention, because a negative fee can otherwise become an expense during export.
Reconcile the reconstructed balances with the venue's account records. A discrepancy can reflect rounding, an extra charge, an omitted execution, or an incorrect currency assumption. Investigate the difference against the original receipts.
What this tests in an agent system
A useful offline fixture contains two executions, a duplicate delivery, and fees in two currencies. The expected result is one economic entry per execution and separate currency totals. This checks accounting behavior without making a prediction or performance claim.
Fee treatment also depends on product type, promotions, account tier, and contract denomination. The procedure here assumes a simple spot-like notional calculation. Inverse contracts and option fees require their documented formulas. The engineering contribution is a reproducible arithmetic boundary between an agent's instruction and its economic receipt.
Fit the receipt into the full trace
Our execution and settlement framework connects these mechanics to recorded outcomes. The operating-layer controls paper explains why the machinery around an agent deserves its own evaluation.