Entry Point

暗号資産におけるEntry Pointとは？

暗号資産の文脈でEntry Pointは一般に、ユーザーがブロックチェーン上の操作を開始する際に通るコントラクト、関数、またはインターフェースを指します。

アカウント抽象化では、Entry Pointは通常、ERC-4337で定義された中核的なEntryPointスマートコントラクトを指します。

EntryPointコントラクトは、スマートアカウントから送信された操作の検証、実行、ガス支払い、アカウントのデプロイ、決済を調整します。

公式のERC-4337仕様では、ユーザーが外部所有アカウントから通常のトランザクションを直接送信する代わりに、UserOperationと呼ばれるオブジェクトを送信する仕組みが説明されています。

バンドラーと呼ばれる特殊なネットワーク参加者がUserOperationを集め、通常のブロックチェーントランザクションを通じてEntryPointコントラクトに送信します。

EntryPointは各操作が承認されているかを確認し、ガスの支払い方法を決定し、該当するスマートアカウントを呼び出して、最終的なガス代を精算します。

EntryPointはウォレット、トークン、ブロックチェーン、秘密鍵、独立した暗号資産ネットワークではありません。

互換性のあるアカウント抽象化ウォレット、バンドラー、アカウントファクトリー、ペイマスター、アプリケーションが利用する共有スマートコントラクト基盤です。

ERC-4337とは？

ERC-4337は、コンセンサス層に新しいEthereumトランザクションタイプを導入せずに、プログラム可能なスマートアカウントを実現するアカウント抽象化規格です。

従来の外部所有アカウントでは、プロトコルで定められた署名とナンスのルールが使われます。

ERC-4337スマートアカウントでは、コントラクトコードによって独自の認証ロジックを定義できます。

これにより、マルチシグ承認、パスキー、復旧システム、セッション権限、支出上限、アクションの一括実行など、プログラム可能なウォレット機能に対応できます。

ERC-4337では独立したUserOperationのフローを導入し、最終的にはブロックに含まれる通常のトランザクションを通じて処理を確定します。

Ethereumのアカウント抽象化の概要では、ERC-4337がEthereumの基本コンセンサスルールを変更せずにスマートアカウント機能を提供すると説明されています。

EntryPointは、このシステムの各要素を結び付ける共有オンチェーンコントラクトです。

なぜEntryPointと呼ばれるのか？

ERC-4337の操作がスマートアカウントに入る際の主要な信頼済みゲートウェイであることから、このコントラクトはEntryPointと呼ばれます。

互換性のあるスマートアカウントは通常、信頼するEntryPointアドレスからのERC-4337検証・実行呼び出しのみを受け入れます。

バンドラーは、ウォレット所有者であるかのように任意のウォレット実行関数を呼び出すわけではありません。

代わりにUserOperationをEntryPointへ送信し、EntryPointが各スマートアカウントに自身の操作を検証させます。

この構造により、ブロックチェーントランザクションの支払い・送信者と、基礎となる操作を承認するアカウントが分離されます。

また、さまざまなスマートアカウント設計を処理するための標準化されたコントラクトインターフェースをバンドラーに提供します。

現在のEntryPointバージョンは？

2026年7月16日時点で、公式アカウント抽象化リポジトリはEntryPoint v0.9.0を最新リリースとして掲載しています。

公式のアカウント抽象化リリースページでは、v0.9のEntryPointアドレスを

としています。

リリースノートによると、v0.9は、実装が新機能を利用しない限り、既存のアカウントおよびペイマスターのインターフェースについてEntryPoint v0.7、v0.8とABI互換です。

ただし、バンドラーはそのUserOperationメンプールに参加する前に、新バージョンを理解する必要があります。

インフラが引き続き対応しているネットワークでは、旧バージョンのEntryPointも稼働を続け、操作を処理する場合があります。

ウォレットは、同じEntryPointバージョンに対応するバンドラー、ペイマスター、ファクトリー、スマートアカウント実装を使う必要があります。

バージョンを変更する前に、アドレス、ネットワーク、デプロイ済みバイトコード、コードハッシュ、リリースノート、セキュリティレポートを確認してください。

複数のEntryPointバージョンが存在する理由

EntryPointはスマートコントラクトとしてデプロイされるため、デプロイ後に変更できない場合、コードをその場で編集することはできません。

通常、新バージョンは新しい決定論的アドレスにEntryPointコントラクトをデプロイして導入されます。

ウォレットやインフラは、新しいコントラクトを検証してその挙動への対応を追加した後、移行できます。

この方法では、1人の管理者に既存シングルトンのコードを無制限に置き換える権限を与えずに済みます。

一方、移行期間にはアカウント抽象化インフラが複数バージョンに分断される可能性があります。

あるEntryPoint向けのUserOperationを、別バージョン向けであるかのように送信してはいけません。

選択したEntryPointアドレスは、操作ハッシュなど重要なセキュリティ計算に含まれます。

UserOperationとは？

UserOperationは、スマートアカウントが実行しようとするアクションを記述した構造化リクエストです。

UserOpと略されることもあります。

UserOperationは通常のEthereumトランザクションではありませんが、最終的にはバンドラーがEntryPoint宛ての通常トランザクションに含めます。

そのフィールドには、スマートアカウント、ナンス、実行データ、ガス上限、手数料上限、署名、任意のアカウントデプロイデータ、任意のペイマスター情報が含まれます。

現在のバージョンでは、オンチェーンにデータを渡す際に

