今、どこかのDAOの財務チャンネルで、ある貢献者が自分のウォレット残高がリアルタイムで増えていくのを見ている——月に一度でも、隔週でもなく、毎秒ごとに。給与日も、バッチ処理もない。ただ黙々と増え続ける数字を、仕事をしている間眺め、雇用主がストリームをキャンセルした瞬間に止まる。
これがストリーミング給与であり、もはや暗号資産Twitterの珍しい話題ではない。SuperfluidやSablierといったプロトコルは現在、数百ものDAOやWeb3チームの実際の報酬を動かしており、リモートファーストの企業も増え、請負契約者への手当としてこのモデルを実験している。これは現実の問題を解決する——「給与処理は通ったか」という不安はもうない——しかし、どの教科書もカバーしていない会計上の問題を生み出す：支払いが決して停止しないため、明確な支払日が存在しない賃金費用を、どのように計上するのか？
ストリーミング給与とは実際何か
従来の給与は、一連の一括払いイベントである：仕事が2週間分発生し、その後、単一の取引で決済される。ストリーミング給与はそのギャップを解消する。雇用主はスマートコントラクトに資金を預け、レートを設定する（例えば、1日100 USDC）。プロトコルは、受取人の請求可能残高に、毎秒約0.00116 USDCの割合で継続的にクレジットする。受取人は、いつでも発生した金額を引き出すことができる。何も「支払われる」のは、彼らが引き出すまでではないが、すべてがバックグラウンドで絶えず発生している。
2つの主要なプロトコルは、これに対して異なる技術的アプローチを取っている：
Superfluidは、通常のERC-20トークンを、ストリーミングロジックを内蔵した「スーパートークン」（USDCxなど）にラップする。ラップされたトークンのbalanceOf関数は継続的に更新される数値を返すため、ウォレットの残高がリアルタイムで目に見えて増加する。送信者のトークンはストリームの期間中プロトコルにロックされるため、Superfluidはオフチェーンの「清算人（リキデーター）」に依存しており、彼らは送信者のバッファを監視し、残高がゼロになる前に強制的にストリームを閉じ、その報酬として手数料を得る。バッファが枯渇すると、従業員のストリームは警告なしに清算される。
Sablierは、2019年にクローズドエンドのベスティングストリームでこのモデルを先駆け、現在はSablier Flowも提供している。これはオープンエンドで債務追跡型のモデルで、ラッピングや清算人を必要とせず、通常のERC-20トークンで機能する。各ストリームは独自の残高を持ち、レートはストリーム途中で調整可能で、ストリームはどちらかの当事者によって一時停止、再開、または恒久的に終了できる。これは、Superfluidのリアルタイム残高表示の一部を、よりシンプルな統合と第三者清算人インフラへの依存なしと引き換えにしている。
両モデルは、クローズドエンドストリーム（固定額の預金が固定期間にわたって権利確定する—トークンの権利確定や助成金の支払いに適している）とオープンエンドストリーム（終了日が固定されていない；雇用主が必要に応じて補充し、ストリームはキャンセルされるか資金が枯渇するまで実行される）の間のスペクトラム上に位置する。
会計上の問題：費用はいつ「発生」するのか？
発生主義会計では、賃金費用は、現金が動く時ではなく、従業員が仕事を遂行する時点で認識される。ストリーミング支払いは、原則として、その原理の最も純粋な表現である—台帳は単に発生率を継続的に追跡すべきである。しかし実際には、ほとんどの簿記システム（そしてほとんどの会計士）は離散的な期間で考えるため、毎秒のストリームは、仕訳帳が表現できるものにまで再び離散化する必要がある。
ほとんどの財務チームが採用する実用的なアプローチ：
- ストリームレートを、修正されない限り、既知の一定の発生額として扱う。 貢献者に100 USDC/日がストリーミングされている場合、日次（または、より軽量な帳簿の場合は月次）の発生仕訳を計上し、賃金/請負費用を借方、義務発生額を貸方にする。毎秒の仕訳は必要ない；報告頻度に合った発生額が必要である。
- 引き出し時に調整する。 受取人が実際に発生した残高を請求するとき、それは新しい費用ではなく、負債の決済であり、「ストリーム未払金」を減らし、財務省資産勘定を貸方にする。これは、すでに通常の未払給与・未払金を処理する方法と同じである。
- レートが調整された場合、新しいストリームではなく、レート変更として認識する。 Sablier Flowの調整可能レートとSuperfluidのストリーム変更呼び出しは、どちらも雇用主がストリーム途中で毎秒のフローを変更することを可能にする。各変更は、事実上、そのブロックタイムスタンプから有効になる新しい発生率である。同じ負債に対する修正として記録し、新しい明細項目として扱わない。そうしないと、調整が数十のマイクロストリームに断片化し、決して一致しなくなる。
人々がつまずく微妙な点：費用は、受取人が決して引き出さなくても発生する。 3ヶ月間、ストリームが放置されたままの貢献者は、依然として財務省に対して3ヶ月分の実際の賃金費用を発生させている。負債はまだ現金で決済されていないだけである。「何も支払われなかった」からといって発生額を計上しないのは、DAOの帳簿で最も一般的な間違いであり、まさに財務運転資金の予測を静かに過大評価するタイプのものである。
公正市場価値：依然として人間が必要な部分
ストリームがステーブルコインで支払われる場合、会計は従来の現金給与に近い — 1 USDCは1ドルであり、それ以外はなく、FASBの暗号資産に関する公正価値ガイダンス（ASU 2023-08）は、台帳の賃金側にはほとんど関係しない。
ストリームが変動の大きいネイティブトークンで支払われる瞬間、発生期間ごとに公正市場価値への換算が必要となる。税務当局は、メカニズムが異なっても基礎となる原則は一貫している。IRSは仮想通貨による賃金を、受領日の公正市場価値での通常所得として扱い（Notice 2014-21）、英国のHMRCはGBP相当額でのPAYE/NI源泉徴収を要求し、EUのガイダンスはステーブルコインやトークンによる賃金を、その換算相当額での所得として扱う。これらの枠組みのいずれも、「秒単位で継続的に受け取る価値」を念頭に置いて書かれていない。ほとんどのチームは、引き出し時点（受取人が実際に管理権を取得する時点）のFMVを採用する。これは従来の給与日に最も近い類似点であり、市場価格が明白な唯一の時点だからである。その選択を会計方針の注記に文書化しておくこと。「どのタイムスタンプの価格を使用したか」は、監査人が最初に尋ねる質問だからである。
実例
あるDAOが、貢献者に対してSablier Flowストリームを月額3,000 USDCで開設し、毎月決算を行うと仮定する。簿記は、「毎秒」と考えるのをやめ、「既知のレートを期間に適用する」と考え始めれば、思ったより簡単である：
- ストリーム開始、1ヶ月目決算： 請負費用 3,000 USDC（借方）/ ストリーム未払金 3,000 USDC（貸方）。現金は動いていない；発生した債務を認識している。
- 貢献者が2ヶ月目中旬に1,800 USDCを引き出し： ストリーム未払金 1,800 USDC（借方）/ 財務省（USDC）1,800 USDC（貸方）。これは決済であり、費用ではない。費用は発生時にすでに計上されている。
- 雇用主が2ヶ月目の途中でレートを月額3,500 USDCに引き上げ： その月の2つのレートにわたって発生額を按分する（例：15日間@3,000/月 + 15日間@3,500/月 ≈ 3,250 USDC）。新しい「ストリーム」勘定を開設するのではなく、レート変更は同じ負債のメタデータである。
- 雇用主が3ヶ月目中旬にストリームをキャンセル： キャンセルブロックタイムスタンプまでの最終部分月発生額を計上する。その後、残りのストリーム未払金残高は、最終引き出しで精算されるか、貢献者が決して請求しない場合は、彼らが請求するまで（または、それを管理する助成/貢献契約に基づいて正式に放棄されるまで—一方的にゼロにしてはいけない）負債として残る。
貢献者がステーブルコインではなく変動トークンで支払われている場合は、各発生額にさらに1行追加する：トークン数量と、その仕訳のタイムスタンプにおける米ドル相当のFMVを両方記録する。トークン建ての負債（オンチェーンで実際に何を負っているかを知るため）と、法定通貨建ての費用（損益計算書や税金源泉徴収計算のため）の両方が必要になるからである。
よくある間違い
- 引き出しを費用として計上すること。 これは最も一般的なエラーである。受取人が残高を請求しない期間ごとに費用を過小評価し（そして運転資金を過大評価し）、最終的に彼らが引き出した期間に、誤解を招くほど大きな費用を一括計上することになる。
- レート変更ごとに新しい負債勘定を開設すること。 1年間に4回給与が調整された貢献者は、勘定科目表に4つの明細項目を散らかすべきではない。既存の発生額を修正する。
- プロトコル手数料を無視すること。 Superfluidの清算人メカニズムや、ストリーム作成・終了時のプロトコルレベルの手数料は、たとえ少額でも実際の費用であり、台帳に計上すべきである。これらは自動的に差し引かれ、簿記係が気付く別個の取引として表示されないため、見逃しやすい。
- ストリーミングプラットフォームを完全な給与システムとして扱うこと。 SablierとSuperfluidは継続的にお金を移動させる。どちらも税務申告書の作成、源泉徴収の計算、または労働者区分の処理を行わない。ほとんどのチームは、ストリーミングレイヤーをRequest FinanceやTokuのようなコンプライアンスツールと組み合わせるか、W-2従業員には従来の給与プロバイダーと組み合わせ、コンプライアンス負荷が軽い貢献者の手当や助成金には、生のプロトコルストリームを予約する。
- 支払不能のエッジケースを忘れること。 Superfluidの送信者バッファが枯渇し、清算人がストリームを強制終了した場合、それは帳簿に反映すべきイベントである。最終発生額は清算タイムスタンプで停止し、簿記係がたまたまストリームが停止していることに気付いた日付ではない。
なぜ監査証跡が実際には過小評価されているメリットなのか
変動性と清算リスクが注目を集めるが、財務チームにとっての本当の利点は、すべてのストリームイベント（開始、レート変更、一時停止、引き出し、キャンセル）が、タイムスタンプとブロック番号を持つ不変のオンチェーン取引であることである。これは、簿記係がそれを記録したかどうかにかかわらず存在する、完全で改ざん防止された給与台帳である。これは、手動の暗号資産給与を悩ませる仮勘定の推測ゲームを排除する（「あの貢献者に10月の支払いを実際に送っただろうか、それとも取引は静かに失敗したのか？」）。
その利点は、自分の帳簿がチェーンを反映し、矛盾しない場合にのみ効果を発揮する。プレーンテキストでバージョン管理された台帳は、ここに自然に適合する。インデクサーやサブグラフからストリームイベントを直接読み取り、対応する発生仕訳を台帳ファイルに追加するスクリプト（日次または月次）を作成でき、オンチェーン取引ハッシュは仕訳のメタデータにキャプチャされる。Beancount.ioは、まさにそれを提供する。プログラムで生成および監査可能で、gitに完全な履歴を持つプレーンテキスト会計フォーマットであり、「ストリーム未払金」負債勘定とそのレート変更が、財務省の他の部分と同様に検査可能である。この統合を構築している場合、ドキュメントではカスタム勘定科目構造とスクリプト化された仕訳生成について説明されており、Favaは、現金運転資金に対して発生額がリアルタイムで積み上がっていくのを実際に確認できるダッシュボードを提供する。これは、完全にリアルタイムを中心に構築された給与モデルにとって、正しい見方のように思える。