Crypto funding settlement currency

Crypto funding settles in the asset specified by the perpetual contract and confirmed by the account ledger, which may be USDT, USDC or an underlying coin such as BTC. Keep the signed amount in that native asset before converting it into a reporting currency. A USD-equivalent display does not prove dollars moved, and changing the conversion price can change the reported value without changing the funding payment.

The practical problem appears when several contracts feed one report. Adding a BTC receipt to a USDT receipt produces no meaningful total until both are valued in a common unit. Replacing the original amounts with that total loses the information needed to reconcile balances.

This educational guide was prepared with AI assistance from official venue documentation reviewed on 23 October 2026. Its original worksheet separates booked funding, reporting conversion and later valuation. All prices and amounts in the worked example are hypothetical.

Identify the settlement asset before the dollar value

Read the exact instrument specification, including product and account context. Quote currency, collateral asset and funding settlement asset describe different roles. An account holding several collateral assets does not make every contract's funding payable in whichever asset is convenient.

Bybit's documented examples show funding in USDT for USDT perpetuals, USDC for USDC perpetuals and BTC for its BTCUSD inverse perpetual example. The inverse calculation values the contract quantity in coin before applying the rate. These are product examples, not a universal interpretation of ticker names. Bybit's funding calculation by contract type provides the underlying mechanics.

Its instrument API separately exposes baseCoin, quoteCoin and settleCoin. Preserve those fields with the native symbol rather than deriving the settlement asset from a label. Bybit's instrument specification fields support that distinction.

For the price-sensitivity formulas, use the existing linear versus inverse contract comparison. The task here begins with the native funding amount and asks how to retain and report it correctly.

A fee-token preference for trading commissions does not establish the funding asset. The trading-fee currency worksheet addresses execution commission and net spot inventory; preserve those charges as a different event class.

Preserve two records for every conversion

Keep a native record and an attached valuation record. The native record answers what the venue credited or debited. The valuation record answers what that cash flow was worth under a stated reporting convention.

For a simple reporting translation, multiply the signed native amount by the reporting-currency price of one native unit. Write the price direction explicitly: USD per BTC, rather than a bare BTC/USD label that a spreadsheet might interpret inconsistently.

Choose and disclose a reproducible convention, such as an identified event-time spot reference. Keep it separate from the mark used to calculate the contract's funding amount. Those prices can serve different purposes and need not match. If the reference is missing, mark the valuation unresolved instead of silently inserting the latest price.

Actual asset conversion is a separate event. Exchanging a BTC receipt into USDT changes balances and can involve execution costs. Merely displaying its USD value changes no balance. Keep the actual conversion fill if one occurred; a reporting exchange rate is not evidence of a trade.

A three-currency funding worksheet

Assume three invented, reconciled funding entries from separate perpetual positions. Positive amounts mean receipts; negative amounts mean payments. Eligibility and native amounts are accepted inputs here, and trading P&L, commission and transfers are excluded. The rates below are reporting valuations, not funding rates or live market quotes.

The calculation is 0.0002 × 60,000 + 2 × 0.999 − 1 × 1.001 = 12.997 USD. A two-decimal display shows a net funding receipt worth $13.00 under this convention. It does not mean the account received 13 dollars or 13 USDT.

The native changes remain +0.0002 BTC, +2 USDT and −1 USDC. Reconcile each against its own asset ledger. A tempting sum of 0.0002 + 2 − 1 = 1.0002 mixes incompatible units and has no useful currency meaning.

Now suppose a report instead translates the same signed entries at later prices: 66,000 USD per BTC, 0.997 per USDT and 1.000 per USDC.

The exchange did not pay another 1.197 USD of funding. The difference comes entirely from changing the translation prices. Do not overwrite the event-time funding total with the later-price total while keeping the same metric label.

Nor is this table a complete asset-revaluation profit calculation. It restates signed cash flows, including a payment. To calculate the account's subsequent holding result, trace which assets actually remained, were spent or were converted. A BTC receipt immediately sold cannot keep earning BTC price changes in the holdings ledger.

Match the field, not the whole balance movement

A settlement row can contain more than funding. Bybit's Unified Account transaction log exposes currency and a separate funding amount, with positive funding meaning received and negative meaning paid. It documents the balance-change relationship as change = cashFlow + funding − fee. For USDC perpetuals, funding and session settlement can share one record; cashFlow identifies the session P&L component. Bybit's transaction-log definitions explain these fields.

For a hypothetical row with +20 USDC of session P&L, −1 USDC funding and zero trading fee, the balance increases by 19 USDC. Recording all 19 as funding would overstate the receipt and reverse the explanation of the actual funding payment.

Binance COIN-M income history likewise distinguishes FUNDING_FEE from commission and realized P&L, and returns the income amount with its asset, timestamp and transaction identity. Use the applicable record type and original units when importing. Binance's COIN-M income-history reference documents that venue's schema; do not copy another API's sign convention without checking it.

Resolve the cash question before the report total

A received asset is not automatically available for another commitment. Other orders or account rules can restrict usable resources. The conditional-order fund reservation guide explains why a balance and a spendable amount need separate checks.

Likewise, a negative balance or conversion elsewhere in the account should not be relabeled funding merely because it followed a funding event. If borrowing is involved, retain the debt and interest records separately; the spot margin borrowing versus funding comparison explains that boundary. A USD reporting total cannot establish which asset is available to meet an obligation.

Before closing a reconciliation, verify each native subtotal, all relevant records and the conversion convention. Keep unexplained differences visible. If the question concerns who held a position at the event, use the funding timestamp evidence guide. If it concerns future rate estimates, use predicted versus realized funding.

A useful funding report lets the reader recover both the original asset changes and the valuation applied to them. Its total should remain explainable even after prices move.