というパック形式を使います。

EntryPointはこの情報に基づいて検証、実行、ガス精算を調整します。

データ形式が正しいだけでUserOperationが有効になるわけではありません。

スマートアカウント、EntryPoint、バンドラーのルール、選択したペイマスターのすべてが受け入れる必要があります。

UserOperationの主なフィールド

フィールドは、操作を検証・実行するスマートアカウントを示します。

フィールドはリプレイを防ぎ、複数の順序付き操作チャネルにも対応できます。

アカウントデプロイ用フィールドにより、未デプロイのスマートアカウントを最初の操作と同時に作成できます。

フィールドは、スマートアカウントが実行する呼び出しを記述します。

ガス関連フィールドは、操作が負担する検証、実行、その他の処理に上限を設定します。

手数料フィールドは、操作が許容する最大ガス価格と優先手数料を定義します。

ペイマスター用フィールドは、ガス代を負担する任意のコントラクトを指定します。

フィールドには、スマートアカウントの検証ロジックが解釈する認証データが含まれます。

スマートアカウントは別の安全な認証方法を実装できるため、署名は基本的な単一鍵署名に限られません。

UserOperationがEntryPointに届くまで

まずウォレットが、要求されたブロックチェーン上のアクションを記述するUserOperationを構築します。

ウォレットは適切なナンスを取得し、操作に必要なガスフィールドを見積もります。

スマートアカウントの認証システムが操作に署名するか、その他の方法で承認します。

ウォレットはアカウント抽象化用RPCメソッドを通じて、操作をバンドラーに送信します。

バンドラーは操作を受け入れる前に、検証ロジックをシミュレーションします。

受理された操作は、専用のUserOperationメンプールに入る場合があります。

バンドラーは複数の操作を選び、1つのブロックチェーントランザクションでEntryPointに送信します。

EntryPointはERC-4337のルールに従って操作を検証・実行します。

実行後、EntryPointは実際のコストを計算し、アカウントまたはペイマスターに請求したガス資金から、バンドラーが指定した受取人へ支払います。

バンドラーとは？

バンドラーは、UserOperationを収集、検証、グループ化して送信するアカウント抽象化の参加者です。

バンドルトランザクションをブロックチェーンへ送る際、バンドラーがネイティブネットワークのトランザクション手数料を支払います。

EntryPointがスマートアカウントまたはペイマスターのデポジットから操作コストを払い戻すことを見込んでいます。

ガスを消費しても支払いが行われない操作を拒否する必要があるため、重要な経済的要件が生じます。

通常、バンドラーは最初の受信から最終送信までの間にブロックチェーンの状態が変わるため、操作を複数回シミュレーションします。

標準化されたERC-7769 JSON-RPCインターフェースは、ウォレットとバンドラーがUserOperationをやり取りし、状態を取得するためのメソッドを定義しています。

バンドラーはスマートアカウントの所有者ではなく、アカウントが拒否する操作を承認できてはなりません。

handleOps関数

EntryPointの主要関数は

です。

パック形式のUserOperationの配列と、受取人アドレスを受け取ります。

オンチェーンにバンドルを送信するトランザクション内で、バンドラーがこの関数を呼び出します。

EntryPointは検証と実行の各段階を通じて操作を処理します。

必要に応じてアカウントのデプロイを確認し、ナンスを検証し、必要な事前入金額を計算し、アカウント検証とペイマスター検証を呼び出し、十分なガス資金があることを確認します。

続いてスマートアカウントを呼び出し、要求されたアクションを実行します。

処理後、実際のコストを計算し、徴収した手数料を受取人に送金します。

受取人は通常バンドラーが管理しますが、プロトコル関数では支払い先として任意のアドレスを指定できます。

検証と実行は別の段階

ERC-4337では、検証と操作の主な実行を分けています。

検証時にEntryPointは、アカウントが操作を承認しているか、ガス代を支払えるかを確認します。

実行時には、スマートアカウントが要求された呼び出しを実行します。

認証チェックに合格しても、アプリケーション呼び出しが失敗する場合があるため、この区別は重要です。

たとえば、スマートアカウントがトークン転送を正しく承認していても、必要なトークン残高がなければ転送に失敗することがあります。

検証や実行失敗でもガスは消費されます。

そのため、意図したアプリケーション上のアクションが成功しなくても、アカウントまたはペイマスターに請求される場合があります。

validateUserOp関数

ERC-4337スマートアカウントは、

という関数を実装します。

検証時にEntryPointがこの関数を呼び出します。

アカウントには、パック形式の操作、そのハッシュ、不足ガス資金に関する情報が渡されます。

アカウントは呼び出し元が信頼済みEntryPointであることを確認しなければなりません。

そのうえで、独自の認証ルールを操作に適用します。

単純なアカウントでは、1つの暗号署名を検証する場合があります。

高度なアカウントでは、複数の署名、パスキーの証明、復旧ガーディアン、セッションキーの権限、支出方針の確認などを要求する場合があります。

UserOperationを実行できる期間を制限する有効期間を返すこともできます。

スマートアカウントが正確なEntryPointを信頼する必要がある理由

EntryPointには、スマートアカウントの重要な検証・実行経路を呼び出す権限が与えられます。

そのため、スマートアカウントはEntryPointを装う信頼されていないコントラクトからの呼び出しを拒否すべきです。

誤ったアドレスを信頼すると、悪意あるコントラクトがナンス処理、ガス計算、呼び出し元の識別、実行順序に関する前提を迂回できる可能性があります。

