Transaction funding decides who pays the network fee, called gas, for the organisation's transactions, and keeps the wallets that pay it funded. The page shows the network selected in the Network submenu of the account menu at the top right: who pays gas there, which shared gas wallets pay it, which wallets wait for funds, and where to send a top-up. The account menu shows that submenu only when multi-network support is on for the organisation and it has more than one active network. Otherwise the page shows the organisation's default network.
When a wallet runs short on a network that charges gas, the platform pauses the write and the Console shows a funding request at the top of the page. How gas is paid and funded explains the pause, the funding window and the three gas payers.
The page also holds the Wallet type row, which sets the kind of wallet every user of the organisation holds. Every change made on this page, including a gas payer change, a sponsorship change, a refund split change, a signing key rotation, a paymaster deposit and a withdrawal, is recorded in the organisation's Audit trail with who made it. A top-up is a transfer you send from another wallet, so the platform keeps no record of it beyond the wallet's higher balance. A withdrawal also appears on the transactions page.
One “Gas” card with a “Gas payer” row and a “Wallets” row that lists the shared gas wallets, and below it the “Wallet type” card that names the current wallet type.
Steps
Keeping the page healthy takes four steps. Change the gas payer, Withdraw from an idle wallet and Change the wallet type are separate tasks.
Read who pays on the network
In the sidebar, open Transaction funding under “Infrastructure”. Under the title, the page reads “On <network>”. It follows the network selected in the “Network” submenu and changes when you switch network there.
One “Gas” card holds two rows. The Gas payer row states who pays on that network and has a “Change” button.
On a network that charges no gas, the row reads “No fee on this network” instead. For a viewer who may not change the payer, Change is unavailable. Point at it to read who can.
A network still being set up says so instead of listing wallets. While a network finishes a move to smart wallets, the row says the gas payer shown can still change. When the read fails, the page reads “Transaction funding could not be read.” with a Try again button. A network whose gas payer the platform has not read yet, such as one added a moment ago, reads “Not read yet” instead of a failure. The Console home System status shows a “Checking” badge with “Not read yet” next to the network, and leaves the network out of Needs attention until a read has happened. The status updates on its own once a new block brings the payer's balance.
On a network that charges no gas while the relayer or the paymaster pays, a notice at the top of the page explains that this saves no fee there. Select Switch this network to Self-pay to open the gas payer sheet with Self-pay preselected. Select “Keep relaying” or “Keep sponsoring” to hide the notice while you stay on the page. A screen reader announces each button together with the notice title, so you hear which notice it acts on.
Fund an open request
When the network refuses a write because a wallet cannot pay its gas, the platform opens a funding request. Bundler setup and repair are the exception: they open one from a balance check, for the bundler wallet's top-up level that Shared gas wallets explains. The page shows one notice at the top for each request open on the network, for example “Bundler wallet needs 0.25 ETH”. Each notice reads “Operations wait until it is funded.” and shows when the request was raised. For a shared gas wallet, the notice also shows its balance. For a wallet the page cannot name, it also shows the address. With no open request, the page shows no notice.
Select the notice's button, for example Fund 0.25 ETH, to open the top-up sheet for that wallet. When the platform could not size the amount, the notice reads “needs gas” and the button reads “Fund”. When a wallet runs out of gas explains what waits and for how long.
For a smart wallet that pays its own gas, the amount covers the gas its EntryPoint deposit does not cover plus the native currency the operation sends, such as a deposit into the paymaster, so one transfer of that amount lets the write continue.
Check the shared gas wallets
The Wallets row is a table of every shared gas wallet the platform runs for the organisation on the network, in use or idle, with the columns “Wallet”, “Status” and “Balance”, and a last column of actions. Shared gas wallets explains each wallet and status. Each row has a “Top up” button and a menu, “More actions for <wallet>”, with “Withdraw”. Open a row for what the wallet does and its top-up level. When “Top up” or “Withdraw” is unavailable, point at it to read why.
In Self-pay with EOA wallets, no shared wallet pays. The row reads “Each wallet pays its own gas. A wallet that runs dry shows here as a funding request.” On a network that charges no gas it reads “This network charges no gas.” instead, and the “Balance” column shows the empty-value placeholder for every wallet, because no balance is needed there. The same placeholder stands for a wallet the indexer has not seen yet.
Top up a wallet
Select Top up on a shared gas wallet in use, or the button on a funding request. “Top up” is enabled only on a network that charges gas and for a wallet that pays fees now. The sheet “Top up on <network>” opens with that wallet preselected under “Wallet to fund”. You can choose another wallet on the network there.
The sheet shows the address under Send to this address with a copy button, a QR code that holds the same address, and the warning “Send <currency> on <network> only. Funds sent on another network do not reach this wallet.” When a request is open for the selected wallet, the sheet shows “Needs at least <amount> to continue” and “Recommended: <amount> (covers follow-on operations)”. When the wallet already holds enough, the sheet says nothing needs to be done and when the request closes. Without a request, the sheet can suggest an amount, as Size a top-up explains.
Send the transfer from the wallet or service your organisation uses for on-chain transfers. Keep the sheet open: it reads “Watching for the deposit…” and changes to “Deposit received.” when the wallet's balance rises, or when the request closes. For the refund splitter, which forwards every deposit, the sheet watches the bundler wallet and the paymaster deposit together.
For the paymaster deposit, the sheet also shows “Deposit from a wallet”. Enter an amount in the network currency, in your own number format and with a suffix such as 1.5k if you like, select Deposit, and confirm with wallet verification. The deposit goes from the wallet of the account you are signed in with into the paymaster, and the sheet reads “Deposit sent. The balance updates once it lands.” A refusal reads “The deposit was refused.”
Change the gas payer
Select Change on the “Gas payer” row. The “Change gas payer” sheet applies to the selected network only, and every other network keeps its own payer. When the deployment offers smart wallets, the sheet names the organisation's “Wallet type”.
Under Gas payer on <network>, choose the payer:
- EOA wallets: “Self-pay” or “Relayer-paid”. “Paymaster-paid” is listed only on a deployment that offers smart wallets, and it is unavailable with the note “Needs smart wallets: set under Wallet type.”
- Smart wallets: “Self-pay” or “Paymaster-paid”. “Relayer-paid” is unavailable, with the note “EOA wallets only: smart wallets go through the bundler instead.”
On a network that charges no gas, the sheet recommends Self-pay. Add a note in “Reason (optional)” to record one in the Audit trail. Select Save payer to apply the choice, or “Keep current payer” to close the sheet. “Save payer” stays unavailable until you choose a different payer. The Console confirms with “Gas payer saved.” and closes the sheet. When the save fails, the sheet shows the reason and the stored payer stays.
A switch changes how new transactions on that network are paid. A transaction the platform already prepared for the relayer still goes through the relayer. Users keep the same wallet addresses, so a switch moves no assets and changes no permissions. The transactions that deploy the organisation are paid by the deploying wallet, whatever you choose.
Switching a network to Relayer-paid creates a relayer wallet on that network, and until it holds enough, user transactions on that network wait for funding. Switching back to Self-pay stops the relayer paying, and the relayer keeps its balance. It shows as Idle in the “Wallets” table, where a Permission manager can withdraw it.
Switching that network back to Relayer-paid later reuses the same relayer wallet and its balance.
The collapsible advanced section at the bottom of the sheet draws “How a write reaches the chain” for the payer you selected and holds the settings that follow. With EOA wallets it is “Advanced: relayer top-up levels”. It shows the “Forwarder” contract's address on the network, or “Not deployed”, and the relayer's top-up level. On a network that charges no gas, it reads “Top-up level: not needed”.
With smart wallets it is “Advanced: bundler, gas tank and sponsorship”. Under “Contracts on <network>” it shows “EntryPoint v0.7” and “Paymaster”, or “Not deployed”, the “Gas tank alarms” and “Refund split” buttons, and the “Signing key” block once the organisation has a paymaster on the network. Without the Permission manager, Gas manager or System manager role, these controls are unavailable.
Custody credentials are on Custody and on-chain roles on Roles and permissions.
Set gas tank alarms
Select “Gas tank alarms” to open “Low-balance alarms”. Enter “Warning at (days of runway)” and “Critical at (days of runway)”: whole numbers of at least 1, with the critical alarm fewer days than the warning alarm. Unset, they read 7 and 3 days. Select Save alarms. The warning days also size the suggested top-up.
Set the refund split
A sponsored operation's gas cost can return in part after it settles. The refund splitter divides each amount it receives between the bundler wallet and the paymaster deposit. Select “Refund split” to open “Refund split (advanced)”, and enter the Bundler wallet share in basis points, a whole number from 0 to 10,000. The rest goes to the paymaster deposit.
The split is stored in the splitter contract, so “Save refund split” asks for your wallet verification, “Confirm the refund split”, to sign the update. The contract accepts the update only from an account that holds the System manager role, so “Save refund split” stays unavailable for anyone else and its tooltip reads “You need the System manager role to configure the gas reserves.”
The split only divides value that reaches the splitter. The bundler wallet and the paymaster deposit still pay their own costs.
Rotate the signing key
The signing key is the custodial key that signs sponsored operations. The “Signing key” block shows the current key and when it was set. Rotate it when it may be compromised: select Rotate signing key and enter your verification code. The platform accepts a rotation from the System manager role only, and any other role gets “You need the System manager role to rotate the signing key.” The current key stops working as soon as the new one takes effect. While the network confirms the change, the block reads “A new key is waiting for network confirmation”.
Read the refund splitter's balance history
Open the Refund splitter row. It holds a small table with the columns “Recorded” and “Balance”: the balances the platform recorded over the last 30 days, each with the time it was recorded. With nothing recorded, it reads “No balance snapshots yet”. When the history cannot be read, it reads “The balance history could not be read.”
Withdraw from an idle wallet
The platform cannot reverse a withdrawal once it confirms, so check the destination before you send.
In the “Wallets” table, open the menu of an idle wallet and select Withdraw. On a network that charges gas, an idle relayer wallet or bundler wallet that holds a balance offers it to the Permission manager role. An idle paymaster deposit offers it to a user with both the Permission manager and the System manager role. Where “Withdraw” is unavailable, the menu item or the opened row says why. A relayer left funded after a gas payer change can be emptied here, once the writes queued before the change have gone through it.
The sheet “Withdraw from <wallet>” shows the wallet's “Balance” and “Withdrawable now”. Part of the balance stays in the wallet to pay for the withdrawal itself, including a resend at a higher fee, and the sheet names that amount.
Once “Send to” holds an address, the platform prices that amount for sending the whole withdrawable amount there. The withdrawal accepts the amount the sheet shows unless the network balance differs from the one shown, or the fee or the wallet's own writes changed since. When the wallet's own signed writes are still on their way to the network, including the bundles of the bundler wallet, the sheet also shows what they hold.
The platform counts each signed write at its worst-case gas cost, so the node admits the withdrawal beside them. Whatever those writes do not spend becomes available once they confirm. The whole paymaster deposit is withdrawable, because the account you sign with pays the withdrawal's gas.
Enter the address in Send to and the amount, which reads your own number format, groups the digits as you type and accepts a suffix such as 1.5k, or select “Withdraw all”, which takes everything withdrawable at the moment the platform sends the withdrawal.
The sheet blocks an address with a wrong checksum, the zero address, the wallet itself, and an address that does not accept a plain transfer of the network's currency.
Select “Review withdrawal”, check “From”, “To”, “Amount” and “Network”, then select Withdraw and enter your verification code. The sheet then reads “Sent <amount>”, or says the withdrawal is queued and links to “Open transactions”, where it shows with its outcome, including if it pauses or fails.
Change the wallet type
Wallet type sets the kind of wallet every user of the organisation holds, on every network. An EOA wallet, or externally owned account, is a plain wallet controlled by one key. A smart wallet is a contract wallet with weighted signers, approval policies, and recovery.
The organisation starts on EOA wallets unless it chose smart wallets during onboarding. Come here when the organisation needs approval rules, key recovery, or batched operations. EOA wallets already issue and transfer assets, so the move is optional. It is also one-way: once the organisation uses smart wallets, the platform does not accept a move back.
The Wallet type row sits in its own card below the “Gas” card and shows only when the deployment offers smart wallets, through its account-abstraction feature. It names the current type, “EOA wallets” or “Smart wallets”. On EOA wallets it says “Each wallet signs with its own key. No setup, no migration.” and “One-way, for the whole organisation.”, and states how many of the organisation's active networks are ready for smart wallets, for example “2 of 3 networks ready for smart wallets”. When none is ready, it reads “No network can host smart wallets yet, so the switch cannot start.” instead.
-
Read the card. Select Review the switch. The “Migrate to smart wallets” sheet opens, and nothing starts until you confirm at the bottom.
-
Read the sheet in order. It starts with What each wallet type gives you, a table that compares the two types, with the active type marked “Current”:
The table names any active network that has no EntryPoint and bundler yet. Then the sheet warns “Writes pause for a few minutes.” Writes already in flight finish first, and anything new waits and resumes on its own.
The “Migrate to smart wallets” sheet.
The sheet starts with a table that compares what each wallet type gives you, then lists each active network as “Ready” or “Not ready”, the steps under “What happens”, and the confirmation field at the bottom.
-
Under Before you start, the sheet lists each active network of the organisation as “Ready” or “Not ready”. A network is ready when its EntryPoint and bundler are in place. A network that is not ready keeps its writes on EOA wallets until it is. A last row, “Gas after the switch”, states that every network starts on Self-pay.
-
When a write on the organisation relayer is paused or still in flight, the sheet lists it under A relayer write has not finished. A paused write waits for relayer funds: top up the relayer on that network, or cancel the write. A cancelled write is not sent again, so submit it again after the switch. The sheet reads readiness again each time it opens, so a write that finished in the meantime no longer shows.
-
Under What happens, the sheet lists the steps:
- A smart wallet deploys for every existing wallet, on each ready network.
- Each existing key becomes the signer of its smart wallet. Holdings stay where they are.
- Every network starts on Self-pay. You switch on a paymaster per network afterwards with Change gas payer.
- When some networks are not ready, the sheet names them. They stay on EOA wallets until they have an EntryPoint and a bundler.
-
Under the consequence line “Every wallet in the organisation moves to a smart wallet, once. It cannot be undone.”, type
MIGRATEin the field labelled “Type MIGRATE to confirm”. “Start migration” stays unavailable until the field holds that word. It also stays unavailable while no network is ready for smart wallets or a relayer write has not finished. Point at the button to read which one applies. The switch would queue writes that cannot land, so the platform refuses it and spends no gas. Select Start migration, or “Not now” to close the sheet without a change.
The Console confirms with “Migration to smart wallets started.” and closes the sheet. When the start fails, the sheet shows the reason, for example “The migration could not start. Try again.”, and the organisation stays on EOA wallets. For anyone who is not an organisation owner or platform administrator, the Console hides the Review the switch button and the sheet. The API accepts the change from the same two roles and denies it to everyone else.
Shared gas wallets
A shared gas wallet is a wallet the platform runs for the organisation on one network to pay gas. Which ones are in use depends on the wallet type and the gas payer. Every other shared wallet on the network is idle.
The Status column reads:
- In use for a wallet the current gas payer uses, and “Low” when its balance is below 0.1 of the network's currency, for example 0.1 ETH.
- Collects refunds for the refund splitter, where a balance is unswept refunds and zero is normal.
- Idle for a wallet the current gas payer does not use. It keeps its balance until it is withdrawn.
- Not seen yet for a wallet the gas payer uses that the platform has no record of on the network. A bundler wallet that a deployment creates is listed within seconds of the platform indexing the deployment's system.
The Balance column shows the balance in the network currency, or “No reading yet” when the platform has no reading, which is different from zero. On a network that charges no gas, it stays blank. The opened row shows the wallet's job, its address with a copy button and an explorer link, and a note: “Top-up level <amount>.” for a paying wallet, “Holds refunds that have not been swept yet.” for the refund splitter, or “Left over from an earlier mode.” for an idle wallet that still holds a balance.
An opened relayer row also shows “Last balance increase seen”: the time the platform's read saw the balance rise, not the time the transfer was mined. The other wallets never show it, because bundle refunds raise their balances.
Every 30 minutes on a smart-wallet network that charges gas, the platform checks the bundler wallet against a top-up level it sizes from the network's live fee quote. The level is the gas ceiling of one bundle, times the maximum fee per gas the network quotes, times the custody provider's reserve multiple: 3 for Fireblocks, 4 for Ripple and 1 for the others. It never exceeds 10 of the network's currency. Below a fifth of that level, the platform refills the wallet from the refund splitter to the level, or to more, up to 10, when pending operations reserve more. When the network has no fresh fee quote, the check waits for the next run instead of guessing an amount.
The page does not list wallets that deployment configuration names for platform tasks. Operator wallet covers those.
Size a top-up
When a request is open, send at least the amount the sheet names as needed. The recommended amount also covers fee changes before the transfer lands. Operator wallet covers how a funding requirement calculates it.
Without an open request, the sheet suggests the amount that covers the organisation's warning days at the last seven days' rate of reserve spend, as “About <amount> covers <days> more days at last week's rate.” For example, with a warning at 14 days and 0.07 of the native currency spent over the last week, it suggests about 0.14. With no spend recorded, it shows no suggestion. The warning days are the gas tank alarms.
Check this page at least once per funding window, 30 minutes by default, rather than after a write fails. A wallet that empties pauses the work it pays for, and that work resumes once the wallet is funded, but only inside the funding window.
Choosing how to respond
Check the latest balance, the wallet's job, and any open request before you fund a wallet that reads Low.
What the platform does on the wallet type switch
Before the switch, the platform grants each smart wallet the on-chain roles its signing wallet holds. When roles have drifted and you do not hold the system admin role, the platform stops the switch and the failure names the smart wallets that need the grant.
The platform also registers each smart wallet under the identity its signing wallet holds.
When none of a person's custody accounts is registered and their identity is registered only on another wallet of theirs that no custody account holds, the platform registers that person's smart wallet under that identity, using the custody account that controls it, or, before it exists, their primary custody account, or their only one.
When those other wallets hold more than one identity, the platform cannot choose one, so it stops the switch before any write and the failure names the participant and the identities. Have an identity manager remove the wrong registration with Remove registration on the participant's page, then start the switch again.
When the organisation paid gas through the relayer on a network, the relayer stops paying for new writes and keeps its balance. It shows as Idle in the “Wallets” table, where the Permission manager role can withdraw the balance.
A write from an EOA wallet that was queued before the switch still goes through the relayer, and the relayer pays its gas. This covers a write that waits for its wallet checker across the switch. A write queued after the switch follows the network's new gas payer. Keep enough in the relayer for those queued writes before you withdraw its balance.
After the migration
The Wallet type row shows a lock and “Smart wallets”, with “Applies to every wallet in the organisation, on every network.” and “Since <date>. This cannot be switched back.” When the date is unknown, it reads only “This cannot be switched back.” Gas is set per network with “Change” on the “Gas payer” row. The row names any active network that has no EntryPoint yet, where wallets stay EOA wallets, and counts the networks ready for smart wallets, for example “2 of 3 networks ready for smart wallets”. A “Deployment” row shows a progress bar of deployed smart wallets for each network that reports them. The comparison table is part of the migration sheet and is not shown after the switch.
Under Deployment, one line per active network shows how many of the organisation's smart wallets are deployed on that network, for example “Polygon Amoy: 3 of 5 smart wallets deployed”. A smart wallet counts when it belongs to a participant that a member of the organisation acts as, or to one of the organisation's own participants. It counts as deployed once the platform has seen the wallet created on the network. A network with no smart wallets yet has no line.
Tokens needing role migration
For the network selected in the “Network” submenu, the page lists tokens whose participants still hold roles on their signing addresses rather than on their smart wallets. The section is titled Tokens needing role migration and says “These tokens have participants whose signing-address roles haven't been migrated to their smart wallets. Each token's admin must run the migration from the token's page.” Its columns are “Token”, “Symbol”, hidden until you add it, “Affected participants” and “Token admins”. When no token needs a role migration, the page does not show this section.
Troubleshooting
The balance has not changed after a top-up
Confirm that the transfer used the address and network the sheet showed, then wait for its on-chain confirmation. The platform reads the shared gas wallets' balances every few seconds, so a confirmed deposit shows within seconds. A transfer to the refund splitter moves on to the bundler wallet and the paymaster deposit, so check those rows.
A write failed with DALP-9087
The network refused the write for gas and the funding window closed before the wallet was funded, or the caller declined the pause. The error names the wallet and the shortfall. That wallet can be a participant's own wallet, which this page does not list as a shared gas wallet. Fund it, then submit the write again. DALP-9087 covers the error.
User transactions wait after a switch to “Relayer-paid”
The relayer wallet on that network holds too little to pay for them. Select Top up on the relayer wallet, or the button on its notice. Waiting transactions resume once the top-up lands, within the network's funding window.
The gas payer choices are unavailable
With EOA wallets, the Console offers Change to an organisation owner or a platform administrator. With smart wallets, the Permission manager, Gas manager or System manager role can change it. Relayer-paid works with EOA wallets only and Paymaster-paid with smart wallets only. The move to smart wallets cannot be undone.
“Withdraw” does not appear or the withdrawal fails
Withdraw is in the menu of an idle relayer wallet, bundler wallet, or paymaster deposit that holds a balance, on a network that charges gas, for the Permission manager role. The menu item says why when it is unavailable. A failed withdrawal names its cause: the address is not a wallet the organisation pays fees from on this network, the selected account lacks the System manager role a paymaster withdrawal needs, or the amount is more than the wallet can send now. For the last one, go back and select “Withdraw all”.
Turning sponsorship off or rotating the signing key affects an operation already in flight
Check the operation's status before retrying. The paymaster checks a sponsorship ticket against its current signer, so a ticket signed with the previous key can fail if the rotation confirms first.
The wallet type row is missing
The deployment does not offer smart wallets, or you do not hold the Permission manager, Gas manager or System manager role that shows Transaction funding. The row has no sidebar entry of its own. An old bookmark to the Wallet type page opens Transaction funding.
“Review the switch” is missing
The button shows only to an organisation owner or a platform administrator. Ask one of them to start the migration.
“Start migration” stays unavailable
Type MIGRATE exactly, in capitals. The button also stays unavailable while no network is ready for smart wallets, or
while a relayer write has not finished. Top up the relayer or cancel the write, then open the sheet again.
The migration fails to start
The sheet shows the reason. The platform denies the write unless you are an organisation owner or a platform administrator. When the failure names smart wallets whose roles drifted, ask a holder of the system admin role to start the migration. When it names a relayer write that has not finished, top up the relayer or cancel that write, then start again. When the switch waits for its own write, start again once that write lands. When it says the organisation's system is not indexed yet, wait until the network's system finishes indexing, then start again.
A network still uses EOA wallets after the migration
That network has no EntryPoint or bundler yet. Its wallets stay EOA wallets until the network is ready.
“Wallet type could not be read”
The row shows “Wallet type could not be read” with “The organisation's wallet type did not load. Try again.” Retry from the error card in the row.
Frequently asked questions
Does funding a wallet bring back a sponsored operation that already expired?
No. A sponsored operation carries its own expiry, separate from the funding wait. The platform renews an expired sponsorship on its own for a bounded number of rounds, and funding plays no part in that. An operation that still fails with an expired sponsorship needs the participant to submit it again. What happens when a wallet empties explains when renewal applies.
API routes
The Platform API reads and changes the same funding state. A system route acts on the organisation's default network unless the request sends X-Chain-Id with another chain ID. Amounts are decimal strings in wei, the currency's smallest unit.
How gas is paid and funded describes what each route returns and how to decline the funding pause. The request and response fields of each route are in the v2 API reference, under Transaction funding, Transactions and Organisation deployment.