Technical Dive: Gas Sponsorship via Paymasters

Overview

One innovation in the blockchain space is ERC4337, a standard for account abstraction on the EVM ecosystem. In this document, we will delve into the Paymaster component of ERC4337 and its functionality within the framework.

Understanding Gasless Transactions

Paymasters, or "gas sponsors," in ERC4337 are smart contracts that enable transaction sponsorship through third-party-designed mechanisms. Often referred to as gasless transactions, paymasters eliminate the need for users to hold a blockchain's native token for transaction fees. This creates opportunities for transaction fee sponsorship or accepting network fees in ERC20 tokens.

Gasless transactions empower contracts to pay on users' behalf under any given conditions, unlocking a new realm of possibilities for transaction sponsorship mechanisms on EVM blockchains.

Let's explore the four major steps involved in this process.

• Step 1: Welcoming UserOperations

Openfort, functioning as the primary orchestrator, receives a set of UserOperations. This phase represents the initiation of the ERC-4337 transaction flow.

• Step 2: Meeting the Paymaster Contract

Openfort communicates with the Paymaster contract, contingent on the inclusion of the Paymaster within the UserOperation. The Paymaster contract is responsible for potentially covering transaction fees for Contract Accounts. Openfort then verifies if the Paymaster has a sufficient deposit or if the associated Contract Account possesses the required gas fees.

• Step 3: Custom Fee Logic in Action

If a Paymaster is involved, it can apply its proprietary fee logic. This allows for a flexible and tailored transaction fee structure based on the specific Paymaster's criteria.

• Step 4: Signature Validation and Execution Initiation

At this juncture, Openfort collaborates with the Contract Account and, when applicable, the Paymaster to authenticate the signatures present in the UserOperation. The Contract Account serves as the interface between the user and Openfort, ensuring streamlined transactional communication. Upon successful signature validation, Openfort conveys the necessary data from the UserOperation to the Contract Account, initiating the transaction execution.

The Power of Sponsoring Transactions

Paymasters can generally be categorized into two types: those with off-chain logic and those with on-chain logic, or simply put those that abstract the payment of network tokens and those that abstract the payment of network tokens with an alternative ERC-20 token.

Standard Paymasters: Sponsoring transaction fees

Currently, to transact on blockchains you'll need the netork native token to pay for gas (i.e. Polygon you need POL). Standard Paymasters offer an alternative approach to this requirement.

Openfort verifies the logic of the paymaster, determines if the paymaster should cover the transaction costs, and signs offchain to pay the gas costs. These costs are directly extracted from the paymaster (smart contract pool) filled with network tokens, similar to the operation of relayers with meta-transactions.

ERC20 Paymasters: Paying with ERC-20 tokens

ERC20 Paymasters present another innovative solution. In this scenario, the Paymaster can pay for gas fees with:

• A fixed amount of ERC20 conversion. This implies that the fixed ERC20 amount will pay the amount of gas fees. This brings consistency to the end user experience but also exposes the game to win/lose ERC20 if the value is above/below the gas fee.
• A dynamic amount of ERC20 conversion. This let's you cover the gas fees based on the conversion rate of your ERC20. This could be your preferred conversion rate or simply the conversion rate in a DEX (we'll use an Oracle for that).

This approach allows for the integration of a Paymaster with an existing ERC-20 token, such as USDC or your own game token.

Extra notes:

• You can use the ERC20 from a players wallets to also subsidize for the network gas fees. It collects digital currencies from the user, converts them into native tokens based on the prevailing exchange rate, and pays for gas fees on behalf of the user.
• You can create policy rules to be more granular on the sponsorhip details, based on contracts. functions and limits like gas cot or timme.
• Get your gas reports directly on the dashboard on monthly basis and pay directly with Fiat without holding tokens/crypto yourself.

If you have more questions/ideas/queries, join our Developer Discord and let us know there. Furthermore, you can follow us on Twitter for our updates as we keep shipping.