ウォレット実装では、承認済みEntryPointバージョンをどのように認識するか定義する必要があります。

固定アドレスを1つだけ使うアカウントもあれば、アップグレード可能またはモジュール型のアカウントでは、制御された移行手順をサポートする場合があります。

新しいEntryPointの追加は、通常のインターフェース設定ではなく、セキュリティ上重要なウォレットアップグレードとして扱うべきです。

UserOperationハッシュとリプレイ防止

UserOperationハッシュは、認証に使われる重要なデータと操作を結び付けます。

ハッシュにはEntryPointアドレスとブロックチェーンのチェーンIDが含まれます。

これにより、あるEntryPointやネットワーク向けに作られた有効な操作が、別のものに自動的に再利用されるのを防ぎます。

スマートアカウントがハッシュに対して認証データを検証できるよう、基礎となる操作ハッシュから署名自体は除外されます。

現在のペイマスター署名設計では、ウォレットとペイマスターが並行して署名できるよう、別個のペイマスター署名もハッシュから除外される場合があります。

開発者は、選択したEntryPointバージョンの正確なハッシュ規則に従う必要があります。

ドメイン分離を誤ると、リプレイリスクが生じたり、正規の操作を検証できなくなったりする可能性があります。

EntryPointのナンス管理

EntryPointは、同じUserOperationが繰り返し実行されるのを防ぐためナンスを管理します。

ERC-4337では、192ビットのキーと64ビットの連番値からなる2要素ナンスを使います。

各キーは、1つのスマートアカウントにおける個別の順序付きチャネルとして利用できます。

これにより、すべての操作を1つの共通連番に押し込めず、通常操作、管理操作、その他の分類を管理できます。

関数は、送信者とナンスキーに対応する現在のナンスを返します。

バンドラーは操作を受け入れ、後に組み込む前にナンスを確認すべきです。

必要に応じて、スマートアカウントは追加のナンス制限を適用できます。

スマートアカウントの反実仮想デプロイ

ERC-4337ウォレットのアドレスは、スマートアカウントコントラクトがデプロイされる前に計算できる場合があります。

これは反実仮想アドレスと呼ばれます。

アカウント抽象化操作を初めて実行する前でも、計算済みアドレスに暗号資産を受け取れます。

最初のUserOperationには、ファクトリーと初期化データを示すアカウントデプロイ情報が含まれます。

EntryPointはSenderCreatorヘルパーを使ってファクトリーを呼び出し、想定されたアドレスにスマートアカウントを作成します。

デプロイ後のアドレスは、UserOperationの

フィールドと一致しなければなりません。

アカウントが存在せず、有効なデプロイ情報も操作に含まれない場合、検証は失敗します。

EntryPoint v0.9とinitCode

EntryPoint v0.9では、送信者アカウントがすでに存在する場合のデプロイデータの扱いが変更されています。

従来の挙動では、アカウントをデプロイする操作に限り、空でない

が想定されていました。

v0.9では、送信者コントラクトがすでに存在する場合、デプロイデータを無視して

イベントを発行できます。

これにより、未デプロイアカウントが異なるナンスチャネルを使った操作を並行して準備しやすくなります。

空でないデプロイデータが常にアカウントの最初の操作を意味する、とアカウントコードで想定してはいけません。

v0.9へ移行する開発者は、従来の前提に依存するロジックを確認してください。

ガスの事前入金

EntryPointを呼び出すトランザクションのネットワーク手数料は、バンドラーが支払います。

そのためEntryPointは、各UserOperationが最大想定コストを払い戻せることを確認する必要があります。

検証時に、操作のガス上限と手数料設定から必要な事前入金額を計算します。

スマートアカウントは、この目的でEntryPoint内にデポジットを保有できます。

デポジットが不足している場合、検証中にアカウントが追加のネイティブ通貨をEntryPointへ送金できることがあります。

ペイマスターが操作をスポンサーする場合は、ペイマスターのデポジットが使われます。

事前入金が不足すると、その操作はブロックへの取り込みに無効となります。

EntryPointのデポジット

EntryPointは、今後のUserOperationのガス代に使うデポジットを管理します。

スマートアカウントとペイマスターは、これらのデポジットにネイティブ通貨を追加できます。

関数は、指定したアカウントまたはペイマスターに資金を追加します。

EntryPointの

関数は、対象のガスデポジット残高を返します。

権限を持つ主体は、コントラクトのルールに従い、

で利用可能なデポジットを引き出せます。

デポジットは利回りを生む残高ではなく、トークン化された投資でもありません。

アカウント抽象化のガス精算に備えて保有される、事前入金済みのネイティブ通貨です。

ペイマスターとは？

ペイマスターは、選択したUserOperationのガス代を負担することに同意する任意のスマートコントラクトです。

アプリケーションがユーザーの操作を補助したり、別の手数料体系を適用したりできます。

ペイマスターはEntryPointのデポジットにネイティブ通貨を預けます。

検証時、EntryPointは

を呼び出し、ペイマスターがその操作の負担を受け入れるか確認します。

ペイマスターは、アカウント識別、コールデータ、期限、署名による承認、支出方針、その他の条件を評価できます。

コンテキストデータを返した場合、EntryPointは実行後にペイマスターの

関数を呼び出すことがあります。

検証に成功した後でアカウントのアプリケーション呼び出しがリバートしても、ペイマスターにはガス代が請求されます。

ペイマスターのデポジットとステークの違い

