Building Sagon's ERC-4337 Paymaster Architecture

Sagon combines two approaches to Ethereum's gas friction: Huff-optimized contracts that minimize execution costs, and Account Abstraction that removes the need for ETH. While the Huff implementation reduces gas costs significantly, this article explores the ERC-4337 paymaster that lets users transact with only stable coins.

What Is Account Abstraction?

Account abstraction replaces private-key wallets with smart contracts, enabling programmable account logic like custom signatures and token-based gas payments. Polkadot describes it as: “a layer of on-chain logic that controls an account, typically in the form of a smart contract, that completely avoids the need for consensus-layer protocol changes. Without a smart contract, abstracting accounts would require changes in the core architecture of the protocol.“

How Account Abstraction works

Traditional Ethereum transactions must be initiated by an Externally Owned Account (EOA) holding ETH. Smart contracts cannot start transactions, and users without gas cannot interact with the network. This limitation has persisted since Ethereum's genesis.

In September 2021, Vitalik Buterin and others introduced ERC-4337, a standard for implementing account abstraction without requiring protocol-level changes. Instead of modifying Ethereum's core, ERC-4337 introduces new components that work within existing infrastructure.

Unlike traditional transactions where EOAs sign and pay gas in ETH, account abstraction introduces additional components. The user signs a UserOperation off-chain, which is collected by a Bundler that submits multiple operations to Ethereum in a single transaction. The EntryPoint contract, a global singleton, receives these bundled operations and coordinates validation through the user's Smart Wallet and an optional Paymaster contract. The Smart Wallet validates the user's signature using custom logic, while the Paymaster can pay gas fees on behalf of the user. After validation, the EntryPoint executes each operation and the Paymaster charges users in their chosen ERC20 token, creating a complete separation between transaction signing and gas payment.

Account abstraction architecture. Source: Ethereum Improvement Proposals

ERC - 4337 Components

1. UserOperations: It is a structure that describes a transaction to be sent on behalf of a user. it includes the following variables:

   • sender - The Account making the UserOperation

   • nonce - Anti-replay parameter

   • factory - Account Factory for new Accounts

   • factoryData - data for the Account Factory

   • callData - The data to pass to the sender during the main execution call

   • callGasLimit - The amount of gas to allocate the main execution call

   • verificationGasLimit - The amount of gas to allocate for the verification step

   • preVerificationGas - Extra gas to pay the bundler

   • maxFeePerGas - Maximum fee per gas

   • maxPriorityFeePerGas - Maximum priority fee per gas

   • paymaster - Address of paymaster contract

   • paymasterVerificationGasLimit - The amount of gas to allocate for the paymaster validation code

   • paymasterPostOpGasLimit - The amount of gas to allocate for the paymaster post-operation code

   • paymasterData - Data for paymaster

   • signature - Data passed into the sender to verify authorization

2. Smart Wallet: Since EOAs lack programmable logic, a smart contract replaces them on-chain. It implements two key functions: validateUserOp() to verify the user's signature and authorize operations, and execute() to perform the actual transaction logic (transfers, contract calls, etc.). Unlike EOAs, Smart Wallets can implement custom validation logic such as multi-signature schemes, social recovery, session keys, or spending limits. Each user deploys their own wallet instance, which holds their assets and executes operations on their behalf when validated by the EntryPoint.

3. Pay Master: It is an optional smart contract that sponsors the gas fees on behalf of the sender. it has two main functions: validatePaymasterUserOp() and postOp(), while the former validates that the contract has sufficient token for the transaction, the later charges the contract.

    function validatePaymasterUserOp
        (PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost)
        external returns (bytes memory context, uint256 validationData);
   
    function postOp
        (PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas)
        external;
   
    enum PostOpMode {
        opSucceeded, // UserOperation succeeded
        opReverted // UserOperation reverted. paymaster still has to pay for gas.
    }
   

4. Entry point: The global singleton contract that coordinates all account abstraction operations, deployed at the same address (0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789) across all EVM chains. It receives bundled UserOperations from bundlers and does the entire execution flow, From validating operations through the Smart Wallet's validateUserOp(), checking paymaster willingness via validatePaymasterUserOp(), executing the actual operation through the wallet's execute() function, and finally settling gas payments through the paymaster's postOp().

5. Bundlers: Users send their signed UserOps to a bundler's RPC endpoint called an alternative mempool (not Ethereum's mempool). The bundler, such as Stackup aggregates multiple UserOps into a single transaction and calls EntryPoint.handleOps(), paying the gas fees upfront in ETH. Within the same transaction, the EntryPoint reimburses the bundler from paymaster deposits, typically including a markup for profit.

Bundler’s Behavior. Source: Ethereum Improvement Proposals

Sagon’s paymaster implementation

While the paymaster is optional in ERC-4337, it's central to Sagon's architecture. Without it, users would still need ETH for gas, defeating the purpose of frictionless token operations. Sagon's paymaster enables users to pay gas fees directly in stablecoins (USDT, USDC), eliminating the ETH requirement entirely.

The implementation addresses three core challenges: accurately pricing gas in token terms via oracles, preventing users from frontrunning gas payments, and efficiently converting collected tokens back to ETH for operational sustainability. Below is Sagon's approach to each.

• Gas Pricing via Oracles: Sagon uses Chainlink price feeds to convert ETH gas costs into stablecoin amounts. During validatePaymasterUserOp(), the paymaster queries the latest ETH/USD and stablecoin/USD prices, it calculates the required token amount with a markup for the bundler, and verifies the user has sufficient balance before approving the operation.

• Frontrunning Gas Payment: Initially, Sagon's design allowed users to pay stablecoins during postOp(), after validation. This created a vulnerability, users could transfer their tokens away between validation and execution, causing the transaction to revert while the bundler still paid gas. To prevent this, Sagon implemented a pre-deposit system. Users deposit stablecoins into the paymaster contract before submitting UserOperations. Deposits are tracked per user address and can only be withdrawn by the depositor. During postOp(), the paymaster deducts gas costs from the user's existing deposit, eliminating the frontrunning risk since funds are already secured.

• Token-To-ETH Conversion: As the paymaster collects stablecoins from users, it must convert them to ETH to replenish its gas reserves. Sagon uses Uniswap V2 for this exchange. Rather than swapping after every transaction (which would be gas-inefficient), the paymaster batches conversion accumulating the deposits until a threshold is reached, then executing with a single swap through Uniswap V2's router.

Conclusion

Sagon's paymaster implementation shows how ERC-4337 can eliminate ETH requirements for on-chain transactions. The core implementation is complete. Current efforts focus on edge case testing and stress testing oracle failures. Once testing concludes, Sagon will offer both gas-optimized token distributions via Huff(completed) and gasless transactions via Account Abstraction.

Full code and documentation will be released upon completion of the security review.