Skip to content

DCA and execution

DCA inverse average entry: keep the units straight

A three-fill inverse ladder reconciles USD face, BTC equivalents and gross P&L. A partial-fill example exposes an average-entry error before exit orders change.

Three ivory slabs hover above black funnel cups holding different portions of lime sand, joined by channels to one ivory basin.
Illustration for dca and execution; examples in this article are educational.

For a DCA bot adding to a fixed-USD-face inverse contract, average entry is total USD face amount divided by the sum of each filled face amount divided by its fill price. This is a face-weighted harmonic average, not an ordinary average of prices. The denominator is an entry-value equivalent in coin; it is not the collateral deposited or coins bought on spot. Use executed fills, the correct contract multiplier and one position side.

Start with the quantity the contract actually accepts

A label such as “buy 1,000” is incomplete. It could mean contracts, dollars of face amount or units of the underlying asset. Before calculating an inverse average, record the venue, exact instrument, settlement coin and fixed USD face value per contract.

For example, Phemex's order-value documentation describes its BTCUSD inverse contract with a 1 USD contract size and calculates coin value as contract quantity multiplied by contract size, divided by execution price. That specification belongs to the documented instrument; check the current specification of the instrument being reconciled.

This article concerns repeated additions to one inverse position. The broader linear-versus-inverse comparison explains settlement and collateral differences between contract families. Copying a linear average-price formula into an inverse deal ledger can produce a plausible-looking number in the wrong accounting model.

Define each executed fill using:

  • nᵢ: filled contract count.
  • m: fixed USD face value per contract.
  • Fᵢ = nᵢ × m: filled USD face amount.
  • Pᵢ: execution price in USD per BTC for this BTC-settled example.

Then calculate:

F = ΣFᵢ

V = Σ(Fᵢ / Pᵢ)

Average entry E = F / V

Here, F is USD face and V is the entry-value equivalent in BTC, so F/V has units of USD per BTC. Bybit's average-entry reference documents this reciprocal aggregation for its inverse perpetual and expiry contracts.

Reconcile a three-fill averaging ladder

The following hypothetical long uses a constant 1 USD face value per contract. Every listed order fills completely at one price. There are no reductions, commissions, funding, settlement resets or other positions. These are invented prices for checking arithmetic, not a recommended ladder.

Executed stepAdded USD faceFill price, USD/BTCAdded entry-value equivalent, BTCCumulative USD faceCumulative average, USD/BTC
Base fill4,00060,0000.066666674,00060,000.00
First addition6,00050,0000.1200000010,00053,571.43
Second addition5,00040,0000.1250000015,00048,128.34

Using unrounded values:

V = 4,000/60,000 + 6,000/50,000 + 5,000/40,000 = 0.3116666667 BTC

E = 15,000 / V ≈ 48,128.34 USD/BTC

The face-weighted arithmetic average is approximately 49,333.33. The unweighted average of the three prices is 50,000. Neither reconciles this inverse position. Equal face amounts contribute more to V at lower prices; the final 5,000 face contributes more BTC equivalent than the earlier 6,000 face.

There is a useful alternative expression: weight each price by its Fᵢ/Pᵢ coin equivalent. That arithmetic calculation gives the same result as the face-weighted harmonic calculation. “Never use an arithmetic average” is therefore too broad; the error is using USD face weights in an arithmetic price average.

Prove the result against position P&L

For this inverse long, gross price P&L at a common exit or reference price X is:

Gross P&L, BTC = Σ[Fᵢ × (1/Pᵢ − 1/X)]

Combining the fills gives:

Gross P&L, BTC = V − F/X = F × (1/E − 1/X)

This follows the reciprocal long-P&L structure in Bybit's inverse-contract calculation guide. For a short, reverse the reciprocal subtraction. The same average-entry aggregation applies to same-side additions.

At a hypothetical common reference price of 52,000, the example produces approximately +0.02320513 BTC. At 45,000, it produces approximately −0.02166667 BTC. Calculating each fill separately and adding the results must match the aggregate calculation. At the unrounded average E, gross price P&L is zero.

An arithmetic average of 49,333.33 would fail that reconciliation. The average is useful because it preserves the payoff of the underlying fills, not because it sits visually between the entry prices.

Fees and funding belong in separate native-currency ledger entries. A zero gross price result does not establish net break-even. Use the break-even and costs guide for that distinction. The take-profit recalculation example uses spot inventory; its distinction between desired exits and confirmed working orders is useful here, but its target formula must not be copied to inverse contracts.

Coin equivalent does not mean collateral or inventory

The table's 0.31166667 BTC is an accounting denominator. It is neither a purchase of that much spot BTC nor proof that the account deposited that much collateral.

In a deliberately simplified initial-margin model, divide each fill's coin equivalent by a fixed leverage factor. At an illustrative 5× factor, a 5,000 USD-face addition at 60,000 has a coin-equivalent margin component of 5,000/60,000/5 ≈ 0.01666667 BTC. The same face at 40,000 produces 0.025 BTC. The USD face is unchanged; the required coin amount in this simplified calculation rises by 50%.

Those figures exclude fees, reserves, maintenance requirements, risk tiers and account-level offsets. They are not exchange quotes for available margin. Bybit's inverse FAQ identifies coin-denominated margin, fees and P&L, while also describing eligible collateral ratios and possible borrowing interest. Check the actual account arrangement and the cross-versus-isolated collateral boundary.

Adding collateral alone does not change F, V or E. Changing leverage alone does not add a fill either. A lower average also does not establish that the position can survive the path to a planned exit.

Catch the partial-fill error before updating exits

Suppose the final planned 5,000 face order fills only 2,000 at 40,000. The actual totals become:

F = 12,000 USD

V = 4,000/60,000 + 6,000/50,000 + 2,000/40,000 = 0.2366666667 BTC

E ≈ 50,704.23 USD/BTC

Using the fully filled ladder would incorrectly report 48,128.34 and overstate the open face amount by 3,000 USD. At a 45,000 reference, the actual gross loss is 0.03 BTC. The fictional full-fill ledger reports approximately 0.02166667 BTC of loss.

Process executions separately when one order fills at multiple prices. Use the partial-fill reconciliation guide to distinguish ordered and executed amounts. Price normalization is another boundary: price-tick collisions can make intended ladder levels coincide, so reconstruct from actual execution prices rather than unique planned level labels.

Keep a compact reconciliation worksheet

Save the following fields with each position snapshot:

CheckRequired record or action
IdentityExact contract, multiplier, settlement coin and position side
Fill ledgerExecution identifier, filled count, price and USD face
Running totalsSum of face and sum of face divided by execution price
Payoff checkPer-fill P&L equals aggregate P&L at one recorded reference price
Separate balancesCollateral, trading fees, funding and realized P&L in their actual currencies
ExceptionsPartial close, reversal, expiry, manual trade or changed contract specification

The formula assumes positive prices and positive same-side opening amounts. With no open face, there is no average entry to report. Reject zero or invalid prices. Do not combine long and short fills by allowing signed quantities to cancel in this formula: a reduction or reversal requires the venue's position-accounting rules. After reductions, reconcile the remaining position and realized ledger rather than recomputing from every historical order as if all remained open.

Editorial method: KLINEO Editorial used primary venue documentation and independently checked hypothetical arithmetic. This educational worksheet does not establish inverse-contract DCA support in KLINEO or report observed trading performance.

Keep the context with the example.

Each worked example is illustrative, with its sources and assumptions in the article. Read our editorial standards for authorship, verification and corrections.