Every transaction on a blockchain costs a network fee, called gas, paid in the chain's own token. For new users that is the biggest hurdle: before they can claim, mint, pay or trade, they first have to buy ETH (or SOL, or POL) and move it to the right network. Gasless transactions remove that step. The user signs an action, and someone else pays the gas: you, a sponsor, or the user in a token they already hold.
"Gasless" is not one technique but a family of them. This page covers every method we build, how each flow works, and how to choose. SemBricks builds the contracts, backend services and front-end flows for all of them.
The Methods at a Glance
- Paymaster sponsorship (ERC-4337): smart accounts, with a paymaster contract paying the gas.
- Token paymasters: the user pays gas in USDC or another token instead of ETH.
- EIP-7702: existing wallets temporarily get smart account powers, including sponsored gas.
- Relayers and meta-transactions (ERC-2771): the user signs, a relayer submits and pays.
- Signature-based token flows: permit (EIP-2612), Permit2 and EIP-3009 for approvals and transfers without gas.
- Native account abstraction: chains such as ZKsync with paymasters built into the protocol.
- Solana fee payers: your service co-signs as the account that pays the fee.
- Gas drops: sending a small amount of native token to new users.
1. Gas Sponsorship with a Paymaster (ERC-4337)
With account abstraction, users have smart accounts that sign "user operations" instead of regular transactions. The flow:
- The user signs a user operation in your app.
- Your backend decides whether to sponsor it and, if so, signs an approval with a short validity. This is the verifying paymaster pattern: business rules stay in your backend, the contract only checks the signature.
- A bundler submits the operation to the EntryPoint contract (ERC-4337).
- The EntryPoint asks the paymaster to confirm, executes the operation and takes the gas from the paymaster's deposit.
You can run this on a managed service such as Alchemy Gas Manager or Biconomy, or on your own contract when your rules are specific, see custom paymaster development. Overview: paymaster development.
2. Paying Gas in Tokens
Not every action has to be free. With a token paymaster, the paymaster pays the gas in ETH and charges the user the equivalent in USDC or another ERC-20 token. For the user it still feels gasless: they never need ETH. A common setup combines both: sponsor onboarding and the first actions, then charge in tokens.
3. EIP-7702: Gasless for Existing Wallets
Since Ethereum's Pectra upgrade, EIP-7702 lets a regular wallet address (an EOA, such as a MetaMask account) delegate to smart account code. The user keeps the same address and assets, but gains smart account features: batching several actions into one, and gas sponsorship through paymasters and bundlers. This closes the gap between users with regular wallets and the smart account world, and is quickly becoming the preferred route for apps whose users already have wallets. Wallet support varies, so we check it for your audience.
4. Relayers and Meta-Transactions (ERC-2771)
The older and still widely used pattern works with any wallet:
- The user signs a request as an EIP-712 message: which contract, which function, a nonce and a deadline.
- A relayer, usually your backend, submits it through a trusted forwarder contract and pays the gas.
- The target contract reads the original user from the forwarded call, so it acts on behalf of the user, not the relayer.
This requires your contracts to support the forwarder, and the forwarder must be trusted completely. Combining ERC-2771 with multicall functions has caused real vulnerabilities, so we review those combinations explicitly. Details: meta-transactions (ERC-2771).
5. Signature-Based Token Flows
- Permit (EIP-2612): the user signs an approval instead of sending an approve transaction; the app combines it with the next action in one transaction.
- Permit2: a shared contract that brings signature-based approvals to tokens that do not support permit themselves.
- EIP-3009: the user signs a complete transfer, for example of USDC, and anyone can submit it. Ideal for payments.
These flows make token actions gasless for the user even with a regular wallet, as long as someone submits the transaction.
6. Native Account Abstraction
Some chains build account abstraction into the protocol. On ZKsync, every transaction can name a paymaster, without a separate bundler or EntryPoint, and it works for regular accounts too. See ZKsync paymaster development.
7. Solana: Fee Payers
On Solana, every transaction names a fee payer, and that does not have to be the user. Your backend can build the transaction, let the user sign it, and add its own signature as fee payer. Be aware that creating new accounts, such as token accounts, also costs rent, which the sponsor often covers too. Rules and limits matter just as much here.
8. Gas Drops
The simplest option: send each new user a small amount of the native token. It works with every wallet and contract, but it is the easiest to abuse, because the gas can be withdrawn and used for anything. Only suitable with strong sign-up checks and small amounts.
Which Method Fits?
- New users without a wallet: smart accounts with paymaster sponsorship, often with passkey login.
- Users with MetaMask or similar: EIP-7702 where supported, otherwise meta-transactions or permit flows.
- Payments in stablecoins: EIP-3009 or a token paymaster.
- ZKsync or Solana: their native mechanisms.
- Many projects combine methods, for example sponsorship for onboarding and token payment afterwards.
Keeping Sponsorship Sustainable
Free gas attracts bots. Whatever the method, sponsorship needs rules and monitoring:
- Who: only signed-in or verified users, or holders of a specific token.
- What: only your own contracts and specific functions, such as claim or mint.
- How much: a number of free actions per user, a daily budget per user and a global budget.
- When: during onboarding, a campaign or below a gas price threshold.
- Monitoring: real-time spend per user and action, alerts on unusual patterns, and automatic refills of paymaster deposits and relayer wallets before they run dry.
Signing Safely Without Gas
Gasless flows rely on signatures, and signatures are where users get phished. Every request is bound to a chain, a contract, a nonce and a deadline, and shown in plain language so users see what they approve. See blind signing prevention and our overview of blockchain signatures.
Frequently Asked Questions about Gasless Transactions
Are gasless transactions really free?
For the user, yes. The network fee is still paid, by you as the sponsor, by a relayer, or by the user in another token through a token paymaster.
Do gasless transactions work with MetaMask?
Yes, through EIP-7702 where the wallet supports it, through meta-transactions with a relayer, or through permit and EIP-3009 signatures for token actions. Paymaster sponsorship with ERC-4337 requires a smart account, which EIP-7702 can provide.
Which chains support gasless transactions?
Ethereum and the major EVM layer 2 networks support ERC-4337 and relayers; ZKsync has native paymasters; Solana supports separate fee payers. On layer 2 networks sponsorship is cheapest, which is why it is most common there.
Can I sponsor only some actions?
Yes, and that is the normal setup. You decide per user and per action, for example the first mint or claim, while other transactions are paid by the user.
How do I stop bots from draining the budget?
By sponsoring only authenticated users, limiting actions per user and per day, restricting which contracts and functions are covered, and alerting on unusual patterns. With a verifying paymaster or relayer, the rules live in your backend and can be tightened instantly.
Can users pay gas in USDC instead?
Yes, with a token paymaster, or with EIP-3009 for USDC transfers that a relayer submits.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Related: smart accounts, session keys and crypto wallet development.
Make Your App Gasless
Tell us who your users are, which wallets they use and which actions should be free. We will recommend the right method, or combination, and build it with limits that keep costs predictable.