今回報告されたNotional Financeの事案は、典型的な担保不足ではないとみられている。セキュリティ研究者らの暫定的な再構成によれば、極端に大きいfCash負債を作成した後、プロトコルがフリー担保を計算する経路でその値をuint128に縮小変換したため、負債がゼロとして扱われたという。負債がこの重要な判定時点で記録上ゼロになれば、本来は出金できない口座でも健全に見え、資産を引き出せる可能性が生じる。 416

ただし、この説明はオンチェーン監視とセキュリティ研究者の報告に基づくもので、プロトコル側の公式ポストモーテムではない。資金移動自体はブロックチェーン上で追跡できる一方、決定的な呼び出し順序、被害の全容、対策の状況は、当時の報道では確認されていなかった。 34

何が起きたのか：巨大な負債が担保計算で「ゼロ」になった

Notional V1では、将来の現金支払い義務をfCashとして表現していた。CertiKの公開アラートによると、攻撃者はmintfCashPair()を2回実行して、-2^128の負債を作成した。この値はフリー担保の評価中にunsafeなuint128変換を受け、0へ切り詰められたとされる。 16

報告された攻撃の流れを、実務的に整理すると次の通りだ。

1. 極端に大きいマイナスのfCashポジションを作る：攻撃者は、128ビットの符号なし整数へ縮小した際に、負債の表現が失われ得る境界値の負債を生成した。 416
2. 担保評価を実行させる：エスクローの会計処理が、この負債をunsafeにuint128へダウンキャストしたと報告されている。
3. チェック上で負債が消える：本来なら巨額のマイナス債務として扱われるべき値が、計算上はゼロになった。 46
4. 出金条件を通過する：フリー担保の会計から負債が抜け落ちた結果、口座がエスクロー内の流動性の高いステーブルコインを引き出せる状態に見えた可能性がある。 46

したがって、これは単に「整数オーバーフロー」と呼ぶより、縮小変換と会計不変条件の破綻として理解する方が正確だ。報告された決定的な影響は、担保不足の出金を止めるはずの評価経路において、マイナスの負債がゼロへ変わった点にある。 416

流出したと報じられた資産

オンチェーン分析に基づく報道では、約69,257 DAIと1,650,824 USDC、合計で約172.8万ドルが流出したとされる。これらは約689.2 ETHに交換され、その後Tornado Cashへ入金されたと報じられた。 215

報道で特定された対象コントラクトは、Notional Financeのエスクロー0x9abd0b8868546105F6F48298eaDC1D9c82f7f683。ある報道によれば、アドレス末尾がCe38のウォレットから、2026年9月3日23時58分47秒（UTC）に準備取引が行われ、およそ3分後の9月4日未明に資金流出取引が実行された。 1723

調査者は、資金移動に関連するとして次の2つのEthereumアドレスを公表した。

• 0xC954…De69
• 0xDaCC…Ce38

ただし、これはオンチェーン調査における関連付けであり、個人・組織・最終的な管理者を特定するものではない。 11

ETHへの交換とTornado Cashが回収を難しくした理由

DAIとUSDCからETHへの交換により、資金追跡・回収の局面は変わった。ステーブルコインの移動はEthereum上で明確に追跡できる一方、ETHへ替えられると資産の形が変わる。さらに、報じられたTornado Cashへの入金は、取引の送信元・宛先・相手方の結び付きを難しくするプライバシー層を追加した。 229

これはブロックチェーン分析が不可能になるという意味でも、後の引き出しを誰が管理したかを証明するものでもない。ただ、資金がミキサーに入った後は、悪用されたエスクローから後続の受取先までを資産単位で直接たどることが、大幅に難しくなる。 29

当時、何が未解明だったのか

報道時点ではNotional側から公のインシデント対応が出ておらず、重要な点が未確認のままだった。

• 技術的な根本原因と、攻撃の完全な呼び出しフロー
• 報告された取引が、影響を受けたコントラクト・口座・資産のすべてだったか
• スワップ手数料や後続の送金を含む最終的な損失額
• 一時停止、アップグレード、補償、資金回収の選択肢
• 攻撃者の身元、および公表された2アドレス以外にも同一管理下のウォレットがあったか 3411

このため、原因の説明は有力な初期分析として扱うべきであり、監査済みのポストモーテムや公式事故報告の代わりにはならない。

レガシーDeFiコントラクトへの教訓

古いコントラクトは、製品ロードマップの中心ではなくなったからといって低リスクになるわけではない。資産を保管している、あるいは発行・決済・担保・出金のフローにアクセスできる限り、現役の金融システムとして攻撃対象であり続ける。

今回報告されたNotional V1の問題は、プロトコル開発チームにとって、少なくとも次の対策を組み合わせて検証する必要性を示している。

• 安全に表現できない値を明示的に拒否し、チェック付きの縮小変換を使う。
• 2^128のような数値境界で、符号付き負債、決済、担保計算をテストする。
• 支払い能力と資産保存のルールを不変条件として実装し、複数回の呼び出し連鎖でも検証する。
• 発行、決済、出金を想定外の順序で組み合わせられる、特権的または特殊な呼び出し経路がないか確認する。
• 本来のコンテキスト外で危険になり得る関数について、呼び出し元と呼び出しフローを制限する。

DeFiでは、表現形式や認可の小さな欠陥が、流動資産を持つ出金経路に到達した瞬間、全損規模へ拡大し得る。防御の要点は個々の関数を監査するだけでなく、到達可能なあらゆる呼び出し順序で会計上の不変条件が保たれることを示す点にある。

