Every write to an EVM network costs a fee in the network's native currency, called gas. Gas sponsorship means the organisation pays that fee for its users from wallets it keeps funded, so an investor or operator can act without holding the native currency while those wallets hold enough. The alternative is Self-pay, where each user funds their own wallet. This page covers the two settings that decide who pays, how a bundler and a paymaster carry a sponsored smart wallet operation to the network, and what happens when a paying wallet runs dry.
The bundler fronts the gas for a user operation, and the EntryPoint repays it from the paymaster deposit or, without a valid ticket, from the wallet.
Two settings decide who pays gas. The wallet type is one choice for the whole organisation: EOA wallets or smart wallets. The gas payer is one choice per network: Self-pay, Relayer-paid with EOA wallets, or Paymaster-paid with smart wallets.
With Relayer-paid or Paymaster-paid, users need no native currency for the writes the organisation pays for. The organisation keeps the paying wallets funded instead.
A paying wallet that runs dry pauses the work it pays for. A top-up releases the work, and work still waiting when the funding window closes fails with the gas required error, DALP-9087.
Two settings decide who pays
An EOA wallet, or externally owned account, is a plain wallet controlled by one key. A Smart Wallet is a contract account with its own signing rules. The wallet type sets which kind every user of the organisation holds, on every network. When the platform offers smart wallets, onboarding proposes smart wallets with Paymaster-paid, so the organisation pays gas from the start. Otherwise onboarding proposes EOA wallets with Self-pay. The move to smart wallets is one-way: once the organisation is on smart wallets, the platform does not accept a move back.
The gas payer is set per network, so one organisation can sponsor gas on a public network and let users pay on another. The wallet type limits which payers a network can use.
On a network that charges no gas, none of these wallets needs a balance, and the Console recommends Self-pay there. On the Console's Transaction funding page you read and change the gas payer for each network, and Change the wallet type covers the move to smart wallets. Moving to smart wallets does not turn sponsorship on: check the gas payer on each network afterwards and choose Paymaster-paid where the organisation sponsors gas.
How a sponsored operation reaches the network
A smart wallet does not send its own transactions. It acts through a user operation, a signed instruction defined by the ERC-4337 standard for account abstraction. An EntryPoint contract on the network validates the instruction and runs it. A bundler collects user operations and submits them to the EntryPoint in one transaction. User operations covers the API for sending, replacing and reading them.
The platform runs one bundler for each organisation and network, so the organisation does not run a bundler of its own. Each bundler signs with its own bundler wallet, which pays the gas for the bundle up front. The EntryPoint repays the bundler wallet in the same transaction, from one of two sources:
- Paymaster-paid. A paymaster is a contract that agrees to pay for an operation. The organisation's paymaster pays only for an operation that carries a sponsorship ticket. The platform signs the ticket with the organisation's custodial signing key. The ticket names the sender, a hash of the call, the organisation, a deadline and the most gas it covers. The paymaster refuses the operation when the sender or the call differ from the ticket, or when the cost exceeds the ticket's maximum. The EntryPoint refuses it once the deadline has passed. For an operation the paymaster accepts, the EntryPoint takes the repayment from the paymaster's deposit at the EntryPoint. For an operation the platform prepares, it signs the ticket only after the operation's gas estimate and funding checks pass, so an operation that fails estimation or is short of funds when it is first prepared leaves no signature request at the custody provider.
- Self-pay. With no ticket, the EntryPoint takes the repayment from the smart wallet's own balance.
A signed user operation that a client sends to the bundler API is checked against the payer's funds first, and one that the paymaster deposit or the smart wallet cannot cover is refused at submission. A write that the platform builds for a user pauses for funding instead, as When a paying wallet runs out of funds explains.
A refund splitter is a contract that divides each gas refund. When the organisation has one on the network, every bundle names the splitter as the receiver of the repayment instead of the bundler wallet, under Self-pay as well as Paymaster-paid. While the splitter's own sponsorship flag is on, it sends the bundler wallet a share set in basis points, one hundredth of a percent each, and deposits the rest into the paymaster deposit. While the flag is off, it sends the whole refund to the bundler wallet. A System manager sets the flag and the share on the splitter, apart from the network's gas payer.
The sponsorship key sits with the organisation's custody provider like any other custodial key, but its wallet must stay free of approval rules. When the provider's policy holds a sponsorship signature for approval, the platform refuses the operation at once and records the hold, so keep the paymaster wallet out of every approval policy at the custody provider, whichever provider it is. Fireblocks policy shows the Fireblocks version. A custody approval on the user's own signature is different: the operation waits for it, but only until 60 seconds before its ticket expires. The deployment sets the ticket lifetime, between 1 second and 1 hour, and the default is 5 minutes. With the default ticket, a person who approves a sponsored operation in the custody provider's app has about four minutes.
Control the cost of sponsorship
Sponsorship moves the fee to an organisation wallet, and the fee itself stays the same. Four controls limit what the organisation spends:
- The per-ticket ceiling. Each ticket covers at most a maximum gas cost. The deployment sets the ceiling per network in the network's native currency, and the platform refuses a ticket above it. A ticket deadline is at most one hour away.
- The gas payer per network. Switch a network to Self-pay to stop sponsoring there. The other networks keep their own payer.
- The refund split. A larger share for the paymaster deposit returns more of each refund to the sponsorship reserve.
- Gas tank alarms. Warning and critical alarms, set in days of runway left, tell you when a reserve needs a top-up.
The Permission manager, Gas manager and System manager roles see Transaction funding. With smart wallets, these roles change the gas payer and the gas tank alarms. The refund split is stored on the splitter contract, which accepts a change only from an account that holds the System manager role. With EOA wallets, an organisation owner or a platform administrator changes the gas payer, in the Console or through the API. Each of these changes is an administration change, so it waits for a second person when the organisation's Approvals settings protect it.
When a paying wallet runs out of funds
When a wallet cannot cover a write that the platform builds and sends for a user, the platform pauses the work, records one funding requirement that names the wallet and the amount to send, and waits. Nothing reaches the network while the work is paused. The requirement can name a user's own wallet, the relayer wallet, the bundler wallet or the paymaster deposit. One top-up that covers the requirement releases every write waiting on it, and nobody has to submit the work again.
The deployment sets a funding window for each network. Work still waiting when the window closes fails with the gas required error, DALP-9087. Its error data names the wallet, the network, the smallest amount to add and a recommended target balance. When a person's own wallet runs short, the platform emails that person the amount to send. A shortfall on a shared gas wallet, such as the relayer wallet, the bundler wallet or the paymaster deposit, sends no such email, so watch the Transaction funding page and the gas tank alarms for those.
A user operation a client signs and sends is refused at submission instead, and a smart-wallet write that needs several signers fails. An integration that prefers to fail fast sends Prefer: dalp- with the write. The platform then fails a write it cannot fund at once with DALP-9087 instead of pausing it. A write that the transaction queue refuses before sending, because the paying account cannot cover it, returns DALP-14062, and nothing reaches the network. Fund the account and send the request again.
How gas is paid and funded covers the funding requirement, and Operator wallet covers the funding webhook events. Transaction funding covers the top-up.
Frequently asked questions
Do investors need the network's native currency in their wallets?
Not for the writes the organisation pays for, when the network's gas payer is Relayer-paid or Paymaster-paid. A few writes fall outside Relayer-paid, such as a call that sends native currency, and What Relayer-paid does not cover lists them. With Self-pay, each wallet pays its own gas and needs a balance in the native currency, unless the network charges no gas.
Can the sponsor change what an operation does?
No. The user's smart wallet signs the operation, and the ticket binds the paymaster to that exact sender and call. A change to the call makes the ticket invalid. The paymaster can refuse to pay, but it cannot change the operation. The platform decides whether to issue a ticket, so a user with no native balance depends on the organisation's sponsorship being funded and on.