ペイマスターのデポジットとステークは目的が異なります。

デポジットはUserOperationのガス代を支払います。

ステークは、サービス妨害や評判の悪用を防ぐ仕組みの一部としてロックされます。

関数は、アンステークまでの待機期間を設定してステークをロックします。

ステークを引き出すには、まず

を呼び出し、待機期間が経過する必要があります。

関数は、引き出し可能な状態になったステークを払い戻します。

デポジット残高が大きくても、ステーク要件を自動的に満たすわけではありません。

ステークがあっても、スポンサー対象のガスを支払うデポジットの代わりにはなりません。

EntryPoint v0.9のペイマスター署名

EntryPoint v0.9は、独立した

値に対応します。

従来のフローでは、ウォレットがUserOperationに署名する前に、完全なペイマスターデータを待つ必要がある場合がありました。

新しい設計では、ペイマスターが対応していれば、ウォレット署名とペイマスター署名を並行して生成できます。

規定のエンコードでは、独立したペイマスター署名はUserOperationハッシュを変更しません。

これにより、スポンサー付き操作のユーザーフローで遅延を減らせる可能性があります。

利用する前に、ウォレット、ペイマスター、バンドラーのすべてがバージョン固有のエンコードを理解している必要があります。

EntryPointのステークとレピュテーション

ERC-4337の検証には、アカウントファクトリー、ペイマスター、署名アグリゲーター、その他のコントラクトが関わる場合があります。

悪意ある主体が、バンドラーのリソースを浪費させたり、操作がメンプールに入った後で無効化したりする可能性があります。

ステークにより、一部の主体は検証時のストレージアクセス範囲を広げられますが、その一方でレピュテーション上の不利益を受ける可能性があります。

バンドラーは、無効なバンドルや不正な挙動を繰り返す主体を監視できます。

具体的なオフチェーンのレピュテーション方針は、バンドラーごとに異なる場合があります。

ステークは特定の攻撃を行う動機を減らしますが、ペイマスターやファクトリーの信頼性を証明するものではありません。

UserOperationシミュレーションとは？

シミュレーションとは、バンドラーがUserOperationのEntryPoint検証通過を予測するために行うオフチェーン処理です。

ブロックチェーンの現在の状態に対して呼び出しとトレースを実行しますが、シミュレーションの変更は確定しません。

アカウント作成、ナンスの有効性、アカウントの認証、ペイマスターの承認、ガス資金、制限付き検証処理などを確認します。

通常、バンドラーは操作を初めて受信した時、バンドルに選ぶ時、バンドルを送信する直前にシミュレーションします。

別のトランザクションによって残高、デポジット、ナンス、コントラクトコード、その他関連状態が変わる可能性があるため、繰り返しのシミュレーションが必要です。

シミュレーションに成功しても、アプリケーションの実行が成功するとは限りません。

ERC-7562検証ルール

プログラム可能な検証には、通常のアカウント署名には同じ形で存在しないサービス妨害リスクがあります。

悪意あるアカウントが、不安定な状態に検証を依存させたり、バンドラーのリソースを大量に消費させたりする可能性があります。

ERC-7562検証ルールは、公開UserOperationメンプールの検証で使用されるオペコード、ストレージアクセス、その他の挙動を制限します。

バンドラーは操作を取り込む前に、オフチェーンでこれらのルールを適用します。

この制限は検証に適用され、アカウントの主な実行中に行われるすべてのアクションを制限するものではありません。

非公開または別のメンプールで受け入れられる操作には、標準の共有メンプールとは異なるポリシーが適用される場合があります。

UserOperationの実行

検証に成功すると、EntryPointはスマートアカウントを呼び出し、要求された操作を実行します。

アカウントは実装に従って

を解釈します。

操作は1つのコントラクトを呼び出す場合も、暗号資産を転送する場合も、複数のアクションをまとめて実行する場合もあります。

アプリケーション上のアクションが金融面で妥当かどうかをEntryPointが判断するわけではありません。

コントラクトのルールに従い、アカウント認証、ガス計算、実行を調整します。

正しく承認された操作でも、悪意あるトークン、安全でないコントラクト、不利な金融ポジションに関わる可能性があります。

IAccountExecuteインターフェース

スマートアカウントは、任意で

を実装できます。

このインターフェースは、現在のパック形式UserOperationとそのハッシュを受け取る

関数を提供します。

EntryPointは、元の実行データをアカウントに直接渡す代わりに、この関数を呼び出せます。

これにより、実行中にアカウントがより完全なUserOperation情報を確認できます。

実際の実行方法は、EntryPointバージョンとアカウントが対応するインターフェースによって異なります。

getCurrentUserOpHash関数

EntryPoint v0.9では、

が追加されます。

この関数を使うと、コントラクトは現在実行中のUserOperationのハッシュを照会できます。

この値を利用できるのは、該当する実行フレーム内だけです。

UserOperationの実行外では、規定のインターフェースに従ってゼロ値を返します。

この機能は、第三者コントラクトが実行動作を処理中の特定UserOperationに結び付けるのに役立つ場合があります。

実行フレーム外でゼロ値が返ったからといって、呼び出し元を信頼できる証拠として扱ってはいけません。

ガス精算と受取人

EntryPointは、各UserOperationの処理に伴うガスを計測します。

実際のコストと操作の手数料上限に従って、負担するアカウントまたはペイマスターに請求します。

徴収した手数料は、バンドラーが

呼び出しで指定した受取人に送られます。

