ERC-4337 Paymasterの不正利用対策｜ガス代無料の予算を守る上限と止め方

あるサービスが、利用者のガス代を肩代わりする「ガス代無料」のキャンペーンを始めました。ところが無料枠は、アドレス単位で付けていました。使い捨てのアドレスが次々に作られ、枠が何度も使われます。販促と決済が同じ財布を使っていたので、決済に必要なガス代まで尽きてしまいました。

ERC-4337のPaymasterを本番で動かすなら、これは想定しておくべき被害です。では、予算をいくらにし、どこで止めればよいのか。考え方は、止めるまでに最悪いくら失うかから逆算することです。

そのうえで、次の3つを重ねて守ります。

• 肩代わりする操作を絞る
• 1件・利用者・期間・全体のそれぞれに予算の上限をかける
• 認証とレート制限、オンチェーンの検証、預託金の見張り

異常が起きたときにどう絞るか、どんな条件で再開するかも先に決めておきます。

ガス代の費用モデルはガスレストランザクションの経済性、AA全体の攻撃面はAAセキュリティリスクで扱っています。ここでは、Paymaster固有の運用の守り方を見ていきます。

予算は「止めるまでの最悪損失」から逆算する

予算の値は、「平均の単価×想定の件数」だけでは決まりません。許せる損失から逆算します。以下は計算の手順を示すための例で、金額は架空です。

1. 気づいてから止めるまでの最悪損失を出す：緊急停止までの検知時間を10分、ピーク時の要求を1分100件とします。止めるまでに、最大で10分×100件＝1,000件分を肩代わりし得ます。1件あたりのガス代を50円とすると、約5万円です。
2. 日次の予算を用途で分ける：日次予算30万円のうち、決済など止めている間も通す重要な操作に20万円、販促に10万円を割り当てます。それぞれ別のポリシー（または別のPaymaster）にします。
3. 販促の枠に自動の停止線を引く：上の最悪損失（約5万円）を、1回の事故で許せる上限とみなします。販促の枠は5万円を使った時点で自動で止め、担当者が確かめてから残りを開けます。
4. 重要な操作の枠は、件数と単価で守る：重要な操作の枠は止めずに通します。その代わり、1件の上限と、利用者ごとの1日の件数の上限を置きます。使うペースが普段の数倍になったら、販促の枠から先に止めます。

具体的な額はチェーンと業務で変わります。それでも、攻撃されたときにどこまで失ってよいかを先に決め、そこから枠と停止線を引く点は同じです。

全部のサービスが1つのPaymasterと1つの預託金を使っていると、冒頭の例のように、販促キャンペーンが荒らされただけで、決済のような大事な機能まで止まります。そこで、財布を分けます。

財布は少なくとも「本番の機能用」と「販促用」に分け、チェーンごと・リスクの高さごとにも分けます。財布に自動で補充する元の口座にも上限を付けます。補充元から無制限に送れる構成にすると、預託金が尽きる事故が、資金庫そのものが尽きる事故に広がるからです。

どんな形で費用を抜かれるか

損失の入り口は、大きく2つに分かれます。肩代わりの承認を悪用されるものと、実行後の精算に失敗するものです。

表の最後の行は、利用者からトークンでガス代を受け取る方式（ERC-20支払型）の話です。実行後にトークンを回収する方式では、回収に失敗すると、取引は取り消されてもPaymaster側にガス代の負担が残ることがあります。

Alchemyの公式FAQも、同じことを説明しています。チェーンの外での事前シミュレーションは、成功を保証しません。実行後のERC-20の移転に失敗すると、取引は取り消される（revert）が、ガス代は事業者が負担する、というものです（Alchemy Gas Manager FAQs）。

肩代わり型と徴収型では、同じ「失敗」でも損失の出方が違います。守りの考え方も分けて立てます。

ガス代を肩代わりする前に、4つの確認を順に通す

1. その人に提供してよいか：ログインの状態、キャンペーンの参加資格、契約プランなど、「誰に、何のために提供するか」をバックエンドで判定します。ウォレットアドレスだけで本人を見分けません。
2. その操作を肩代わりしてよいか：対象のチェーン、送り先のコントラクト、呼び出す関数、トークン、金額を許可リストと突き合わせます。何でも実行できる呼び出しデータ（calldata）に、肩代わりの署名をしません。
3. 予算の内側か：1件、利用者、ポリシー、日次・月次の上限をすべて当てはめます。ガス価格が異常なときは、承認を止めるか、利用者の負担に切り替えます。
4. チェーン上でも確かめる：肩代わりの署名を、このチェーン・このPaymaster・この依頼・この期間に限ったものにします。別のチェーンや期限後での使い回しを拒みます。署名に含める項目は後半にまとめています。

商用のサービスにも、何層かの制御があります。

• Alchemy Gas Manager：1件・送信者・ポリシー全体の金額／件数の上限、送信者の許可・拒否リスト、有効期間を設定できる（Create Policy API）
• Coinbase CDP Paymaster：肩代わりの対象のコントラクト・関数と、利用者別・全体の上限を設定できる（CDP Paymaster guide）

ただし、Alchemyは、要求をまとめて処理する都合で、実際の支出が設定上限をわずかに超える時間があり得ると明記しています。ですから、SaaSの上限だけを唯一の止め具にはしません。SaaSの上限とは別に、予算そのものを分けて上限をかけておけば、上限をすり抜けても失う額に天井ができます。

預託金が尽きると、何が止まるか

ERC-4337では、PaymasterがEntryPointへ預けた預託金から、利用者の依頼（UserOperation）の実費が引かれます。EntryPointは実行の前に、残高が最大の費用をまかなえるかを確かめます。足りなければ、そのPaymasterを使う依頼は拒否されます（ERC-4337仕様）。