今回報告されたNotional Financeの事案は、典型的な担保不足ではないとみられている。セキュリティ研究者らの暫定的な再構成によれば、極端に大きいfCash負債を作成した後、プロトコルがフリー担保を計算する経路でその値をuint128に縮小変換したため、負債がゼロとして扱われたという。負債がこの重要な判定時点で記録上ゼロになれば、本来は出金できない口座でも健全に見え、資産を引き出せる可能性が生じる。 416

ただし、この説明はオンチェーン監視とセキュリティ研究者の報告に基づくもので、プロトコル側の公式ポストモーテムではない。資金移動自体はブロックチェーン上で追跡できる一方、決定的な呼び出し順序、被害の全容、対策の状況は、当時の報道では確認されていなかった。 34

何が起きたのか：巨大な負債が担保計算で「ゼロ」になった

Notional V1では、将来の現金支払い義務をfCashとして表現していた。CertiKの公開アラートによると、攻撃者はmintfCashPair()を2回実行して、-2^128の負債を作成した。この値はフリー担保の評価中にunsafeなuint128変換を受け、0へ切り詰められたとされる。 16

報告された攻撃の流れを、実務的に整理すると次の通りだ。

1. 極端に大きいマイナスのfCashポジションを作る：攻撃者は、128ビットの符号なし整数へ縮小した際に、負債の表現が失われ得る境界値の負債を生成した。 416
2. 担保評価を実行させる：エスクローの会計処理が、この負債をunsafeにuint128へダウンキャストしたと報告されている。
3. チェック上で負債が消える：本来なら巨額のマイナス債務として扱われるべき値が、計算上はゼロになった。 46
4. 出金条件を通過する：フリー担保の会計から負債が抜け落ちた結果、口座がエスクロー内の流動性の高いステーブルコインを引き出せる状態に見えた可能性がある。 46

したがって、これは単に「整数オーバーフロー」と呼ぶより、縮小変換と会計不変条件の破綻として理解する方が正確だ。報告された決定的な影響は、担保不足の出金を止めるはずの評価経路において、マイナスの負債がゼロへ変わった点にある。 416

流出したと報じられた資産

オンチェーン分析に基づく報道では、約69,257 DAIと1,650,824 USDC、合計で約172.8万ドルが流出したとされる。これらは約689.2 ETHに交換され、その後Tornado Cashへ入金されたと報じられた。 215

報道で特定された対象コントラクトは、Notional Financeのエスクロー0x9abd0b8868546105F6F48298eaDC1D9c82f7f683。ある報道によれば、アドレス末尾がCe38のウォレットから、2026年9月3日23時58分47秒（UTC）に準備取引が行われ、およそ3分後の9月4日未明に資金流出取引が実行された。 1723

調査者は、資金移動に関連するとして次の2つのEthereumアドレスを公表した。

• 0xC954…De69
• 0xDaCC…Ce38

ただし、これはオンチェーン調査における関連付けであり、個人・組織・最終的な管理者を特定するものではない。 11

ETHへの交換とTornado Cashが回収を難しくした理由

DAIとUSDCからETHへの交換により、資金追跡・回収の局面は変わった。ステーブルコインの移動はEthereum上で明確に追跡できる一方、ETHへ替えられると資産の形が変わる。さらに、報じられたTornado Cashへの入金は、取引の送信元・宛先・相手方の結び付きを難しくするプライバシー層を追加した。 229

これはブロックチェーン分析が不可能になるという意味でも、後の引き出しを誰が管理したかを証明するものでもない。ただ、資金がミキサーに入った後は、悪用されたエスクローから後続の受取先までを資産単位で直接たどることが、大幅に難しくなる。 29

当時、何が未解明だったのか

報道時点ではNotional側から公のインシデント対応が出ておらず、重要な点が未確認のままだった。

• 技術的な根本原因と、攻撃の完全な呼び出しフロー
• 報告された取引が、影響を受けたコントラクト・口座・資産のすべてだったか
• スワップ手数料や後続の送金を含む最終的な損失額
• 一時停止、アップグレード、補償、資金回収の選択肢
• 攻撃者の身元、および公表された2アドレス以外にも同一管理下のウォレットがあったか 3411

このため、原因の説明は有力な初期分析として扱うべきであり、監査済みのポストモーテムや公式事故報告の代わりにはならない。

レガシーDeFiコントラクトへの教訓

古いコントラクトは、製品ロードマップの中心ではなくなったからといって低リスクになるわけではない。資産を保管している、あるいは発行・決済・担保・出金のフローにアクセスできる限り、現役の金融システムとして攻撃対象であり続ける。

今回報告されたNotional V1の問題は、プロトコル開発チームにとって、少なくとも次の対策を組み合わせて検証する必要性を示している。

• 安全に表現できない値を明示的に拒否し、チェック付きの縮小変換を使う。
• 2^128のような数値境界で、符号付き負債、決済、担保計算をテストする。
• 支払い能力と資産保存のルールを不変条件として実装し、複数回の呼び出し連鎖でも検証する。
• 発行、決済、出金を想定外の順序で組み合わせられる、特権的または特殊な呼び出し経路がないか確認する。
• 本来のコンテキスト外で危険になり得る関数について、呼び出し元と呼び出しフローを制限する。

DeFiでは、表現形式や認可の小さな欠陥が、流動資産を持つ出金経路に到達した瞬間、全損規模へ拡大し得る。防御の要点は個々の関数を監査するだけでなく、到達可能なあらゆる呼び出し順序で会計上の不変条件が保たれることを示す点にある。