これにより、ブロックチェーントランザクションを送信し、その費用を負担した主体に払い戻されます。

事前入金額のうち未使用分は、アカウントまたはペイマスターのEntryPointデポジットに残ります。

ガス見積もりを誤ると、操作が拒否されたり、ガス不足になったり、想定以上の資金が確保されたりする場合があります。

1つの操作の失敗でバンドル全体が壊れるか？

問題が判明するタイミングと使用するEntryPoint関数に応じて、検証失敗した操作は除外される場合も、バンドル送信全体がリバートする場合もあります。

そのため、バンドラーは送信前に操作を繰り返しシミュレーションします。

検証に合格した後でも、アプリケーションの実行がリバートする可能性があります。

実行がリバートした場合、通常、UserOperationは失敗として記録されますが、ガス代は引き続き支払われます。

状態変更によって後続操作が予期せず無効にならないよう、バンドラーはバンドルを慎重に構成する必要があります。

バンドルへの取り込みが要求された呼び出しの成功を意味すると決めつけず、UserOperationのレシートと成功イベントを確認してください。

EntryPointのイベント

EntryPointは、UserOperationの動作を確認できるイベントを発行します。

UserOperationイベントには、操作ハッシュ、送信者、ペイマスター、ナンス、成功状態、実際のガスコスト、使用ガス量を含められます。

アカウントデプロイイベントには、新しく作成されたスマートアカウントとそのファクトリーを記録できます。

デポジットおよび引き出しイベントは、事前入金済みガス残高の変化を記録します。

ステークイベントは、ステーキング、ロック解除、引き出しの動作を記録します。

新しいバージョンでは、無視されたデプロイデータやEIP-7702の初期化など、バージョン固有の動作を示すイベントが追加される場合があります。

インデクサーは、追跡対象のEntryPointバージョンに対応するイベント定義を使用する必要があります。

EntryPointとEIP-7702

EIP-7702は、外部所有アカウントがスマートコントラクトコードへの委任を承認できるようにします。

現在のERC-4337バージョンでは、この委任を利用して既存アドレスにアカウント抽象化機能を提供できます。

公式のEIP-7702仕様は、トランザクションレベルでの認証方式を定義しています。

ERC-4337バンドラーは、互換性のあるUserOperationバンドルを送信する際に必要な認証データを含められます。

EntryPointは、関連するハッシュ計算と初期化ロジックに委任先を含めます。

EIP-7702を使っても、委任先のアカウント実装、認証処理、EntryPointとの連携を安全に保つ必要があります。

EntryPoint v0.9の有効期間

スマートアカウントとペイマスターは、UserOperationの有効期間を制限できます。

従来のEntryPointの挙動では、こうした制限はタイムスタンプで表されていました。

v0.9では、規定のエンコードフラグを使うと、ブロック番号として解釈される有効期間にも対応します。

権限やアクションがすでにブロック高を基準に定義されているアプリケーションで役立つ場合があります。

バンドラーはエンコードを理解し、まだ有効でない操作や取り込み前に期限切れとなりそうな操作を含めないようにする必要があります。

EntryPointの決定論的デプロイ

公式EntryPointのデプロイでは、対応する互換ネットワーク上で同じバージョンを同じアドレスに配置できるよう、決定論的なコントラクト作成手法が使われます。

これにより、ウォレットやバンドラーの設定が簡素化される場合があります。

EntryPointコントラクト文書では、公式リポジトリがローカル環境や互換環境へのデプロイに固定のデプロイ用ソルトを使う仕組みを説明しています。

ただし、同じアドレスであることだけでは真正性を確認できません。異なるネットワークでは、コードやデプロイ履歴が異なる場合があります。

開発者は、サポートする各ネットワークでアドレスのバイトコードとコードハッシュを確認してください。

EntryPointとスマートアカウントの違い

EntryPointは、多数のスマートアカウントが利用する共有インフラです。

スマートアカウントは、資産を保有し、認証ルールを定義するユーザー固有のコントラクトです。

通常、EntryPointはユーザーのトークン残高を保管せず、スマートアカウントのアドレスに取って代わることもありません。

UserOperationを承認するかどうかは、スマートアカウントが判断します。

EntryPointは、共通の処理、ナンス、デプロイ、ガス、決済の枠組みを適用します。

EntryPointが正しく動作していても、スマートアカウントの脆弱性はそのアカウントに影響します。

広く使われているEntryPointバージョンの脆弱性は、それを信頼する多くのアカウントやペイマスターに影響する可能性があります。

EntryPointとバンドラーの違い

EntryPointはオンチェーンのコントラクトです。

バンドラーは、UserOperationを受け取り、EntryPointを呼び出すトランザクションを送信するオフチェーンの参加者です。

バンドラーはシミュレーションを行い、最初のネットワークトランザクション手数料を支払います。

EntryPointは、オンチェーンで正式な検証と精算を行います。

バンドラーが無効なスマートアカウント署名を有効にすることはできません。

ただし、バンドラーは操作の取り込みを遅らせたり拒否したりできるため、複数の互換送信経路を利用できるウォレットはメリットを得られる場合があります。

EntryPointとペイマスターの違い

EntryPointは操作を処理し、ガス代を精算します。

ペイマスターは任意で、特定のユーザーやアクションに代わって費用を支払うことに同意します。

ペイマスターはERC-4337の検証制限内で、独自のスポンサー条件を定義します。

十分なデポジットを保有する必要があり、ステークも必要となる場合があります。

