EIP-7702は、イーサリアムのPectraアップグレード（2025年）で導入された仕組みで、一般ユーザーのEOAウォレットが1つのトランザクションの範囲内で一時的に実行ロジックをスマートコントラクトに委任し、バッチトランザクション、ガス代の肩代わり、カスタム検証ロジックなど従来コントラクトアカウントだけが持っていた能力を獲得できるようにする。しかしプロトコルレベルではアドレスは常にEOAの身分を保持し、実際にコントラクトアカウントに変わることはない。これは従来の明確に分かれていたEOA対コントラクトの区分とは完全に異なる。
この仕組みが存在するのは、ユーザーエクスペリエンス上の根本的な矛盾を解決するためだ。スマートコントラクトウォレットはバッチトランザクション、ソーシャルリカバリー、ガス代の肩代わりなどより良い体験を提供するが、従来これらの機能を享受するには実際にコントラクトアカウントをデプロイする必要があり、それは移行、再設定、さらには使用習慣の再学習を意味した。EIP-7702は既存のEOAアドレスがどこにも移行せずに直接これらの能力を借りられるようにし、スマートアカウント機能の採用障壁を大幅に下げる。これが、アカウント抽象化を主流への普及に押し進める重要な一歩と見なされている理由でもある。
実際の運用では、ユーザーのEOAが特殊な委任承認（authorization）に署名し、次に行うトランザクションでどのコントラクトの実行ロジックを借りるかを指定する。この委任は1回限り有効にすることも、取り消されるまで継続的に有効にすることもできる。分析者がアドレスが現在この仕組みを使用しているかを判断するには、アドレスにバイトコードがデプロイされているか（EOAの場合通常は空）を見るだけでは不十分で、トランザクション自体に委任承認の署名データが含まれているかを確認する必要がある。これは「まずアカウントの状態を確認し、その後トランザクションの解釈方法を決める」という従来のワークフローを完全に逆転させ、「まずこのトランザクションに委任があるかを確認し、その後アカウントのその時点での行動能力を理解する」ものになる。
読者にとっての実際的な影響は、オンチェーンのラベリングシステムやウォレット分類を使ってトランザクションの背後にあるリスクやアイデンティティを判断している場合、EIP-7702の普及が進むにつれて「これはEOAだから個人ユーザーのはずだ」という前提はもはや信頼できないということだ。EOAとラベル付けされたアドレスが、その特定のトランザクションでコントラクトアカウントと同じくらい複雑なロジックを実行することは十分にありうる。オンチェーンの調査やリスク評価を行う際は、アカウントレベルの静的な分類だけに頼るのではなく、個々のトランザクションレベルで委任承認が発動されたかを確認することが、そのトランザクションが発生した瞬間の行動能力とリスクプロファイルを本当に理解する唯一の方法だ。
EIP-7702以前、イーサリアム上のアドレス分類は比較的シンプルだった。外部所有アカウント（EOA、秘密鍵によって制御される、ユーザーウォレットの標準形式）とコントラクトアカウント（コードによって制御され、デプロイ後はロジックが固定される）だ。ほぼすべての分析ツールとラベリングシステムは、最初に同じ問い——「これはEOAかコントラクトか」から始まる。両者ができることや、トランザクションの解釈方法が完全に異なるからだ。
イーサリアムの2025年Pectraアップグレードの一部であるEIP-7702は、メインネットで稼働を開始した後、この二分法の安定性を根本から崩した。これは既存の任意のEOAが、1つのトランザクションの範囲内で自分の実行をスマートコントラクトに一時的に委任できるようにする。この委任関係はトランザクション完了後も継続する場合もあれば終了する場合もあるが、重要なのは、プロトコルレベルではこのアドレスは最初から最後までEOAのままであることだ。新しいコントラクトをデプロイすることもなく、自分自身をコントラクトアカウントに変換することもない。単にコントラクトのような能力を「借りる」だけだ。ユーザーは新しいアドレスに移行する必要も、何かを再デプロイする必要もない。
従来のアドレスラベリングシステムは、あるアドレスがコントラクトかどうかを、そのアドレスの下にバイトコードがデプロイされているかどうかで判断するのが一般的だった。EIP-7702が有効になった後、「EOA」とラベル付けされたアドレスが、一部のトランザクションでバッチトランザクションを実行したり、ペイマスターを通じて他者にガス代を払ってもらったり、カスタムの検証ロジックを適用したりすることが完全に可能になる。これらは元々コントラクトアカウントだけが持つ行動特性だった。「まずEOA/コントラクトを判断し、その後どう解釈するかを決める」という古いロジックに依存している分析ツールは、コントラクトのように振る舞うがラベルにはEOAと書かれているという矛盾した結果を見ることになる。
これは単なる分類上の美観の問題ではなく、オンチェーンのフォレンジックや資金フロー追跡の実務作業に直接影響する。例えば、研究者は過去、「このアドレスはコントラクトである」という事実を、背後にマルチシグやプログラムされたロジック、あるいは取引所のホットウォレットのようなインフラがある可能性のシグナルとして扱っていた。今では、コントラクトのように振る舞うアドレスが、単にEIP-7702を使ってスマートアカウントの機能を一時的に借りている一般ユーザーである可能性もある。両者がオンチェーンに残す痕跡は非常に似ているが、その背後にある実際の管理者とリスクプロファイルは完全に異なる。プログラマブルなリカバリーメカニズムやセッションキーの委任——かつては新しいコントラクトをデプロイしなければ実現できなかった機能——も、永続的な新しいアカウントを作成せずに動作するようになり、かつてコントラクト型のリカバリーメカニズムを追跡するために使われていた手法が、こうしたアドレスでは単純に機能しなくなっている。
あるEOAが現在EIP-7702の委任機能を使用しているかどうかを判断するには、分析者はそのアドレスにバイトコードがデプロイされているかという単一の指標に頼るのではなく、そのトランザクション自体に委任承認の署名データが含まれているかを確認する必要がある。これは判断ロジックを「アカウントレベルの静的な状態を見る」ことから「トランザクションレベルの動的な委任記録を見る」ことへとシフトさせる。バルクラベリングシステムに依存する分析プラットフォームにとって、これは既存のEOA/コントラクトの二元分類ルールを、「このトランザクションが一時的な委任を発動したか」をトランザクション単位で判断できるように再設計する必要があることを意味する。そうしなければ、EIP-7702の採用率が上がるにつれてラベリングの精度は低下し続ける。