Operating multi-venue algorithmic trading strategies requires precise post-trade reconciliation. Each major perpetual venue—Binance, Bybit, and Hyperliquid—formats trade reports, fee assessments, and cash flow ledgers using divergent terminology, idiosyncratic sign conventions, and distinct API data models.

Failing to standardize multi-exchange transaction ledgers results in phantom trading profits, inaccurate tax reporting, and miscalculated strategy return metrics. For foundational principles on keeping auditable trade books, read Crypto Trading P&L Records and download the companion Multi-Venue Perp Execution & PnL Reconciliation Worksheet.

Mapping Divergent Schema to a Universal Trade Record

Every completed derivative transaction must be ingested from raw exchange CSV exports or REST API endpoints into a normalized relational schema:

raw fill schema reconciliation across Hyperliquid, Binance, and BybitThree-to-one schema normalization pipeline translating Hyperliquid userFills, Binance userTrades, and Bybit execution/list fields into a canonical audit record. MULTI-VENUE RAW EXPORT TO CANONICAL LEDGER NORMALIZATION HYPERLIQUID (userFills) tid / cloid → trade_id px / sz → price / qty dir ("B/A") → side crossed → maker/taker fee (USDC) → fee_amount closedPnl → price_pnl BINANCE (userTrades) id / orderId → trade_id price / qty → price / qty side → BUY / SELL maker (bool) → role commission → fee (USDT/BNB) realizedPnl → price_pnl BYBIT (v5 list) execId execPrice/Qty side isMaker execFee PnL in closed-pnl CANONICAL ROW • UTC ISO time • Exact Venue • Price & Qty • Isolated Fee • Gross PnL ✓ Auditable Download the Perpetual Execution & PnL Reconciliation Worksheet to standardize multi-venue exports
Three-to-one schema normalization pipeline translating Hyperliquid userFills, Binance userTrades, and Bybit execution/list fields into a canonical audit record. Illustrative teaching diagram · not live market data

The core mapping divergences across platforms include:

  • Order Identification: Binance uses orderId and client-specified clientOrderId; Bybit utilizes orderId and orderLinkId; Hyperliquid relies on numeric oid and 128-bit hexadecimal cloid.
  • Directional Signs: Binance and Bybit record trade side as explicit strings ("BUY" / "SELL"). Hyperliquid orders specify "B" or "A" (Bid/Ask), where position closures are inferred from account state.
  • Execution Timestamps: Binance reports millisecond epoch timestamps (time), Bybit reports millisecond strings, and Hyperliquid WebSocket feeds provide microsecond-resolution transaction times.
Normalized Fill Record = [Venue, Timestamp_UTC, Symbol, Side, Fill_Price, Fill_Qty, Fee_Paid, Fee_Asset, Role]

Isolating Fee Currencies and Collateral Assets

One of the most frequent accounting pitfalls in derivatives auditing is the conflation of fee payment assets with trade settlement currencies.

fee currency isolation: preventing accidental conversion and rounding errorsFour-bucket accounting diagram showing why fees paid in BNB, USDC, and USDT must be summed in their native asset buckets before timestamped USD valuation. BNB FEE BUCKET −0.4250 BNB Deducted from Spot BNB Mark BNB/USD at fill time Never add to USDT raw! USDC FEE BUCKET −18.50 USDC Hyperliquid / Bybit USDC Includes maker rebates Native L1 settlement USDT FEE BUCKET −42.10 USDT Binance / Bybit Linear Direct margin deduction Isolated USDT ledger UNVERIFIED ROWS Status: UNKNOWN Missing fee asset or rate Do not coerce to $0.00 Flag for manual check Accounting Rule: Sum fees per native asset first, then apply timestamped spot conversion for USD reporting Adding 0.425 BNB + 42.10 USDT as raw numbers ("42.525") corrupts net PnL reconciliation SuperQuant's execution ledger keeps fee assets distinct and flags missing fee currencies
Four-bucket accounting diagram showing why fees paid in BNB, USDC, and USDT must be summed in their native asset buckets before timestamped USD valuation. Illustrative teaching diagram · not live market data
  • Binance: If “Using BNB for Fees” is toggled on, trading fees are deducted from a spot BNB balance at a discount, even while perpetual PnL settles in USDT. Recording the fee without converting the historical BNB spot price to USD creates an uncalibrated cost basis.
  • Bybit: Fees for USDC perpetuals are deducted in USDC, while USDT perps deduct from USDT margin. See Stablecoin Collateral and Margin Risk for how collateral currency affects margin accounting.
  • Hyperliquid: All perpetual contracts settle and deduct fees natively in USDC on the Hyperliquid L1, eliminating cross-currency translation complexity.

