Fee Abstraction

What Is Fee Abstraction?

Fee abstraction is a blockchain design pattern that decouples transaction fee payments from a network's native token. On most blockchains, every transaction requires the sender to hold the chain's native currency (ETH on Ethereum, BTC on Bitcoin, ATOM on Cosmos) to pay for execution costs. Fee abstraction removes this requirement, letting users pay fees in alternative tokens or have fees covered by a third party such as a dApp developer.

The problem fee abstraction solves is straightforward: a user holding $500 in USDC on Ethereum cannot send a single dollar without first acquiring ETH for gas. This creates a frustrating onboarding barrier, especially for newcomers who may not understand why they need two tokens to complete one action. Fee abstraction makes this friction invisible, bringing the blockchain experience closer to traditional payment apps where the underlying infrastructure costs are hidden from the end user.

How It Works

Fee abstraction can be implemented at different layers of the blockchain stack. Each approach involves a mechanism for converting the user's preferred token into the native fee currency, or for sponsoring the fee outright.

ERC-4337 Paymasters

The most widely adopted approach on Ethereum uses paymasters, a component of the ERC-4337 account abstraction standard finalized in March 2023. In this model, users submit UserOperations (pseudo-transactions) to an alternative mempool. Bundlers package these into on-chain transactions routed through a singleton EntryPoint contract, which calls the paymaster to handle fee payment.

Two types of paymasters exist:

• Sponsoring paymasters: the dApp developer covers gas costs entirely, typically to reduce onboarding friction for new users. An off-chain service decides which transactions qualify for sponsorship.
• Token paymasters: users pay gas in ERC-20 tokens like USDC or USDT. The paymaster pays the actual ETH cost and collects the equivalent token amount from the user, using oracle price data for conversion.

// Simplified ERC-4337 paymaster interface
interface IPaymaster {
    // Called before execution to validate sponsorship
    function validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost
    ) external returns (bytes memory context, uint256 validationData);

    // Called after execution for settlement
    function postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost
    ) external;
}

In 2024, ERC-4337 accounts executed over 103 million UserOperations, a 12x increase from the previous year. Roughly 87% of these used paymasters, demonstrating that fee abstraction is the primary driver of account abstraction adoption.

Protocol-Level Fee Abstraction

Some blockchains build fee abstraction directly into the protocol rather than handling it at the application layer:

• Cosmos SDK fee abstraction: developed by Osmosis Labs, this module allows users on any IBC-connected chain to pay fees using IBC tokens. The module queries Osmosis for TWAP (Time-Weighted Average Price) data to determine exchange rates, then periodically swaps collected tokens back to the native currency.
• Celo: transactions include a feeCurrency field specifying an alternate payment token (cUSD, USDC, USDT). The protocol reserves the maximum fee in the chosen token before execution and refunds any unused portion afterward. No smart contract wallets or relayers required.
• zkSync Era: native account abstraction at the protocol level means every account can define its own fee-payment logic. Users pay fees in any supported token without relying on the ERC-4337 stack.

Meta-Transactions (ERC-2771)

An earlier approach to fee abstraction, ERC-2771 meta-transactions allow users to sign messages describing their intended action without submitting an on-chain transaction. A relayer (funded by the dApp) wraps this signed message in a native transaction and submits it, paying the gas. The target contract extracts the original sender from appended calldata using a trusted forwarder.

While ERC-2771 proved the concept of gasless transactions, it has a significant limitation: target contracts must explicitly support the standard by using a modified sender extraction function. It does not work retroactively with already-deployed contracts. ERC-4337 has largely superseded this approach because it works with any contract without modifications.

Architectural Elimination

Some protocols take fee abstraction to its logical conclusion by eliminating per-transaction fees entirely. Spark, a Layer 2 for Bitcoin, achieves this through its statechain architecture. Spark-to-Spark transfers work by reassigning cryptographic key shares rather than broadcasting on-chain transactions. Since no on-chain transaction occurs during a transfer, there is no mining fee or gas cost to pass along. Users pay standard Bitcoin network fees only when depositing to or withdrawing from Spark.

Use Cases

Onboarding New Users

The most immediate use case is eliminating the "cold start" problem. When a new user receives stablecoins for the first time, they cannot do anything with them without also acquiring native tokens for gas. Sponsoring paymasters let dApps cover initial transaction costs, reducing the steps from "download wallet, buy ETH, swap to USDC, then transact" to simply "download wallet and transact."

