How to Calculate Crypto Funding Payments, Step by Step

The first task is to identify what the quantity field counts. A position can be quoted in BTC, in contracts representing a fraction of a coin, or in contracts with a fixed dollar face value. A calculator that accepts “position size” without explaining its unit can give a plausible-looking answer that is wrong by a factor of ten, one hundred or more.

For the linear examples in this guide, quantity is measured in BTC, the valuation price is USDT per BTC and the funding payment is USDT. We use mark-price valuation, as documented for Bybit’s USDT perpetuals. Hyperliquid instead specifies oracle-price valuation. Use the reference named by the contract; choosing whichever price happens to be nearest on screen is not a reliable substitute.

A 0.5 BTC long assessed at 60,000 USDT per BTC has a funding value of 30,000 USDT. At +0.01%, convert the rate to 0.0001, then multiply: 30,000 × 0.0001 = 3 USDT. The long pays, so our cash-flow entry is −3.00 USDT. An equal short receives +3.00 USDT under the same bilateral funding assumptions.

Convert the input once, not twice

A display showing 0.01% needs division by 100 before ordinary multiplication. An API returning 0.0001 as a decimal already represents that rate and should not be divided again. Conversely, entering 0.01 into a decimal-rate field produces a 1% charge, one hundred times too large. Keep the original field label alongside the copied number.

If the position uses contract counts, convert those counts to their economic quantity. For example, twenty contracts worth 0.01 BTC each represent 0.2 BTC, not twenty BTC. At 60,000 and +0.01%, the illustrative payment is 1.20 USDT. The contract multiplier belongs in this conversion; it is not another leverage multiplier.

Leverage is absent from the event formula because the position value already includes the exposure. If 1,000 USDT supports a 20,000 USDT position, use 20,000, then apply the funding rate once. Using only 1,000 understates the charge; multiplying the correct payment by 20 overstates it.

Consider a hypothetical long carried through four discrete assessments. It begins at 0.5 BTC. After the second assessment, 0.3 BTC is closed, leaving 0.2 BTC for the third and fourth. The funding rate changes sign once, and the valuation price changes at every event. All prices and rates below are invented to make the arithmetic inspectable.

The first line is the 3 USDT debit calculated above. The second uses 0.5 × 62,000 × 0.00005 = 1.55 USDT. Because the market rate is negative, the long receives this amount. Do not remove the negative sign from the rate and then classify every line as an expense.

The third line uses the remaining 0.2 BTC, not the original 0.5. Its notional is 12,200 USDT; multiplying by 0.0002 gives a 2.44 USDT debit. At the fourth event the notional is 12,100 USDT and the debit is 1.21 USDT. The position reduction affects later entries only. It does not rewrite payments already assessed.

What changes if you keep the full position?

With 0.5 BTC still open, the third debit becomes 6.10 USDT and the fourth becomes 3.025 USDT. The net funding cash flow would be −10.575 USDT before any account-specific rounding. The smaller total after reducing quantity comes from smaller exposure at those later events, not from a discount on the funding rate.

Switching the demonstration to short reverses each cash flow while keeping the absolute quantities, prices and rates unchanged. The negative-rate event then becomes an expense. This is a useful check on the sign logic: a total that remains a debit for both sides of the same matched example has mixed up payment direction or the record’s sign convention.

The reduction also changes price exposure and can create realized P&L and trading fees. Those belong in a full trade result, but they are not additional funding entries. Keeping this ledger limited to one type of cash flow lets you audit it before combining it with the rest of the account.

A submitted close order and a completed close are different facts. Suppose the 0.3 BTC reduction above fills only 0.1 BTC before the next assessment. The account still holds 0.4 BTC, so the third payment at 61,000 and +0.02% is 4.88 USDT, not 2.44. The order’s original requested size cannot replace the filled position history.

An increase works the same way. If another entry fills before an assessment, add the resulting open quantity for that event. Do not apply the new size retrospectively to the earlier periods. When several fills happen near an assessment, the exchange’s recorded eligible position is the important evidence; a later position-panel screenshot may already reflect another change.

Do not charge the closing order itself a funding percentage

In the discrete-assessment model used here, funding applies to the eligible open position at assessment. The close has its own execution commission. Multiplying the closing order’s value by the funding rate again creates a charge with no corresponding funding event. A platform using continuous accrual requires a time-segment calculation instead; closing can realize an amount already accrued.

For one-way position mode, a sell may reduce a long or carry it through zero into a short. If a 0.5 BTC long is replaced by a 0.1 BTC short before the next event, the next funding calculation needs the short side and 0.1 BTC. It is not enough to preserve the original “long” label while updating a signed quantity.

With independent long and short legs, calculate the eligible legs according to that product’s records. Equal legs may offset their funding economically, but that does not mean there were no transfers or no margin implications. Keep separate entries when the platform reports them separately, then net only the amounts in the same currency.

