Open Paymaster は、ERC-4337 （Account Abstraction、アカウント抽象化）のPaymaster（ガス代を肩代わりするコントラクト）です。
Paymasterの体験価値は、ユーザーがネイティブ通貨（ETH）を持っていなくても、ERC-20でガス代を払ってトランザクションを通せるところです。一方で、Paymaster自体は「誰かが面倒を見る」前提になりやすいのがしんどいポイントです。
Open Paymasterは、ここを運営者の頑張りで解くのではなく、ユーザー/LP/リバランサーの3者インセンティブで自律的に回す方向に寄せています。この記事では、LP持分の実装（ERC-6909）ではなく、この「誰も運営しないのに回る」設計思想を中心に追います。
Paymasterは「運営しないと回らない」問題がある
Ethereum 互換チェーンでは「トークンは持っているのに、ガス代のネイティブ通貨がなくて何もできない」問題があります。例えばUSDCだけ持っているユーザーにとっては、まずETHを用意するところが一番の壁になりがちです。
Paymasterはここを解決できますが、支払い元のETHは減り続けます。ユーザーからはERC-20が入ってくるので、放置するとプールは次の方向に偏ります。
- ETH準備金は減る（ガス代として支払われる）
- トークン残高は増える（ユーザーから回収した分が溜まる）
つまりPaymasterは、UXの代わりに「誰がどのタイミングで、どうやってETHを補充するのか」という運用問題を背負います。
Open Paymasterの価値は、この運用問題を「誰かのボランティア」ではなく「市場参加者の得」で解こうとしているところにあります。
3者のインセンティブ構造（ここが一番大事）
Open Paymasterには、ざっくり3種類の参加者がいます。この3者が、それぞれの得で噛み合うように作っているのが肝です。
- ユーザー: ガス代をERC-20で払える（利便性）
- 流動性提供者（LP）: ETHを預けて手数料収益を狙える（リターン）
- リバランサー: 溜まったトークンを割引で買える（アービトラージ機会）
「運営が補充する」「運営が損失を被る」前提をできるだけ排除して、枯れそうなときほど市場参加者が"得を取りに来る"構造にしている、という理解が一番スッキリします。
どこがオンチェーンで、どこがオフチェーンか
Open Paymasterは、オンチェーンのコントラクトが本体です。
- Open Paymaster（オンチェーン、必須）
- ERC-4337のPaymasterとして、EntryPointに対して「このUserOperationは支払う」とコミットする
- ETHとトークンのプール（複数）を持つ
- ユーザーからトークンを回収し、ガス代をETHで支払う
- LPの持分（シェア）を管理する
また、便利のために以下がある、という位置付けです（なくても動く）。
- Paymaster Router（オフチェーン、任意）: どのプールが一番レートが良いかを選ぶ
- フロントエンド/SDK（オフチェーン、任意）: LPの入出金や、UserOperation構築を支援する
Open Paymasterの構成図（ざっくり）
まずは「何がどこにあって、誰がどこを叩くのか」を1枚でまとめます。
flowchart TB
subgraph Offchain[オフチェーン（任意）]
Wallet[ウォレット/SDK]
Router[Paymaster Router]
PythSvc[Pyth Price Service]
end
subgraph Onchain[オンチェーン（必須）]
EP[EntryPoint]
PM[Open Paymaster]
SA[Smart Account]
Pyth[Pyth Oracle Contract]
Pool[(ETH+Token Pool群)]
end
User[ユーザー] --> Wallet
Wallet -->|UserOperation| EP
EP -->|validate/postOp| PM
PM --> Pool
PM -->|価格参照/更新| Pyth
PythSvc -. 署名付き価格データ .-> Wallet
Router -. どのpoolが安い？ .-> Wallet
Wallet -. token/chain選択 .-> Router
LP[LP] -->|ETH deposit/withdraw| PM
Rebalancer[リバランサー] -->|ETH補充 + token回収| PM
ポイントは、オンチェーンで完結する「支払いの確定」と、オフチェーンに寄せる「便利機能」を分けているところです。 （RouterやSDKは無くても成立する、という設計を強く意識しています）
1つのUserOperationが通るまでの流れ
ERC-4337では、ユーザーの操作はUserOperation（ユーザーオペレーション）としてEntryPointに投げられます。
ここでPaymasterがやることは、大きく分けると2段階です。
- validate（前払いの確保）
- postOp（実費で精算）
ETHGlobalの説明では、Open Paymasterは以下のような手順で動きます。
sequenceDiagram participant User as User participant SA as Smart Account participant EP as EntryPoint participant PM as Open Paymaster participant Oracle as Pyth User->>SA: UserOperationを署名して送る SA->>EP: handleOps(UserOp) EP->>PM: validatePaymasterUserOp PM->>Oracle: 価格（トークン/ETH）を参照 PM->>PM: 必要なトークン額を見積もる PM->>PM: ユーザーからトークンを回収 EP->>EP: UserOpを実行（ガスはPaymasterのETH） EP->>PM: postOp PM->>Oracle: 価格を更新/再計算 PM->>User: 余りがあればトークンを返金 PM->>PM: プール会計（ETH減、トークン増）
validate/postOpは実装の詳細が色々ありますが、この記事の文脈だと次の理解で十分です。
- validateで「必要になりそうな最大額」を先に確保する（Paymasterは後出しで逃げられない）
- postOpで実際の消費に合わせて精算し、余りがあれば返金する
価格はどうやって決めるのか（Pythとpull oracle）
Open Paymasterは価格フィードにPyth Network を使っています。
Pythはpull oracle（プル型オラクル）で、「必要なときに価格更新データをオンチェーンに持ち込む」モデルです。
Paymasterの文脈だと、次の2点が効いてきます。
- validateで「今見えてる価格」で見積もりを出し、postOpで「より新しい価格」で精算する、という構造を取りやすい
- 価格更新の手数料（update fee）をどこが持つか、という設計が表に出る
ここは実装と運用のトレードオフが強いので、プロジェクトが今後どのチェーンでどう展開するかで見え方が変わりそうです。
リバランス機構の詳細（この記事の中核）
ユーザーがトークンでガス代を払うと、Paymaster側のプールは偏ります。
- ETH準備金は減る
- トークン残高は増える
このままだとETHが枯れて詰むので、誰かがETHを補充し、溜まったトークンを外に出す必要があります。
Open Paymasterでは、それを「リバランサーが割引価格でトークンを引き取れる」形でインセンティブ化しています。
flowchart LR U[ユーザー] -->|トークンで支払う| PM[Open Paymaster] PM -->|ETHでガス支払い| EP[EntryPoint] PM -->|トークンが溜まる| Pool[(Pool)] R[リバランサー] -->|ETHを補充| Pool Pool -->|割引でトークン払い出し| R
雑に言うと「プールの中に溜まったトークンを、割引で買って市場で売れるならリバランスが回る」という設計です。
なぜETHが枯れないのか
直感としては、ETHが減れば減るほど（= トークン在庫が積み上がるほど）リバランスの旨味が増えるようにして、放置しづらくしています。
結果として、
- ETHが減る -> トークンが溜まる
- トークンが溜まる -> 割引率が大きくなる
- 割引率が大きくなる -> リバランスが起きやすくなる
というフィードバックループになります。
割引率がどう機能するか（トークンが溜まるほど呼び水が強くなる）
割引率の考え方はシンプルで、「プールの偏りに応じて割引を厚くする」です。
- トークンがあまり溜まっていないとき: 割引は小さく、リバランスは急がない
- トークンが溜まりすぎたとき: 割引を大きくして、買い手（リバランサー）を強く呼び込む
これをやると、運営が「そろそろ補充しないと」と判断して手動で動く必要がなくなります。割引が大きい局面はアービトラージの匂いが強いので、見つけた人が勝手にETHを持ち込んでトークンを引き取っていきます。
プール残高の変化（ETHが減ってtokenが溜まる）
「ユーザーが使うほど詰みそうになる」構造を、状態遷移っぽく描くとこうなります。
stateDiagram-v2 direction LR [*] --> Healthy Healthy: ETHが十分 / tokenが少ない Healthy --> Drifting: UserOperationでETHが減る Drifting: ETHが減る / tokenが溜まる Drifting --> LowETH: さらにUserOperation LowETH: ETHが枯れかけ LowETH --> Healthy: リバランスでETH補充 Drifting --> Healthy: リバランスでETH補充 Healthy --> Healthy: LPがdeposit/withdraw
この「Drifting状態を放置すると枯れる」問題を、リバランサーのインセンティブで戻すのが肝です。
言い換えると、Open Paymasterが作っているのは「Paymaster運用」ではなく「枯れそうなときほど儲かる市場」だと思います。これが成立するなら、運営者は不要になります。
補足: LP持分の管理（ERC-6909はここにだけ出てくる）
この仕組みを現実に動かすには「LPが預けたETHが誰の持分か」を記録し、入出金や収益配分を計算できないといけません。
Open Paymasterでは、LP持分の台帳としてERC-6909 （Minimal Multi-Token Interface）を使っています。複数プール（複数トークン）を1つのコントラクト内でID管理できるので、プールごとにLPトークン用のコントラクトを増やすよりシンプルに整理できます。
ただ、ここは新規性というより実装の整理で、Open Paymasterの価値の中心は「誰が運営するのか問題」をインセンティブで潰しているところだと思います。
まとめ
Open Paymasterの面白さは、ERC-6909みたいな部品よりも「持続性を設計の中心に置いている」ところにありました。
- ユーザーはERC-20で払える（UX）
- LPはETHを預けて収益を狙える（リターン）
- リバランサーは割引でトークンを買える（アービトラージ）
- トークンが溜まるほど割引が大きくなり、リバランスが誘発される
個人的には、Paymasterに限らず「維持コストがかかる仕組み」を作るときは、まず"誰の得で回すのか"を設計の中心に置くのが大事だと思いました。ボランティア前提はだいたい続かないので、そこを最初から潰すのが肝です。