有効な操作すべてをスポンサーするようEntryPointがペイマスターに強制することはありません。

スマートアカウント自体が有効でも、ペイマスターの停止や方針による拒否によってスポンサー付きフローが止まる場合があります。

EntryPointとアカウントファクトリーの違い

アカウントファクトリーはスマートアカウントのコントラクトをデプロイします。

未デプロイの送信者が有効な作成データを含む場合、EntryPointはSenderCreatorの仕組みを通じてファクトリーを呼び出します。

ファクトリーは想定されるアカウントアドレスを生成する必要があります。

ERC-4337のセキュリティ要件に従って、機密性の高い作成経路も制限しなければなりません。

スマートアカウントの実装、所有者、モジュール、復旧ルールをEntryPointが決定するわけではありません。

これらの特性は、ファクトリーと初期化データによって定まります。

EntryPointモデルのメリット

EntryPointは、多様なスマートアカウント設計に対し、バンドラーが共通して使えるインターフェースを提供します。

アカウントは、固定された署名方式だけに依存せず、プログラム可能な認証を定義できます。

最初のUserOperationと同時に、反実仮想アカウントをデプロイできます。

プログラム可能なポリシーに基づき、ペイマスターがガス代をスポンサーできます。

複数のユーザーアクションを、基礎となる1つのトランザクションにまとめられます。

ユーザーの認証と、ネットワークトランザクション手数料を支払うアカウントを分離できます。

コンセンサス層の変更なしで、互換ネットワークにデプロイできます。

EntryPointモデルの制約

EntryPointにより、追加のコントラクト、RPCメソッド、シミュレーション、ガスフィールド、インフラ上の役割が必要になります。

ウォレットは互換性のあるバンドラー、場合によってはペイマスターとも連携しなければなりません。

EntryPointのバージョンが異なると、流動性、ツール、メンプール対応が分断される可能性があります。

プログラム可能な検証にはサービス妨害リスクがあり、厳格なオフチェーンルールが必要です。

ガス見積もりは、基本的なアカウントトランザクションより複雑です。

ペイマスターが利用できない場合やリクエストを拒否した場合、スポンサー付き操作は失敗する可能性があります。

アカウント抽象化はウォレットの柔軟性を高めますが、フィッシング、悪意あるアプリケーション、安全でない承認、スマートコントラクトのバグをなくすものではありません。

EntryPointのセキュリティリスク

スマートアカウントやペイマスターから特別な権限を与えられるため、EntryPointは価値の高い共有依存要素です。

検証、ガス計算、デポジット、ステーキング、アカウント作成、実行に欠陥があれば、広範囲に影響する可能性があります。

開発者はコアコントラクトを安易に変更せず、監査済みの公式デプロイを使うべきです。

ウォレットは信頼するEntryPointのアドレスとバージョンを確認しなければなりません。

バンドラーは検証ルールとレピュテーションルールを一貫して適用する必要があります。

アカウントとペイマスターは、機密性の高いコールバックが信頼済みEntryPointから発信されたことを確認してください。

ファクトリーは、正しいSenderCreatorコントラクトからの呼び出しであることを確認する必要があります。

署名と認証のリスク

アカウント抽象化は柔軟な署名に対応しますが、柔軟性は安全な認証を保証しません。

脆弱なパスキー検証、不適切なマルチシグのしきい値、漏えいしたセッションキー、欠陥のある復旧モジュールは、意図しないUserOperationを承認する可能性があります。

アカウントは認証を、正しい操作ハッシュ、チェーンID、EntryPoint、ナンス、有効期間、意図した呼び出しに結び付ける必要があります。

承認を求める前に、ウォレットのインターフェースでバッチに含まれる呼び出しを明確に表示してください。

有効なスマートアカウント署名は、トークン承認や転送を含む複数のアクションを一度に承認する場合があります。

ペイマスターのリスク

ペイマスターは、制限的または中央集権的なスポンサー条件を適用する場合があります。

デポジット残高の低下、サービス停止、方針変更により、スポンサーを停止できます。

検証や会計に不備があれば、ペイマスターはデポジットを失う場合があります。

悪意あるユーザーが、有益なアクションを完了せずにペイマスターのリソースを消費しようとする可能性があります。

ペイマスター署名者が侵害されると、意図した方針を逸脱した操作を承認する場合があります。

ガスがスポンサーされているからといって、その操作が安全、または他の費用が一切かからないと考えてはいけません。

バンドラーのリスク

バンドラーはUserOperationを検閲、遅延、誤った価格設定、または破棄する可能性があります。

ガス見積もりや古い状態情報を返す場合もあります。

オンチェーン検証によってスマートアカウントは保護されますが、選択したバンドラーの信頼性が低ければ、ユーザー体験に問題が生じる可能性があります。

対応している場合、ウォレットはタイムアウト、操作の置き換え、手数料変更、代替バンドラーへの送信を適切に処理する必要があります。

バンドラーの保留中応答だけに頼らず、最終的なオンチェーンレシートを確認してください。

ガス見積もりのリスク

UserOperationでは、検証、実行、ペイマスター処理、バンドラーのオーバーヘッドに複数のガス上限を設定します。

上限が低すぎると、検証または実行に失敗する可能性があります。

不必要に高く設定すると、最終精算はプロトコルのルールに従い実際のコストを使うものの、より大きな事前入金が必要になる場合があります。

ネットワーク固有のデータコストは

に影響する場合があります。

