結論
LPトークン・債権トークンの損益計算は、履歴の欠損や数量不一致により「売買処理」とせざるを得ないケースが多く、理論上の正しい処理が実務的に不可能な場面が頻発する。
- 理由① LPトークンの返却履歴がブロックチェーン上に残らない、返却数量と預入数量が一致しない、預入と返却が別トランザクションに分かれるなど、「預入＝貸付」として処理するための前提データが揃わない。
- 理由② 債権トークンも同様に、プロトコルによっては残高表示がなかったり一部しか表示されないケースがある。結果として、税務上は売買処理（取得＋譲渡）として計算せざるを得ず、本来の経済実態と処理がずれる。
- 条件 これらの問題は個人の知識不足ではなく、ブロックチェーンインフラ側の制約に起因する。正確な損益計算にはオンチェーンデータの解析と税務判断の両方が必要であり、専用ツールなしでの対応は現実的でない。
所得税法第36条第1項
この記事でわかること
- LPトークン・債権トークンの損益計算で実務上遭遇する5つの問題パターン
- 損益計算ソフトの対応限界とその構造的な原因
- 理論上の処理方針と実務で売買処理とせざるを得ない理由
- マイナーなDApps・サービス終了DAppsの計算上の扱い
- 計算困難なケースへの対応方針
LPトークン・債権トークンの基本的な仕組み
【結論】LPトークンは流動性供給時に、債権トークンはDAppsへの暗号資産預入時にそれぞれ付与されるトークンである。いずれもDAppsのスマートコントラクトが発行するため、取引履歴の出力形式はプロトコルごとに異なり、統一的な損益計算の前提が成り立たない（所得税法第36条第1項・第35条）。
LPトークンは、UniswapやCurve等の分散型取引所（DEX）に暗号資産を預け入れた際に付与されるトークンである。流動性を引き出す際にLPトークンを返却し、預けた暗号資産と手数料報酬を受け取る。
債権トークン（cDAI、stETH、eETH等）は、DAppsに暗号資産を供給して対価として受け取るトークンである。流動性供給と概念的にはほぼ同じであり、コントラクト上でも明確に区別できない。
損益計算においては、LPトークン・債権トークンのいずれも以下の4パターンの処理方法がある。
| パターン | 処理方法 | 概要 |
|---|---|---|
| A | 売買処理 | LPトークンを預けたトークンで「購入」したものとして処理 |
| B | 貸付（時価）＋借入（時価） | 預入＝貸付、LPトークン取得＝借入として時価で記帳 |
| C | 貸付（取得原価）＋借入（時価） | 預入＝貸付（原価）、LPトークン取得＝借入（時価） |
| D | 預入処理＋借入（時価） | 預入は保管場所変更、LPトークン取得＝借入 |
パターンA・B・Cは最終損益が一致する。パターンDのみ時価変動分が反映されないため異なる結果となる。
ここまでが理論上の整理であり、以下で述べる実務上の問題は、これらのパターンをそもそも適用できないケースが多いという点にある。
実務で遭遇する5つの問題パターン
【結論】LPトークン・債権トークンの損益計算で実務上遭遇するのは「シンプルなケース」よりも「複雑でイレギュラーなケース」の方が多い。以下の5パターンは一例に過ぎず、プロトコルの仕様次第でさらに多様な問題が発生する（所得税法第36条第1項）。
損益計算や申告を専門家に依頼したい場合は「暗号資産・DeFiの損益計算を依頼する（Cryptorch）」をご覧ください。
パターン①：流動性解除時にLPトークン返却履歴が出ない
流動性供給時にはLPトークンが付与される履歴が出力されるにもかかわらず、流動性解除時には暗号資産のみが戻り、LPトークンを返却する履歴が出てこないケースがある。この場合、LPトークンの「処分」がいつ・いくらで行われたかを取引履歴から確認できないため、損益計算の根拠が不明になる。
パターン②：供給・解除時双方でLPトークンが非表示
流動性供給時・解除時の双方で、そもそもLPトークンが履歴に一切表示されないケースが存在する。パターン①よりもさらに深刻で、LPトークンの存在自体を取引履歴から把握できない。
パターン③：元本と利息が別トランザクションで返却
債権トークンと引き換えに利息分の暗号資産のみが返却され、元本は別のトランザクション（tx）で返ってくるケースがある。損益計算ソフト上では1つの「引出」として処理したくても、2つのトランザクションを紐付ける必要があり、自動処理が困難になる。
パターン④：返却枚数と付与枚数の不一致
すべての暗号資産を返却してもらったにもかかわらず、LPトークンや債権トークンの返却枚数が付与枚数に比べて少なく、少量がウォレットに残り続けることがある。この事象は計算処理そのものには影響を与えないが、トークン数量の調整時に煩雑さを増大させる原因となる。
パターン⑤：損益計算ソフトで取引の一部しか表示されない
損益計算ソフト上で表示される取引内容が、その取引全体のごく一部しか表示されないケースがある。取引全体を一律に表示しようとすると、他の取引において納税者に関係のない処理まで表示させてしまう恐れがあるため、損益計算ソフト運営側で個別に対処が必要となるが、コスト的に対応が困難な場合が多い。
売買処理とせざるを得ない構造的理由
【結論】LPトークン・債権トークンの処理は、理論上「預入」や「貸付・借入」を前提とするスタンスを採りたくても、実務上は「売買処理」（パターンA）とせざるを得ないケースが多い。その原因はプロトコル側の仕様の多様性と、損益計算ソフトの対応限界にある（所得税法第36条第1項・第35条）。
売買処理とせざるを得ない理由は大きく3つに分類できる。
第一に、DAppsの仕様の多様性である。 一見してどのような内部処理が行われたかの判別が不明なDAppsが存在する。明らかにLPトークンや債権トークンの付与枚数が返却時の枚数と合わないDAppsも存在する。各プロトコルのスマートコントラクトの実装が異なるため、統一的な「預入・返却」の対応関係を構築できない。
第二に、取引の複雑性である。 LPトークン・債権トークンの取引は、教科書的なシンプルなケース（預ける→返してもらう）だけでなく、幾度もLPトークン・債権トークンを預け入れたり、別種のトークンに変換したりする複雑なケースが多い。預け入れたトークンが同じ種類のまま手元に戻ってこないケースも多発する。このような場合、「貸付・借入」のスタンスを維持すること自体が不可能になる。
第三に、損益計算ソフトの対応限界である。 マイナーなDAppsやサービス終了したDAppsの場合、損益計算ソフトによる個別対応がコスト的に見合わないという事情がある。結果として、対応されないプロトコルの取引は手動での処理が必要になり、売買処理として整理するのが現実的な選択となる。
| 理由 | 内容 | 影響 |
|---|---|---|
| DAppsの仕様の多様性 | 内部処理が不明・枚数不一致 | 「預入・返却」の対応関係が不成立 |
| 取引の複雑性 | 多段階預入・トークン変換 | 貸付・借入スタンスの維持が不可能 |
| ソフトの対応限界 | マイナー・終了DApps未対応 | 手動処理＝売買処理が現実的 |
損益計算や申告を専門家に依頼したい場合は「暗号資産・DeFiの損益計算を依頼する（Cryptorch）」をご覧ください。
よくある質問（FAQ）
Q1. LPトークンの損益計算は必ず売買処理になりますか？
必ずではない。取引履歴が完全に取得でき、預入と返却の対応関係が明確なプロトコルであれば、貸付・借入処理（パターンB等）も採用できる。ただし実務上は履歴欠損等の理由で売買処理とせざるを得ないケースが多い。
Q2. 債権トークン（stETH等）もLPトークンと同じ問題がありますか？
ある。債権トークンは流動性供給と概念的にほぼ同じであり、コントラクト上でも明確に区別できない。履歴欠損・数量不一致・別トランザクションでの返却等、LPトークンと同種の問題が発生する。
Q3. 損益計算ソフトで対応されていないDAppsの取引はどうすればよいですか？
手動で取引データを整理し、売買処理として損益計算するのが現実的である。マイナーなDAppsやサービス終了したDAppsは、損益計算ソフトによる個別対応がコスト的に見合わないため、自動対応されないケースが多い。ブロックチェーンエクスプローラーで取引内容を確認し、各トランザクションの経済的実態に基づいて処理する必要がある。
Q4. LPトークンの返却枚数が付与枚数と合わない場合、税務上どう処理しますか？
少量のトークン残留は計算処理そのものには影響を与えない。全暗号資産の返却が完了しているにもかかわらずLPトークンが少量残る場合、実質的な経済的価値がないため、数量調整の処理として整理する。ただし、トークン残高の帳尻を合わせる作業が増える点で実務上の煩雑さは生じる。
損益計算や申告を専門家に依頼したい場合は「暗号資産・DeFiの損益計算を依頼する（Cryptorch）」をご覧ください。
関連記事・サービスページ
関連記事
専門の税理士に依頼する場合
暗号資産の確定申告の全体像・最新情報は「暗号資産の確定申告ガイド【2027年版】」をご覧ください。
関係法令
- 所得税法第36条第1項（収入金額）
- 所得税法第35条（雑所得）