Stablecoin Payments

For stablecoin payment rails to compete with traditional payment networks, users should not need to think about gas tokens. Fee abstraction allows a merchant accepting USDC to offer customers a payment experience where fees are denominated in the same currency as the payment, or hidden entirely. This mirrors how traditional card networks handle interchange fees behind the scenes.

Embedded Wallets

Embedded wallets integrated into apps and websites benefit significantly from fee abstraction. When wallet infrastructure is invisible to the user, exposing gas token requirements breaks the abstraction. Fee sponsorship or token-denominated fees let embedded wallet providers maintain a seamless experience where users never interact with blockchain mechanics directly.

Cross-Chain Operations

Users operating across multiple chains face the burden of maintaining native token balances on each network. Fee abstraction combined with chain abstraction allows users to hold a single asset (like USDC) and transact across chains without acquiring separate gas tokens for each one. This is particularly relevant for payment chain abstraction flows where the underlying chain selection is automated.

Fee Abstraction on Bitcoin

Bitcoin's UTXO model and limited scripting language make Ethereum-style fee abstraction (paymasters, smart contract wallets) more difficult to implement at the base layer. Every Bitcoin transaction requires a fee paid in BTC, and there is no native mechanism for third-party fee sponsorship.

Layer 2 solutions address this differently. The Lightning Network still requires channel participants to hold BTC for on-chain operations (opening, closing, and force-closing channels), though routing fees are minimal. Spark's approach is more radical: by using off-chain key rotation via FROST threshold signatures, transfers of both BTC and USDB settle in under one second with zero protocol fees. Users only encounter Bitcoin network fees at the boundary between Spark and the base chain.

This architectural approach to fee abstraction is detailed in the Spark Layer 2 deep dive. Unlike paymaster-based systems that still incur underlying gas costs (someone always pays), Spark's statechain model genuinely eliminates the cost of peer-to-peer transfers.

Risks and Considerations

Centralization of Fee Sponsorship

When a single entity sponsors all gas fees, they gain the ability to censor transactions by refusing to sponsor specific users or operations. This creates a dependency on the sponsor's willingness to continue covering costs. If a dApp shuts down its paymaster, users who never acquired native tokens may find their funds temporarily stranded.

Oracle and Price Feed Risk

Token paymasters that accept fee payment in ERC-20 tokens rely on oracle price feeds to calculate conversion rates. Stale or manipulated price data could lead to users overpaying or the paymaster operating at a loss. Robust oracle infrastructure and rate-limiting are essential for production deployments.

Cost Sustainability

Sponsoring gas fees is a business expense. Protocols offering free transactions must have a sustainable economic model to cover these costs long-term. Common approaches include absorbing fees as a customer acquisition cost, charging platform fees elsewhere, or building fee coverage into subscription pricing. Circle's Paymaster, for example, transitioned from free to a 10% service fee on gas costs in July 2025, reflecting the reality that someone must ultimately pay for block space.

Smart Contract Risk

Paymaster contracts handle fee-related logic and interact with user funds. Bugs in paymaster implementations could lead to drained sponsorship deposits or stuck transactions. The additional smart contract surface area introduced by ERC-4337 (EntryPoint, paymaster, bundler interactions) creates more potential attack vectors compared to simple native transactions.

Comparing Approaches

Frequently Asked Questions

Is fee abstraction the same as account abstraction?

No. Account abstraction is a broader concept that makes blockchain accounts programmable, enabling features like social recovery, transaction batching, and session keys. Fee abstraction is one specific capability that account abstraction enables, typically through the paymaster mechanism. You can have fee abstraction without full account abstraction (as Celo and Cosmos demonstrate), and account abstraction without fee abstraction.

Who ultimately pays the fee?

In paymaster-based systems, someone always pays the underlying gas cost. Sponsoring paymasters shift the cost to the dApp operator. Token paymasters shift the denomination but the user still pays. Only architectures that eliminate on-chain transactions (like Spark's statechain model) truly remove the fee rather than redirecting it.

Does fee abstraction work on Bitcoin?

Bitcoin's base layer does not support fee abstraction natively. Every L1 transaction requires BTC for fees. However, Layer 2 solutions like Spark achieve the same user experience by processing transfers off-chain, meaning users can hold and transfer stablecoins without ever needing BTC for fees.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.