How do you calculate P&L on an inverse perpetual?
For a standard inverse perpetual with a fixed dollar face value per contract, calculate trading P&L using reciprocal prices. The result is in the settlement coin. Multiplying the price change by a fixed BTC quantity gives you a different instrument.
Suppose a hypothetical BTC inverse contract has a $1 face value. You buy 100,000 contracts at $50,000 per BTC and close the entire position at $55,000. Before fees and funding:
Q = signed contract count; positive for a long
C = dollar face value per contract
P&L_BTC = Q × C × (1 / entry_price − 1 / exit_price)
= 100,000 × $1 × (1 / $50,000 − 1 / $55,000)
= 0.18181818 BTC
P&L_USD_at_exit = 0.18181818 × $55,000
= $10,000The position has $100,000 of contract face value. Its BTC equivalent changes with price: 2 BTC at entry, approximately 1.818182 BTC at exit. That changing conversion is why I want contract specifications beside the accounting code. A column named size is an invitation to spend Friday evening discovering which unit somebody meant.
Check the venue’s multiplier, settlement currency and rounding rules. “Inverse” describes a payoff convention; it doesn't guarantee that one contract means one dollar everywhere.
Why does my account gain more dollars than the trade made?
Because the collateral also has a price.
Start with 1 BTC of collateral, worth $50,000, and run the trade above. Assume no deposits, withdrawals, fees or funding, and enough margin throughout. After closing, the account holds 1.18181818 BTC. At $55,000 per BTC, that's $65,000.
| Component | Calculation | Dollar change |
|---|---|---|
| Original collateral | 1 BTC × ($55,000 − $50,000) | +$5,000 |
| Derivative P&L, valued at exit | 0.18181818 BTC × $55,000 | +$10,000 |
| Total account equity | $65,000 − $50,000 | +$15,000 |
The trade ledger and account equity curve answer different questions. If your report labels the entire $15,000 as signal P&L, it gives the strategy credit for holding its collateral through a rising market.
And the reverse matters. A strategy can accumulate BTC while its dollar equity falls. Neither chart is inherently wrong. The bug is switching between them without saying so.
Should I measure backtest returns in BTC or USD?
Pick the reporting currency before comparing strategies, then keep both views available. For this account, the BTC return is 18.18%; the dollar return is 30%. Those are two measurements of the same outcome.
For comparisons across US equities, stablecoin-settled futures and coin-settled contracts, I generally use dollar account equity as the common reporting series. For a research mandate defined around accumulating BTC, the BTC series deserves equal prominence. The choice changes the return distribution, drawdowns and Sharpe ratio.
Include a passive collateral benchmark. Here, simply retaining the initial 1 BTC would have produced a 10% dollar return. The account beats that benchmark by 20 percentage points over this interval. That subtraction describes this example; it doesn't establish alpha or adjust for the derivative exposure taken along the way.
Write the unit into the field name. Use equity_btc, equity_usd and pnl_btc. A naked equity column becomes dangerous the moment two contract types enter the same report.
How should a backtest record fees and funding paid in BTC?
Record the actual coin movement when it happens. A BTC fee reduces the BTC wallet; a BTC funding receipt increases it. Derive those amounts using the applicable contract rules and historical rates.
Then distinguish transaction attribution from account valuation. A 0.001 BTC fee paid when BTC trades at $50,000 has a $50 value at payment. If BTC later reaches $55,000, the account holds $55 less than an otherwise identical account that never paid that fee. The extra $5 is the subsequent price change on the coin that left the account.
Both figures can be useful. Adding historical dollar-valued cash flows to starting dollar equity will miss that currency effect unless you reconcile it explicitly.
My preference is a coin ledger as the accounting source, with dollar valuations derived from it. At each snapshot, value wallet balance plus unrealized coin P&L using a documented, timestamp-aligned conversion price. Record any deliberate difference between the contract marking price and the reporting conversion price.
What tests catch inverse-contract accounting bugs?
I start with tiny synthetic paths whose answers fit on paper. Market history is remarkably good at hiding a unit error inside a plausible equity curve.
| Test, excluding costs | Expected result |
|---|---|
| Enter and exit at the same price | Zero derivative P&L in BTC |
| Reverse the position sign on an identical path | Derivative P&L changes sign exactly |
| Hold 1 BTC with no derivative position; price rises from $50,000 to $55,000 | BTC equity stays at 1; dollar equity rises by $5,000 |
| Close the example position at its current mark | Unrealized P&L moves into the wallet without changing total equity |
That final test catches double counting: the engine credits realized P&L but forgets to remove the unrealized amount. Also test a partial close. Only the closed contracts should settle their P&L; the remainder must retain the correct entry basis under the venue’s accounting convention.
What should an AI research agent report for an inverse strategy?
Contract count and multiplier, settlement currency, starting collateral, coin cash flows, and equity in the declared reporting currency. Alongside the strategy curve, show the passive collateral curve and reconcile the difference.
In an autonomous research workflow, I'd make that reconciliation a condition for accepting a backtest. An optimizer can rank whatever number you hand it. If a rising BTC balance sheet is being credited to the trading signal, it will cheerfully optimize that accounting mistake.
The useful report can explain why this trade made $10,000 while the account gained $15,000, down to the last settlement entry. That's a result another researcher can actually audit.
← All posts