EntryPointから直接確認できないEIP-7702の認証コストにも、追加の計算が必要になる場合があります。

ウォレットは、選択したEntryPointバージョンとネットワークに対応するRPCサービスを利用してください。

再入可能性と外部呼び出し

EntryPointは、スマートアカウント、ファクトリー、ペイマスター、署名アグリゲーター、アプリケーションコントラクトを呼び出します。

これらの外部呼び出しでは、任意のコントラクトコードが実行される可能性があります。

外部コードがリバートしたり、ガスを消費したり、再入を試みたりすることを前提に実装する必要があります。

スマートアカウントとモジュールは、EntryPoint経由の実行中に重要な状態を保護してください。

ペイマスターの事後処理ロジックでは、アカウントが要求したアクションの成功を前提にしてはいけません。

監査済みEntryPointを使っていても、独自のアカウント抽象化拡張には独立したセキュリティ分析が必要です。

開発者向けEntryPoint統合方法

まず対応バージョンを選び、各ネットワーク上の公式デプロイを確認します。

次に、スマートアカウントが承認済みEntryPointアドレスだけを信頼するようにします。

3つ目に、署名、ナンス、有効期間、資金処理を正しく行う

を実装します。

4つ目に、正しいUserOperationのパッキングとハッシュ規則を使います。

5つ目に、未デプロイおよびデプロイ済みアカウントのフローをテストします。

6つ目に、選択したEntryPointバージョンに対応するバンドラーを統合します。

7つ目に、操作のシミュレーション、置き換え、失敗レシート、ガス見積もりをテストします。

8つ目に、ペイマスター、ファクトリー、モジュール、アップグレード、復旧に関する権限を確認します。

9つ目に、悪意ある検証・実行コントラクトを使ってテストします。

10つ目に、公式リリース、監査、移行ガイダンスを継続的に確認します。

ユーザーがEntryPointに触れる場面

ほとんどのユーザーはEntryPointを手動で呼び出しません。

スマートアカウントウォレットがバックグラウンドでUserOperationを作成・送信します。

基礎となるブロックチェーントランザクションが作成される前に、アカウント抽象化操作のハッシュが表示される場合があります。

取り込み後、ブロックチェーンエクスプローラーでは、EntryPointの

を呼び出すトランザクションが表示される場合があります。

1つのトランザクションに、互いに関係のない複数のスマートアカウントの操作が含まれることがあります。

バンドル内のすべてのアクションが同じ結果になったと考えず、個別のUserOperationの結果を確認してください。

EntryPointトランザクションの例

Aliceがスマートアカウントを使い、1つの操作でトークンを承認して暗号資産ボールトに預け入れたいとします。

ウォレットは、両方の呼び出しを含むUserOperationを作成します。

アカウントの認証ロジックは、Aliceが設定した認証方法を使って操作を承認します。

ペイマスターは、その方針に従ってネットワークガスのスポンサーに同意します。

ウォレットは互換性のあるバンドラーに操作を送ります。

バンドラーは、アカウントとペイマスターの検証をシミュレーションします。

その後、他のUserOperationとともにAliceの操作を含め、EntryPointの

関数を呼び出します。

EntryPointはナンス、アカウントの認証、ペイマスターの承認、利用可能なガスデポジットを確認します。

スマートアカウントはトークン承認とボールトへの入金を実行します。

EntryPointは実際のガス代をペイマスターのデポジットに請求し、バンドラーの受取人に支払います。

ボールトの呼び出しがリバートした場合、Aliceの操作は失敗として記録されても、消費済みガスは支払い対象となります。

EntryPointでよくある間違い

EntryPointをユーザーのスマートアカウントと混同すること。

異なるEntryPointバージョンに対応するバンドラーへUserOperationを送ること。

デプロイ済みコードを確認せずEntryPointアドレスを信頼すること。

バンドルへの取り込みがアプリケーション呼び出しの成功を証明すると考えること。

ガスデポジットとペイマスターのステークを混同すること。

認証ロジックにチェーンIDとEntryPointアドレスを含めないこと。

シミュレーション成功を実行成功の保証とみなすこと。

EntryPointを名乗る任意の呼び出し元に、機密性の高いアカウント関数を許可すること。

スポンサー付きトランザクションなら、トークン請求や別の手数料が発生しないと考えること。

新しいEntryPointへアップグレードする際に、バージョン固有の挙動とセキュリティレポートを確認しないこと。

FAQ

ERC-4337のEntry Pointとは？

互換性のあるアカウント抽象化ウォレットのUserOperationを検証、実行、精算する中核的なスマートコントラクトです。

EntryPointはウォレットですか？

いいえ。スマートアカウントウォレット、バンドラー、ファクトリー、ペイマスターが使う共有インフラです。

EntryPointは暗号資産ですか？

いいえ。EntryPointはスマートコントラクトソフトウェアであり、独自トークンを必要としません。

最新のEntryPointバージョンは？

2026年7月16日時点で、公式アカウント抽象化リポジトリはEntryPoint v0.9.0を最新リリースとして掲載しています。

EntryPoint v0.9のアドレスは？

公式v0.9リリースのアドレスは

ですが、使用前にネットワーク、コード、公式セキュリティ情報を確認してください。

複数のEntryPointバージョンが共存できますか？

はい。ウォレット、バンドラー、ペイマスターが移行する間、旧版と新版が共存できます。

UserOperationとは？

送信者、ナンス、呼び出し、ガス設定、認証、任意のデプロイ情報またはスポンサー情報を含む、構造化されたアカウント抽象化リクエストです。

