A reproducible trading-fee baseline from official sources

A fee comparison is only reproducible when it records the product, pair, execution role, account tier, residence and observation time. This review uses the public fee documentation of Binance, OKX, Bybit and Bitget as a source ledger dated 28 August 2026. It does not rank the platforms or assume that a public schedule proves regional eligibility, account approval or the exact rate displayed to a particular user.

Define one comparison before reading any rate

Write down the intended market, trading pair, order size, account tier and whether the order is expected to add or remove liquidity. Binance publishes tiered spot and margin rows that depend on factors such as 30-day volume and BNB balance, while other product tabs use different schedules. Comparing a Binance regular-user spot row with another platform's futures or VIP row produces a precise-looking but invalid result.

Use the same residence and legal-account context throughout the comparison. Bybit expressly states that actual rates may vary by region and directs verified users to the account-specific My Fee Rate page. OKX likewise notes that its public explanation may not apply to every customer. These statements make the account display the final checkpoint rather than evidence that can be replaced by a referral page or a cached screenshot.

Separate maker and taker by execution

The order label alone does not determine the fee role. OKX explains that an order is a taker when it fills immediately against liquidity already on the book, while a limit order can still be a taker if it crosses the book at entry. Record the execution shown in the fill history and apply the corresponding account rate; do not assume every limit order receives a maker charge or every partially filled order has one role.

Add costs that sit outside the trading row

The trading percentage is not the complete movement-of-funds cost. Record spread, slippage, conversion charges, funding where relevant, and the fee for the selected withdrawal asset and network. Bitget's official overview states that withdrawal fees depend on the cryptocurrency and network and may fluctuate, so the withdrawal screen must be captured at the time of the planned transfer rather than copied from an earlier comparison.

Record an official-source delta instead of overwriting history

Keep each observation as a dated row containing the official URL, page update date when shown, product, pair, tier, maker and taker labels, account-screen result and reviewer. When a platform changes a schedule, add a new row and describe the changed field. Do not silently replace the old number, because the earlier rate may still explain a historical fill and the new page may apply only to another region or product.

Stop when the evidence cannot be matched

Do not publish a numerical comparison when the legal entity, residence, product, tier or execution role is unknown. A promotional code records attribution only and cannot establish a fee discount, reward, regional access or account approval. If the public documentation conflicts with the authenticated fee page, preserve both observations and ask official support to clarify the applicable scope before using the rate in a decision.

Scenario checkpoint

• Fix the same product, pair, order size, residence and account tier for every comparison.
• Verify maker or taker status from the actual execution rather than the order label.
• Add spread, slippage, conversion, funding and network withdrawal costs where applicable.
• Store every official-source observation as a dated row and preserve later changes as deltas.
• Use the authenticated account display as the final rate check and stop on unresolved conflicts.