To reconcile accurately, always separate cash flow events into two isolated ledgers: the Trade Fill Ledger and the Cash Balance Movement Ledger. You can also estimate expected maker versus taker fee deductions before auditing using the Perpetual Fee & Slippage Drag Calculator and our guide to Maker Rebates and VIP Fee Tiers.

Segregating Funding Payments from Realized Trade PnL

On exchange user interfaces, “Realized PnL” often aggregates pure directional price returns with cumulative funding payments and trading fees. For quantitative evaluation, these components must be strictly disentangled:

segregation of funding settlement rows from trade fill executionsTwo-stream accounting architecture separating order fill executions from periodic funding cash settlements to reconcile exact wallet equity changes. STREAM A · TRADE FILL EXECUTION LEDGER • Event Trigger: Market or Limit Order Match • Records: Fill Price, Fill Qty, Liquidity Role • Cost: Maker / Taker Commission Debit Outputs: Gross Price PnL & Execution Fees STREAM B · FUNDING SETTLEMENT LEDGER • Event Trigger: UTC Clock Snapshot (1h / 8h) • Records: Open Position Size × Oracle Mark • Cash Flow: Settled Funding Rate Debit/Credit Outputs: Net Realized Carry Cash Flow Ending Wallet Balance − Starting Balance = Gross Price PnL − Execution Fees ± Settled Funding If the equation does not balance to $0.00 variance, check for omitted funding rows, BNB fee deductions, or liquidation penalties Keeping streams separate prevents confusing passive carry yield with directional trade timing skill
Two-stream accounting architecture separating order fill executions from periodic funding cash settlements to reconcile exact wallet equity changes. Illustrative teaching diagram · not live market data
Gross Realized PnL = sum((P_exit − P_entry) × Quantity × Side Sign)

Net Account Change = Gross Realized PnL − sum(Trading Fees) + sum(Settled Funding Cash Flows)

By isolating settled funding into a dedicated carry column—using either the Multi-Venue Perp Execution & PnL Reconciliation Worksheet or the Perpetual Funding Rate Settlement Audit Worksheet—a trader can determine whether a strategy’s edge stems from genuine predictive alpha or whether the model is simply a disguised funding carry trade.

Multi-Exchange Ledger Field Cross-Reference

Universal Field Binance USDⓈ-M API Bybit V5 Linear API Hyperliquid Info API
Transaction ID id (trade ID) execId tid (transaction hash/index)
Client Identifier clientOrderId orderLinkId cloid (hex string)
Instrument Symbol symbol (e.g., "BTCUSDT") symbol (e.g., "BTCUSDT") coin (e.g., "BTC")
Liquidity Role maker (boolean) execType ("Maker"/"Taker") crossed (false = Maker, true = Taker)
Fee Deduction commission + commissionAsset execFee + fee token field fee (always settled in USDC)
Funding Record Income API (type: "FUNDING_FEE") Execution API (execType: "Funding") User Funding API (delta.funding)

Disclaimer: API schema field names reflect public API specifications across versions (Binance Futures v1, Bybit v5, Hyperliquid API v1).