はじめに
こんにちは！ブロックチェーン×AI Agentで自律経済圏を創るKomlock labでエンジニアをしている小原（@brto_0224）です。
XでEIP-7702のdelegateを悪用されて資産を抜かれた事例を見ました。EIP-7702のdelegateは「ガスレスとかバッチトランザクションに使うもの」くらいのイメージだったんですが、「実際何が起きてるのか、もう少しちゃんと理解したい」となったので、自分の理解のために整理した記事です。
Account Abstractionの全体像を俯瞰しつつ、EIP-7702のdelegateの仕組みを技術的に掘り下げます。
先に結論
- EIP-7702のdelegateはEOAにコード実行権限を付与する永続的な操作
- 秘密鍵が漏洩した状態で悪意あるdelegateを設定されると、資産が入った後にsweeperによって抜かれる可能性がある
- ERC-4337とEIP-7702は競合ではなく補完関係。用途で使い分ける
- エージェント向けには、秘密鍵直渡しではなくマスターウォレット＋セッションキーのような最小権限設計が基本になる
想定読者
- EIP-7702の「delegate」が何をしているのか知りたい人
- AIエージェントにオンチェーン操作をさせる設計を考えているエンジニア
- Account Abstractionの2026年時点の全体像を整理したい人
EIP-7702のdelegateとは何か
delegate = 「委任する」。EIP-7702の文脈では、EOAのコードスロットに「このコントラクトのコードを使え」というポインタを書き込むことを指します。これにより、EOAがスマートコントラクトのように振る舞えるようになります。ただし、そのロジックは常にそのEOAの資産とstorageを前提に動きます。
技術的な詳細
EIP-7702は新しいトランザクションタイプ（type: 0x04）を導入します。このトランザクションにはauthorization_listというフィールドがあり、以下の形式のタプルを含みます。
[chain_id, address, nonce, y_parity, r, s]
このタプルに対してEOAの秘密鍵で署名すると、EOAのコードスロットにdelegation indicatorが書き込まれます。
0xef0100 || address
これが書き込まれた後、そのEOAに対してコード実行が発生すると、addressにあるコントラクトのコードを読み込み、EOAのコンテキストで実行します。
重要なポイント
- 永続的：delegationは明示的に解除するまで残り続ける
- EOAのコンテキストで実行される：委任先コードはEOAのbalanceやstorageを前提に処理できる
-
解除にはEOA自身の署名が必要：
addressをゼロアドレスにしたauthorization tupleに署名してトランザクションを送る - chain_id=0で署名すると全チェーンで有効：EIP-7702の仕様上、chain_id = 0 は「all chains」として扱われるため、実装状況によってはクロスチェーンリプレイのリスクがある
解除方法
authorization_list: [{
chain_id: 1,
address: 0x0000000000000000000000000000000000000000,
nonce: <current_nonce>,
y_parity, r, s // EOAの秘密鍵で署名
}]
ゼロアドレスへのdelegationは、設定済みのdelegation indicatorを解除します。ただし、秘密鍵が漏洩している場合は攻撃者が再度delegateできるため、そのアドレスは使えなくなります。
被害事例：なぜ資産が抜かれるのか
ケース1：SoSoValue LP引き出し直後の資金流出（2026年5月）
SoSoValueでロックしていたUSSI/USDCのLPをクールダウン後に引き出したところ、資産がウォレットに戻った直後に抜かれた事例がXで報告されました。
Basescanで確認すると、被害者のアドレスにDelegated to:の表示が。つまり、被害者のEOAには既に悪意あるコントラクトへのdelegationが設定されていたということです。
攻撃の流れ
- 何らかの経路で秘密鍵、またはEIP-7702 authorization署名が攻撃者に渡る
- 攻撃者が被害者EOAを悪意あるsweeper contract（アドレスに入った資産を即座に別アドレスへ転送するコントラクト）へdelegateする
- 被害者が資産を引き出し、EOAに戻る
- delegateされたコードが実行され、資産が攻撃者アドレスへ転送される
ケース2：$1.54M フィッシング（2025年8月）
EIP-7702のauthorization署名をフィッシングで取得し、被害者のEOAにsweeper contractをdelegateした事例。一度delegateされると、そのアドレスに入る全ての資産が自動的に攻撃者に転送されます。
観測上、大半がsweeperに使われていた
GoPlus SecurityやWintermuteの調査として報じられた内容では、2025年時点で観測されたEIP-7702 delegationの97%以上が、脆弱なウォレットを探して資産を抜く同一コードのsweeper contractに関係していたとされています。
なぜこの攻撃が成立するのか
従来のApprove攻撃との違い
ERC-20のapprove攻撃は「特定のトークンを特定のアドレスが移動させてよい」という許可です。被害はapproveしたトークンに限定されます。
EIP-7702のdelegation攻撃はEOA自体のコード実行権限を奪います。
- 全資産にアクセスできる
- 将来入ってくる資産も自動で対象
- delegationが残っている限り永続的
- EOAのstorageを使うため、delegate先コントラクトの設計ミスがそのままアカウントのリスクになる
攻撃者が署名を取得する方法
- 秘密鍵の漏洩：マルウェア、フィッシングサイト、不正なブラウザ拡張
- フィッシングによるauthorization署名：「ウォレットアップグレード」「セキュリティ強化」に偽装してSET_CODEトランザクションの署名を要求
- chain_id=0の悪用：1つの署名で全EVM互換チェーンに適用される
防御策
以下はFireblocks、GoPlus Security等のセキュリティリサーチャーの分析をもとにまとめたものです。
ユーザー向け
-
Basescan/Etherscanでdelegation状態を確認する：アドレスに
Delegated to:が表示されていないか - 不審なトランザクション署名を拒否する：type 0x04（SET_CODE）トランザクションの署名要求は特に注意
- ホット/コールド分離：大きな資産はdelegationを設定しないコールドウォレットに
- delegation解除ツール
開発者向け
- delegation先は監査済みコントラクトのみ：EIP-7702専用に設計されたものを使う
- 既存のスマートコントラクトウォレットをdelegation先にしない：初期化ロジックのfront-running、storage collision等の脆弱性がある
- 最小権限の原則：delegation先コントラクトの機能は必要最小限にする
- ERC-7579モジュールで権限を分離：セッションキー、支出制限等をモジュールとして管理
Account Abstractionの全体像
ここまでEIP-7702のリスクを掘り下げましたが、AAは本来「EOAの制限を解消する」ための仕組みです。正しく使えば強力なセキュリティと柔軟性を実現できます。
そもそもAAが必要な理由
EOAは「秘密鍵で署名してトランザクション送信」しかできません。
- 鍵紛失でアカウント終了
- ガス代はネイティブトークンでしか払えない（ERC-20での支払い不可）
- マルチシグができない
- エージェントウォレット側でポリシーを設定しない限り、秘密鍵を渡す＝全権限を渡すになる
AAはウォレット自体をスマートコントラクトにして、ルールをコードで表現できるようにします。
ERC-4337：プロトコルを変えずにAAを実現する
2023年3月にEthereumメインネットで稼働。主要L2（Polygon、Arbitrum、Base等）で対応済みです。
仕組み
普通のトランザクションとは別の「UserOperation」オブジェクトを使い、Bundlerがまとめてチェーンに送信します。
できること
- セッションキー：期限・用途限定の鍵を発行してエージェントに渡せる（SDK層で実装）
- Paymaster：ガス代を別のアカウントに立て替えてもらえる
- バッチトランザクション：複数操作を1トランザクションにまとめる
- 支出上限・許可リスト：ウォレット自体に制御ルールを書ける
制約
新しいアドレスが必要。既存EOAとは別のアドレスになるので、「今のウォレットをそのまま使いたい」ケースには向きません。
EIP-7702：既存EOAにコントラクトのコードを持たせる
ERC-4337との使い分け
| ERC-4337 | EIP-7702 | |
|---|---|---|
| ウォレット | 新規スマートウォレット | 既存EOAにコードを付与 |
| アドレス | 変わる | 変わらない |
| delegation | なし（コントラクト自体がロジック） | EOAにコード実行権限を付与 |
| 向いている用途 | 常設のエージェント専用ウォレット | 既存ウォレットへの権限付与（解除まで永続） |
| セキュリティモデル | コントラクト自体が境界 | delegation先コントラクトが境界 |
| 移行コスト | 高い（新アドレス） | 低い（アドレスそのまま） |
この2つは競合ではなく補完関係です。
正しい使い方
EIP-7702のdelegationは危険だという話をしてきましたが、監査済みの信頼できるコントラクトに対して使う分には強力なツールです。
- バッチトランザクション（approve + swap を1トランザクションで）
- ガス代スポンサリング（ERC-4337のPaymasterと組み合わせて利用）
- セッションキーによる権限委任
- ソーシャルリカバリー
ERC-7579：モジュラーアカウント
ERC-4337の上に乗せる「プラグイン標準」です。ウォレットの機能をモジュールとして差し替えられます。
AIエージェント向けには「このトークンだけ」「1日あたりN USD以内」「このコントラクトへのcallのみ」といった細かい権限制御をモジュールとして実装できます。
MetaMask Delegation Toolkit
MetaMask Delegation Toolkitは、MetaMaskが提供する権限委任フレームワークです。EIP-7702とも組み合わせられ、既存EOAにもスマートアカウント的な権限管理を持ち込めます。
- delegator（委任者）がdelegation（権限）を発行
- delegate（受任者）がその権限を行使
- delegationはいつでもrevokeできる
- transitive delegation（権限の再委任）もサポート
AIエージェントに「1日100 USDC以内のswap」「特定のDEXへのcallのみ」といったスコープ付きdelegationを渡す用途に設計されています。
MPC：鍵を分割する別アプローチ
ERC-4337とは別の仕組みで、秘密鍵を複数のシェアに分割して保持します。
エージェント単独での署名が不可能になります。Coboのエージェントウォレットがこのアプローチを採用しています。
AAを実現するSDK
ZeroDev
ERC-4337とEIP-7702の両対応。Bundler・Paymasterインフラとセッションキー管理を提供。ERC-7579（モジュラーアカウント）対応。Kernelというスマートウォレット実装が中心。
Alchemy Account Kit
ERC-4337とEIP-7702の両対応。Bundler・PaymasterのインフラとSDK。エンタープライズ向け。
Safe（旧Gnosis Safe）
マルチシグウォレットの老舗。ERC-4337対応。EIP-7702用の新しいコントラクトも開発中（既存Safeコントラクトは7702と非互換）。企業・DAO向け。
Openfort
ゲーム・NFT向け。ERC-4337 + ERC-7579対応、AIエージェント向けセキュリティモジュール開発中。
2026年時点のトレンド
EIP-7702の光と影が明確になった
UXの改善は大きい一方で、delegationを騙し取るフィッシングが最大の脅威になっています。ウォレット側のUI改善（SET_CODEトランザクションの警告表示）が急務。
AIエージェント向けの最小権限設計が標準化
「エージェントに秘密鍵をそのまま渡さない」方向に設計が寄ってきています。セッションキー、タスク単位のポリシー、支出上限がデフォルト。
モジュラー化（ERC-7579）の実用段階
認証・実行・セキュリティをモジュールとして差し替える設計が実装レベルで広がっています。
観測上大半がsweeperだった問題への対応
ウォレットUIでのdelegation警告、Etherscan等のExplorerでの表示改善、delegation whitelistの導入が進んでいます。
まとめ
- EIP-7702のdelegateはEOAにコード実行権限を付与する永続的な操作。悪意あるdelegation先を設定してしまうと、署名1つで全資産へのアクセス権を渡したのに近い状態になる
- 防御の基本はdelegation先の検証と最小権限。監査済みコントラクトのみ、ホット/コールド分離
- ERC-4337とEIP-7702は補完関係。新規ウォレット vs 既存EOA拡張で使い分ける
- エージェント向けには秘密鍵直渡しではなく最小権限設計が基本
EIP-7702の被害事例だけを見ると怖くなりますが、問題はEIP-7702そのものというより、「EOAにコード実行権限を付与する」という操作の重さを、ユーザーが十分に理解できないまま署名してしまう点にあります。
delegation先の検証、最小権限、セッションキー、支出上限といった設計を組み合わせれば、AAはオンチェーンのUXとセキュリティを大きく改善するインフラになります。
Discussion