逆型パーペチュアルのP&Lはどう計算するのか?
コントラクトあたりのドル建て額面が固定された標準的な逆型パーペチュアルでは、価格の逆数を使ってトレード損益を計算する。結果は決済コイン建てになる。価格変化に固定BTC数量を掛けるやり方では、別の商品の計算になってしまう。
仮に、あるBTC逆型コントラクトの額面が1ドルだとする。1BTC=50,000ドルで100,000枚を買い建て、1BTC=55,000ドルでポジション全体を決済する。手数料とファンディングを除くと以下のようになる。
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,000このポジションのコントラクト額面は100,000ドル相当だが、そのBTC換算額は価格によって変わる。建玉時は2BTC、決済時は約1.818182BTCだ。この変化する換算レートこそ、私が会計コードの傍らにコントラクト仕様を置いておきたい理由である。sizeという名前のカラムは、金曜の夜を丸ごと使って誰がどの単位を意図したのか突き止める羽目になる招待状のようなものだ。
取引所の乗数、決済通貨、端数処理ルールを確認してほしい。「インバース」はペイオフの規約を表すものであり、どの取引所でも1コントラクト=1ドルであることを保証するものではない。
なぜ口座の増加額がトレードの利益より大きくなるのか?
担保にも価格があるからだ。
50,000ドル相当の1BTCの担保から始めて、上記のトレードを実行するとする。入出金、手数料、ファンディングはなく、証拠金は常に十分にあると仮定する。決済後、口座は1.18181818BTCを保有する。1BTC=55,000ドルなら、これは65,000ドルに相当する。
| 項目 | 計算 | ドル増減 |
|---|---|---|
| 当初担保 | 1 BTC × ($55,000 − $50,000) | +$5,000 |
| デリバティブ損益(決済時評価) | 0.18181818 BTC × $55,000 | +$10,000 |
| 口座エクイティ合計 | $65,000 − $50,000 | +$15,000 |
トレード台帳と口座エクイティカーブは異なる問いに答えている。もしレポートが15,000ドル全体をシグナルの損益として表示するなら、それは上昇相場の中で担保を保有し続けたことの手柄まで戦略に与えてしまうことになる。
逆のケースも重要だ。ドル建てエクイティが下落している間に、戦略がBTCを積み増していくこともあり得る。どちらのチャートもそれ自体は誤りではない。バグとなるのは、それを明示せずに両者を切り替えてしまうことだ。
バックテストのリターンはBTC建てとドル建てのどちらで測るべきか?
戦略を比較する前にレポート通貨を決め、その上で両方のビューを常に確認できるようにしておく。この口座の場合、BTC建てリターンは18.18%、ドル建てリターンは30%だ。これらは同じ結果を測る2つの指標にすぎない。
米国株、ステーブルコイン決済先物、コイン決済コントラクトを横断して比較する場合、私は通常ドル建て口座エクイティを共通のレポート系列として使う。BTCの蓄積を目的として設計された研究であれば、BTC建て系列も同等に重視すべきだ。この選択によってリターン分布、ドローダウン、シャープレシオは変わる。
受動的な担保保有ベンチマークを含めること。ここでは、当初の1BTCを単に保有し続けるだけでもドル建てで10%のリターンになっていた。この口座はその期間においてベンチマークを20ポイント上回っている。この差引きはこの例を説明するものであって、アルファの存在を証明するものでも、その過程で取ったデリバティブ・エクスポージャーを調整したものでもない。
単位をフィールド名に書き込むこと。 equity_btc、equity_usd、pnl_btcのように。裸のequityカラムは、2種類のコントラクトが同じレポートに混在した瞬間に危険なものになる。
BTC建てで支払われる手数料とファンディングをバックテストはどう記録すべきか?
実際のコインの動きが発生した時点でそれを記録する。BTC建て手数料はBTCウォレットを減らし、BTC建てファンディングの受け取りはそれを増やす。それらの金額は、該当するコントラクトのルールと過去のレートを使って算出する。
その上で、取引の帰属と口座評価を区別すること。BTCが50,000ドルのときに支払われた0.001BTCの手数料は、支払い時点で50ドルの価値を持つ。その後BTCが55,000ドルに達した場合、その口座はその手数料を一切支払わなかった場合と比べて55ドル少ない残高になる。この追加の5ドルは、口座を出て行ったコインのその後の価格変動によるものだ。
どちらの数字も有用でありうる。過去のドル建てキャッシュフローを当初のドル建てエクイティに単純に加算すると、明示的に調整しない限りこの通貨効果を見落とすことになる。
私が好むのは、コイン台帳を会計の情報源とし、そこからドル評価額を導出する方式だ。各スナップショットでは、ウォレット残高と未実現のコイン建て損益を、タイムスタンプが整合し文書化された換算レートを使って評価する。コントラクトのマーキング価格とレポート用の換算レートとの間に意図的な差異がある場合は、それを記録しておくこと。
逆型コントラクトの会計バグを見つけるにはどんなテストが有効か?
私はまず、答えが紙の上で計算できるほど小さな合成パスから始める。市場の実データは、単位の誤りをもっともらしいエクイティカーブの中に驚くほど巧妙に隠してしまう。
| テスト(コストを除く) | 期待される結果 |
|---|---|
| 同じ価格でエントリーとエグジットを行う | BTC建てデリバティブ損益がゼロになる |
| 同一のパスでポジションの符号を反転させる | デリバティブ損益の符号が正確に反転する |
| デリバティブ・ポジションを持たずに1BTCを保有し、価格が50,000ドルから55,000ドルに上昇する | BTC建てエクイティは1のまま、ドル建てエクイティは5,000ドル増加する |
| 例のポジションを現在のマーク価格で決済する | 未実現損益がウォレットに移り、合計エクイティは変化しない |
最後のテストは二重計上を検出する。エンジンが実現損益を計上する一方で、未実現分を取り除き忘れるケースだ。部分決済もテストすること。決済された分のコントラクトのみが損益を確定させるべきであり、残りは取引所の会計規約に従って正しいエントリー基準を維持しなければならない。
AIリサーチエージェントは逆型戦略について何を報告すべきか?
コントラクト数と乗数、決済通貨、当初担保、コイン建てキャッシュフロー、そして申告されたレポート通貨でのエクイティ。戦略のカーブと並べて、受動的な担保保有カーブも示し、その差を突き合わせて説明すること。
自律的なリサーチワークフローにおいては、この突き合わせをバックテストを受理するための条件にするだろう。オプティマイザーは与えられた数字が何であれランク付けしてしまう。上昇するBTC建てバランスシートがトレーディングシグナルの手柄にされてしまえば、オプティマイザーは喜んでその会計上の誤りを最適化してしまう。
有用なレポートとは、なぜこのトレードが10,000ドルの利益を生み、口座が15,000ドル増えたのかを、最後の決済エントリーに至るまで説明できるものだ。それは他の研究者が実際に監査できる結果である。
← 記事一覧