UserOperationはEthereumトランザクションですか？

いいえ。バンドラーが1つ以上のUserOperationを、EntryPoint宛ての通常のブロックチェーントランザクションにまとめます。

handleOpsの役割は？

UserOperationのバンドルを検証・実行し、徴収したガス代から指定された受取人に支払います。

誰がEntryPointを呼び出しますか？

通常、バンドラーがオンチェーンにUserOperationのバンドルを送る際にEntryPointを呼び出します。

UserOperationを承認するのは誰ですか？

スマートアカウントが独自の

ロジックで承認します。

バンドラーはアカウントの承認なしに資金を使えますか？

正しく実装されたスマートアカウントは、認証ルールを満たさない操作を拒否します。

EntryPointのデポジットとは？

今後のUserOperationのガス代を支払うため、EntryPoint内に事前入金されたネイティブ通貨です。

EntryPointのステークとは？

サービス妨害やレピュテーション対策の一環として、特にペイマスターなどがロックするネイティブ通貨です。

ペイマスターのデポジットとステークは同じですか？

いいえ。デポジットはガス代を支払い、ステークは別途、アンステークの待機期間を設けてロックされます。

ペイマスターとは？

選択されたUserOperationのガス代を支払うことに同意するコントラクトです。

ペイマスターを使うとすべての操作が無料になりますか？

いいえ。操作を拒否したり、利用条件を適用したり、別の方法で費用を回収したりする場合があります。

UserOperationのシミュレーションとは？

操作を送信する前に、EntryPointの検証に通るかどうかをバンドラーがオフチェーンで予測する処理です。

シミュレーションの成功は実行を保証しますか？

いいえ。アプリケーションの実行がリバートしたり、取り込み前にブロックチェーンの状態が変化したりする場合があります。

操作ハッシュにEntryPointアドレスが含まれる理由は？

あるEntryPointバージョン向けの認証が、別のコントラクトを通じてリプレイされるのを防ぐためです。

操作ハッシュにチェーンIDが含まれる理由は？

同じ署名済み操作が、別のブロックチェーンネットワークで自動的にリプレイされるのを防ぐためです。

EntryPointはスマートアカウントをデプロイできますか？

送信者アカウントがまだ存在しない場合、アカウント作成データとファクトリーを使ってデプロイを調整できます。

反実仮想スマートアカウントとは？

アカウントコントラクトがデプロイされる前に計算されるスマートアカウントアドレスです。

EntryPointはユーザーのトークンを保有しますか？

通常、トークンはユーザーのスマートアカウントが保有し、EntryPointはガス処理に関するデポジットとステークのみを保有します。

1つのEntryPointトランザクションに複数ユーザーを含められますか？

はい。バンドラーは、互いに関係のない複数のスマートアカウントのUserOperationを、1つの

トランザクションに含められます。

失敗したUserOperationでもガスを消費しますか？

はい。検証と実行失敗でもガスが消費され、負担するアカウントまたはペイマスターに請求される場合があります。

EntryPointはEIP-7702アカウントに対応しますか？

現在のEntryPointバージョンは、互換性のあるEIP-7702認証と委任アカウントのフローに対応しています。

EntryPoint v0.9の変更点は？

主な変更には、並行ペイマスター署名、ブロック番号による有効期間、デプロイデータの扱いの変更、現在のUserOperationハッシュ照会、追加の可観測性向上が含まれます。

プロジェクト独自のEntryPointをデプロイすべきですか？

本番ウォレットでは通常、レビュー済みの標準デプロイを使います。独自のローカルデプロイは主にテストと開発に利用されます。

EntryPointは安全ですか？

公式コントラクトは厳重にレビューされていますが、安全性は正確なデプロイ、バージョン、スマートアカウント、バンドラー、ペイマスター、ファクトリー、モジュール、統合コードにも左右されます。

まとめ

EntryPointは、ERC-4337アカウント抽象化の中核となるオンチェーンゲートウェイです。

バンドルされたUserOperationを受け取り、スマートアカウントの検証を調整し、必要に応じてアカウントをデプロイし、ガス資金を確認し、承認済みの呼び出しを実行して手数料を精算します。

バンドラーは操作をEntryPointに送信し、スマートアカウントは独自の認証ルールを管理します。

ペイマスターは、デポジットを維持し、プログラム可能な検証方針で操作を受け入れることで、ガス代をスポンサーできます。

EntryPointは、ナンスチャネル、デポジット、ステーク、操作イベント、その他の共有アカウント抽象化機能も管理します。

2026年7月16日時点で、公式アカウント抽象化リポジトリに掲載されている最新リリースはv0.9.0です。

バージョンの互換性を確保するには、ウォレット、バンドラー、ペイマスター、ファクトリー、アカウント実装が、選択したEntryPointデプロイで一致する必要があります。

開発者はアドレスとバイトコードを確認し、信頼済み呼び出し元の検査を保護し、正確なハッシュ規則に従い、操作をシミュレーションし、接続するすべてのコントラクトをレビューする必要があります。

スポンサー付きガスやプログラム可能なウォレットは利便性を高めますが、フィッシング、実行失敗、承認リスク、スマートコントラクトの脆弱性をなくすものではありません。

EntryPointを理解すると、暗号資産ユーザーは共有ERC-4337処理コントラクトと、それを取り巻くスマートアカウント、バンドラー、ペイマスター、アプリケーション上の操作を区別しやすくなります。