Now use an invented inverse BTCUSD position with 20,000 USD of total contract face value. Assume the funding valuation price is 50,000 USD per BTC and the final rate is +0.025%. Dividing the dollar face value by the price gives 0.4 BTC. Multiplying by 0.00025 gives 0.0001 BTC of funding.

If the next event uses 40,000 USD per BTC with the same face value and rate, the coin value is 0.5 BTC and the funding amount becomes 0.000125 BTC. Both events correspond to 5 USD at their respective valuation prices, but the number of satoshis transferred differs. Reporting only a dollar total hides that change in the settlement asset.

Two valid dollar totals can answer different questions

Across those two events the long pays 0.000225 BTC. Valuing each payment at its own assessment price gives 5 + 5 = 10 USD. Valuing the combined BTC outflow later at 45,000 gives 10.125 USD. Neither procedure changes the original BTC ledger. They answer historical-value and later-value questions respectively.

For a combined report, decide which conversion convention you need and label it. Add BTC payments in BTC first if you are reconciling the coin balance. Convert each event at a stated rate if you are analyzing historical dollar expense. Do not add 0.000225 BTC directly to a 5.10 USDT debit and call the numerical sum a total fee.

A coin-collateralized contract is not automatically an inverse contract. Some products accept several collateral assets while maintaining a linear payout. Determine the payoff and funding formula from the exact instrument, not from the coin sitting in your wallet. Otherwise, dividing by price can be just as wrong as multiplying by it.

Compare one event before investigating the cumulative total. A correct sum of incorrect lines is still incorrect, and several errors can cancel by accident. Match the contract, assessment time, side, eligible quantity, valuation price, final rate and settlement currency. Those fields explain most large discrepancies without needing an elaborate spreadsheet.

A public historical rate can verify the contract’s rate at an event, but it does not reveal your private position. A current mark price cannot prove the valuation used hours earlier. If the account export includes the actual payment, preserve it as the observed amount and keep your reconstruction in a separate column. Replacing the record with an estimate destroys the comparison.

Keep precision until the last step

Three hypothetical debits of 0.0049 USDT sum to 0.0147 USDT. Rounding each first to two decimals displays three zeroes and loses the total. Sum the booked precision before rounding the result.

Our demonstration retains 3.025 USDT for the fourth event in the unreduced case and sums to 10.575 USDT. A two-decimal presentation would normally show about 10.58, but that display policy must not be presented as the exchange’s internal rounding rule. If the export gives more precision, use it.

Separate rate precision from quantity precision. A funding rate displayed as 0.01% may conceal more digits in the settled record. A position summarized as 0.2 BTC can also hide a smaller quantity increment. Reconstructing from rounded labels may explain the direction and rough amount while still missing the final few units of account precision.

Do not subtract the same cost twice when moving from the funding ledger to the trade result. If a closed-P&L export is already net of funding, adding the signed ledger again duplicates it. Start with price-only P&L if you intend to add every expense yourself, or use the platform’s net figure and reconcile its components.

A constant-rate calculator is useful for a scenario, but it cannot recreate a changing history by itself. Take a deliberately simple comparison: 10,000 USDT of valuation held at each of three eight-hour assessments. Contract A settles at +0.01%, −0.005% and +0.02%. For the long, the three cash flows are −1.00, +0.50 and −2.00, a net debit of 2.50 USDT.

Now assume Contract B has twenty-four hourly assessments, each at +0.001%. Keeping its valuation at the same 10,000 for every event gives a 0.10 USDT debit each hour, or 2.40 USDT total. Its smaller historical funding total wins this narrow comparison by 0.10 USDT. A difference in one trading commission or fill can easily outweigh that amount.

This comparison holds dollar value constant. For a fixed coin quantity in a moving market, calculate a new notional at each event. Maintaining fixed-dollar exposure instead requires rebalancing, with its own execution costs.

An average rate needs the right weights

In the four-event example, the arithmetic average of +0.01%, −0.005%, +0.02% and +0.01% is +0.00875%. Multiplying that by the original 30,000 USDT and four events gives a 10.50 USDT debit. The actual modeled ledger gave 5.10 because the quantities and prices changed. The average alone discarded the information that determined the payments.

If you need a summary rate, dividing the signed rate-weighted notionals by the sum of the event notionals produces an exposure-weighted event rate. That can summarize the data, but it does not replace the cash-flow total. A daily or annual equivalent then adds another time assumption. For an account reconciliation, the sum of individual transfers is simpler and less ambiguous.

Use the calculator for the question it answers: an assumed rate, exposure and payment schedule. For a changing history, use the event-by-event method above. The difference is not a weakness of arithmetic; it is a difference between forecasting with assumptions and reconstructing transactions already assessed.

The position changes before the second assessment, so its payment uses 0.1 BTC. Sum event cash flows in one currency; put commissions and transfers on separate lines.