つまり預託金は、ただの会計上の残高ではありません。ガス代無料の機能が動き続けるかを左右する、運転資金です。

誤解しやすい点が2つあります。

• 預託金とは別に、stake（検証の際に一定の主体へ求められる拘束資金）があります。stakeは利用者のガス代には使えません。厚くしても、預託金が尽きるのは防げません。
• Bundlerの事前シミュレーションは、無効な依頼を落とすのには役立ちます。しかし「有効ではあるが、事業者が負担したくない操作」までは判定しません。

どの操作を肩代わりするかの条件と予算の上限は、事業者が自分で決めて守るものです。

残高が減ってきたら、4段階で絞る

残高の状態は4つに分け、段階ごとに肩代わりの動き方を変えます。

段階ごとに運用の担当者がすることは、後半にまとめています。

少額の不正利用は、残高のアラートに届くまで長く続きます。そのため、見張るのは残高だけでは足りません。次の値も見ます。

• 肩代わりの要求数、承認率、送信者のうち新しい人の割合
• 1件あたりの費用、取り消し（revert）の率
• 送り先・関数ごとの費用、使うペース

残高は「ETHがいくらあるか」だけでなく、直近のペースで「あと何分持つか」を見積もります。SaaSの請求型では、EntryPointの残高が見えないことがあります。その場合は、ポリシーの利用額と請求の上限を、同じ状態の判定に使います。

止めた後、どう再開するか

攻撃された入り口を残したまま再開すると、新しい預託金もすぐに失われます。ですから、再開は補充して終わりではありません。次の順で進めます。

1. 対象のポリシーを止める
2. ログから、利用者・送り先・関数・肩代わりの署名をたどる
3. 漏れた鍵やAPIキーを交換し、過去の承認を期限切れにする
4. 限られた利用者と操作から再開する

本番の前に、何を試すか

• 同じ利用者、複数のアドレス、複数のIPからの連続した要求が、想定の上限で止まる。
• 許可外のコントラクト、許可された関数に見せかけたcalldata、別のチェーンでの署名の使い回しを拒否する。
• ガス価格の急騰、高いガス上限、実行の取り消し（revert）、実行後の処理（postOp）の失敗で、最大の損失を測る。
• SaaSのポリシーの停止、Bundlerの障害、署名サービスの停止、預託金の不足のとき、画面が再送を繰り返さない。利用者の負担か、はっきりした待機に移る。
• アラートから停止までの時間、停止の権限、補充の承認者、段階的な再開の判定者を訓練する。

拒否や予算切れで利用開始が止まった件数を、利用者の離脱と区別して数える方法はスマートウォレットの利用開始率を測るで、ガス代補助を事業KPIと総保有コストに結び付ける方法はAAの導入効果の測り方で扱っています。

Paymasterを使わない方がよいのは、どんなときか

次のような場合は、利用者がガス代を払う形のままの方が安全です。

• ガス代が使いやすさの壁になっていない
• 利用者を見分けられず、悪用の上限を決められない
• 24時間の見張りと、止める権限を用意できない
• 肩代わりの費用で、どこまで失ってよいかを事業側が決められない

小さく試すなら、自前のPaymasterより、上限の機能を持つSaaSを使う方法があります。実際の数字を取ってから、自社で運用する必要があるかを判断できます。スタック選定はAA開発スタックの選定2026を参照してください。

実装する人向けの詳細

ここからは、Paymasterと署名サービスを作る担当者向けの内容です。

EntryPointでの確認の流れ

EntryPointは実行前に預託金の残高が最大費用を賄えるかを確認し、PaymasterのvalidatePaymasterUserOpを呼びます。stakeは、検証時に共有ストレージへアクセスする主体へ求める拘束資金です。

肩代わりの署名に含める項目

署名にchain ID、Paymasterアドレス、UserOperation hash、有効期間、ポリシーの版を含め、別チェーン・別Paymaster・期限後の再利用を拒否します。操作の許可リストでは、送信先コントラクトと関数セレクタ（calldataの先頭で呼び出す関数を示す値）で照合します。費用の上限は、1 UserOperationごと、利用者ごと、ポリシーごと、日次・月次で適用します。

残高の状態ごとの運用

• 通常（Normal）：定期監視
• 制限（Constrained）：担当者へ通知、原因調査
• 緊急停止（Emergency）：ポリシー無効化、鍵の交換
• 復旧（Recovery）：監視強化、事後検証

XTELAができること

XTELAは、Paymasterの脅威モデル、肩代わり条件、署名の境界、予算の分け方、監視・縮退・復旧の手順を設計し、SaaSの比較、PoC、実装まで進めます。貴社が決めた事業条件と許容損失を、テストで確かめられるポリシーと停止線に落とし込むのが私たちの仕事です。設計のご相談はお問い合わせからどうぞ。

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool（2026年8月12日確認）
• ERC-4337 Docs: Security and Griefing Protection（2026年8月12日確認）
• eth-infinitism/account-abstraction（v0.9系、2026年9月24日確認）
• Alchemy Gas Manager: Create Policy（2026年9月24日確認）
• Alchemy Gas Manager FAQs（2026年9月24日確認）
• Coinbase CDP Paymaster guide（2026年9月24日確認）

資料の確認日

ERC-4337の仕様は2026年8月12日に、主要サービスの機能は2026年9月24日に確認しました。本文で引いたAlchemy Gas Manager FAQsの記述は2026年9月24日、Alchemy Create Policy APIとCoinbase CDP Paymaster guideの記述も2026年9月24日の確認です。