Tools: Open Paymaster: A Rebalancing Design That Operates Without Management

The Problem of "Not Operating Without Management" in Paymasters ## The Incentive Structure of Three Parties (This is the Most Important Part) ## What is On-Chain and What is Off-Chain ## Overview of Open Paymaster's Architecture ## The Flow of a Single UserOperation ## How is the Price Determined? (Pyth and Pull Oracle) ## Details of the Rebalancing Mechanism (The Core of This Article) ## Why ETH Does Not Run Out ## How the Discount Rate Functions (The Stronger the Accumulation of Tokens, the Stronger the Incentive) ## Changes in Pool Balances (ETH Decreases and Tokens Accumulate) ## Additional Note: Management of LP Shares (ERC-6909 Only Appears Here) ## Conclusion ## Reference Links 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). 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: 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. Open Paymaster includes roughly three types of participants. The key is that these three parties are designed to align their incentives. 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. Open Paymaster is fundamentally an on-chain contract. Additionally, the following components are positioned as conveniences (they are optional and the system can function without them): First, let's summarize "what is where and who interacts with what" in a single diagram. 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.) In ERC-4337, user actions are submitted to the EntryPoint as UserOperations. The Paymaster's responsibilities can be broadly divided into two stages: According to explanations from ETHGlobal, Open Paymaster operates through the following steps: The details of validate/postOp have various implementation specifics, but in the context of this article, the following understanding is sufficient: 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: 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. When users pay gas fees with tokens, the Paymaster's pool becomes imbalanced. 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. 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." 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. This creates a feedback loop. The concept of the discount rate is straightforward: "increase the discount according to the pool's imbalance." 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. The structure that makes it "seem like it will run out the more users use it" can be depicted as a state transition: 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. 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. The interesting aspect of Open Paymaster lies not in components like ERC-6909 but in placing "sustainability at the center of design." 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. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse COMMAND_BLOCK: 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 Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: 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 COMMAND_BLOCK: 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 CODE_BLOCK: 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) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: 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) CODE_BLOCK: 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) CODE_BLOCK: 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 Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: 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 CODE_BLOCK: 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 COMMAND_BLOCK: 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 Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: 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 COMMAND_BLOCK: 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 ETH reserves decrease (as they are paid as gas fees) - The token balance increases (as tokens collected from users accumulate) - 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) - 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 - 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 - 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 - 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 - validate (securing prepayment) - postOp (settling actual costs) - 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 - 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. - ETH reserves decrease - Token balance increases - ETH decreases -> tokens accumulate - Tokens accumulate -> discount rate increases - Discount rate increases -> rebalancing becomes more likely - 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). - 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 - Open Paymaster GitHub - Open Paymaster | ETHGlobal - ERC-4337: Account Abstraction - ERC-6909: Minimal Multi-Token Interface - Pyth Network Documentation