Originally published on 2026-01-23
Original article (Japanese): Open Paymaster: 誰も運営しないのに回るリバランス設計
Open Paymaster is a Paymaster contract that implements ERC-4337 (Account Abstraction).
The value of the Paymaster experience lies in the ability for users to pay gas fees using ERC-20 tokens, even if they do not possess the native currency (ETH). However, a challenging aspect is that the Paymaster often operates under the assumption that "someone is managing it."
Open Paymaster aims to address this by not relying on the efforts of an operator, but rather by creating a self-sustaining system driven by the incentives of users, liquidity providers (LPs), and rebalancers. This article will focus on this design philosophy of "operating without management," rather than the implementation of LP shares (ERC-6909).
The Problem of "Not Operating Without Management" in Paymasters
In Ethereum-compatible chains, there is a common issue where users may hold tokens but lack the native currency for gas fees, rendering them unable to perform transactions. For example, a user holding only USDC might find that acquiring ETH is their biggest hurdle.
While Paymasters can solve this issue, the ETH used for payments continues to decrease. As ERC-20 tokens flow in from users, if left unattended, the pool will become imbalanced in the following ways:
- The ETH reserves decrease (as they are paid as gas fees)
- The token balance increases (as tokens collected from users accumulate)
In other words, the Paymaster inherits the operational problem of "who will replenish the ETH, when, and how."
The value of Open Paymaster lies in its approach to solving this operational issue not through "someone's volunteer work," but by leveraging the benefits for market participants.
The Incentive Structure of Three Parties (This is the Most Important Part)
Open Paymaster includes roughly three types of participants. The key is that these three parties are designed to align their incentives.
- Users: Can pay gas fees with ERC-20 tokens (convenience)
- Liquidity Providers (LPs): Can deposit ETH and aim for fee revenue (returns)
- Rebalancers: Can purchase accumulated tokens at a discount (arbitrage opportunities)
By minimizing the assumptions of "management replenishing" and "management incurring losses," the structure encourages market participants to "come to take advantage" especially when the system is running low.
What is On-Chain and What is Off-Chain
Open Paymaster is fundamentally an on-chain contract.
- Open Paymaster (on-chain, mandatory)
- As an ERC-4337 Paymaster, it commits to "pay for this UserOperation" to the EntryPoint
- Holds multiple pools of ETH and tokens
- Collects tokens from users and pays gas fees in ETH
- Manages LP shares
Additionally, the following components are positioned as conveniences (they are optional and the system can function without them):
- Paymaster Router (off-chain, optional): Chooses which pool offers the best rate
- Frontend/SDK (off-chain, optional): Assists with LP deposits/withdrawals and constructing UserOperations
Overview of Open Paymaster's Architecture
First, let's summarize "what is where and who interacts with what" in a single diagram.
flowchart TB
subgraph Offchain[Off-chain (optional)]
Wallet[Wallet/SDK]
Router[Paymaster Router]
PythSvc[Pyth Price Service]
end
subgraph Onchain[On-chain (mandatory)]
EP[EntryPoint]
PM[Open Paymaster]
SA[Smart Account]
Pyth[Pyth Oracle Contract]
Pool[(ETH+Token Pool)]
end
User[User] --> Wallet
Wallet -->|UserOperation| EP
EP -->|validate/postOp| PM
PM --> Pool
PM -->|price reference/update| Pyth
PythSvc -. signed price data .-> Wallet
Router -. which pool is cheaper? .-> Wallet
Wallet -. token/chain selection .-> Router
LP[LP] -->|ETH deposit/withdraw| PM
Rebalancer[Rebalancer] -->|ETH replenishment + token collection| PM
The key point is the separation between "confirmation of payment" that is completed on-chain and "convenience features" that are handled off-chain. (The design strongly emphasizes that the Router and SDK are not necessary for the system to function.)
The Flow of a Single UserOperation
In ERC-4337, user actions are submitted to the EntryPoint as UserOperations.
The Paymaster's responsibilities can be broadly divided into two stages:
- validate (securing prepayment)
- postOp (settling actual costs)
According to explanations from ETHGlobal, Open Paymaster operates through the following steps:
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: Sign and send UserOperation
SA->>EP: handleOps(UserOp)
EP->>PM: validatePaymasterUserOp
PM->>Oracle: Refer to price (token/ETH)
PM->>PM: Estimate required token amount
PM->>PM: Collect tokens from user
EP->>EP: Execute UserOp (gas paid with Paymaster's ETH)
EP->>PM: postOp
PM->>Oracle: Update/recalculate price
PM->>User: Refund excess tokens if any
PM->>PM: Pool accounting (ETH decreases, tokens increase)
The details of validate/postOp have various implementation specifics, but in the context of this article, the following understanding is sufficient:
- validate secures the "maximum amount that may be needed" in advance (the Paymaster cannot back out later)
- postOp settles the actual consumption and refunds any excess
How is the Price Determined? (Pyth and Pull Oracle)
Open Paymaster uses the price feed from Pyth Network.
Pyth operates as a pull oracle, which brings price update data on-chain "when needed."
In the context of the Paymaster, two points are particularly relevant:
- The structure allows for estimating based on "the price currently visible" during validate and settling with "a more recent price" during postOp.
- The design of who bears the cost of the price update fee becomes apparent.
There is a strong trade-off between implementation and operation here, so the visibility may change depending on how the project expands across different chains in the future.
Details of the Rebalancing Mechanism (The Core of This Article)
When users pay gas fees with tokens, the Paymaster's pool becomes imbalanced.
- ETH reserves decrease
- Token balance increases
If this continues, the ETH will run out, and someone will need to replenish it while extracting the accumulated tokens.
Open Paymaster incentivizes this by allowing rebalancers to redeem tokens at a discounted price.
flowchart LR
U[User] -->|Pays with tokens| PM[Open Paymaster]
PM -->|Gas payment with ETH| EP[EntryPoint]
PM -->|Accumulated tokens| Pool[(Pool)]
R[Rebalancer] -->|Replenishes ETH| Pool
Pool -->|Tokens dispensed at discount| R
In simple terms, the design is such that "if accumulated tokens in the pool can be bought at a discount and sold in the market, rebalancing will occur."
Why ETH Does Not Run Out
Intuitively, the more ETH decreases (i.e., the more token inventory accumulates), the more attractive the rebalancing opportunity becomes, making it less likely to be ignored.
As a result:
- ETH decreases -> tokens accumulate
- Tokens accumulate -> discount rate increases
- Discount rate increases -> rebalancing becomes more likely
This creates a feedback loop.
How the Discount Rate Functions (The Stronger the Accumulation of Tokens, the Stronger the Incentive)
The concept of the discount rate is straightforward: "increase the discount according to the pool's imbalance."
- When tokens are not accumulating much: the discount is small, and rebalancing is not urgent.
- When tokens are accumulating excessively: increase the discount to attract buyers (rebalancers).
By doing this, the need for management to manually intervene and replenish is eliminated. Situations with a large discount strongly signal arbitrage opportunities, prompting those who discover them to independently bring ETH and redeem tokens.
Changes in Pool Balances (ETH Decreases and Tokens Accumulate)
The structure that makes it "seem like it will run out the more users use it" can be depicted as a state transition:
stateDiagram-v2
direction LR
[*] --> Healthy
Healthy: Sufficient ETH / Few tokens
Healthy --> Drifting: ETH decreases with UserOperation
Drifting: ETH decreases / tokens accumulate
Drifting --> LowETH: Further UserOperations
LowETH: ETH is running low
LowETH --> Healthy: ETH replenished through rebalancing
Drifting --> Healthy: ETH replenished through rebalancing
Healthy --> Healthy: LP deposits/withdraws
The key is to incentivize rebalancers to reverse the "Drifting state" before it runs out.
In other words, what Open Paymaster is creating is not "Paymaster operation" but rather a "market that becomes profitable when it is about to run dry." If this can be established, operators become unnecessary.
Additional Note: Management of LP Shares (ERC-6909 Only Appears Here)
To make this system operational, it is necessary to record "who owns the ETH deposited by LPs" and be able to calculate deposits, withdrawals, and revenue distribution.
Open Paymaster uses ERC-6909 (Minimal Multi-Token Interface) as a ledger for LP shares. This allows for ID management of multiple pools (multiple tokens) within a single contract, simplifying organization compared to creating separate contracts for LP tokens for each pool.
However, this aspect is more about implementation organization than novelty; the core value of Open Paymaster lies in its ability to eliminate the "who manages it" problem through incentives.
Conclusion
The interesting aspect of Open Paymaster lies not in components like ERC-6909 but in placing "sustainability at the center of design."
- Users can pay with ERC-20 (UX)
- LPs can deposit ETH and aim for returns
- Rebalancers can buy tokens at a discount (arbitrage)
- The more tokens accumulate, the larger the discount, triggering rebalancing
Personally, I believe that when creating systems that incur maintenance costs, it is essential to design around "who benefits from it operating." Relying on volunteers typically does not last, so addressing this from the outset is crucial.
Top comments (0)