Transaction funding

Transaction funding decides who pays the network fee, called gas, for the organisation's transactions. The page shows one network at a time: the network selected in the sidebar network switcher. For that network, it says who pays gas, which shared gas wallets pay it, which wallets wait for funds, and where to send a top-up. To see another network, select it in the sidebar. The page has no network choice of its own.

Two settings decide who pays. The wallet type is one choice for the whole organisation: EOA wallets or smart wallets. An EOA wallet, or externally owned account, is a plain wallet controlled by one key. The gas payer is one choice per network, and you change it on this page. Choose a gas payer compares the options and what each one costs. The wallet type has its own page, Wallet type, because the move to smart wallets is one-way.

Come here before users start to transact, to choose who pays, and again on a schedule, to keep the paying wallets funded.

This page replaces the earlier Advanced accounts and Operator wallets pages and the earlier tabs of this section. A bookmark to an old address lands on a current page in one redirect. The old Operator wallets addresses and the old Meta transactions tab open Transaction funding. The old Advanced accounts addresses and the old Advanced accounts tab open Wallet type, which opens Transaction funding when the deployment does not offer smart wallets.

Turning sponsorship on or off, adjusting the refund split, or rotating the signing key is one of the operations the organisation's Audit trail records, with your name and your role at the time. A top-up is an on-chain transfer that you send from another wallet, not a Console operation, so it has no Audit trail entry. The wallet's new balance is what confirms it. A withdrawal is a transaction the platform sends from the paying wallet, and it appears on the transactions page.

StepsCopy Anchor Link

Choose a gas payerCopy Anchor Link

Two settings decide who pays gas when a user of the organisation signs a transaction. Neither changes the network fee itself. They change which wallet pays it and what you must keep funded.

• Wallet type, one choice for the whole organisation: EOA wallets, or smart wallets with approvals and recovery. The move from EOA wallets to smart wallets is permanent. It is made on Wallet type.
• Gas payer, one choice per network. With EOA wallets, each user pays (Self-pay) or the organisation's relayer pays (Relayer-paid). With smart wallets, each smart wallet pays (Self-pay) or the organisation's paymaster pays (Paymaster-paid).

The organisation picks its wallet type, and the gas payer for its first network, during onboarding. Each network the organisation adds later starts with each user paying. After a move to smart wallets, every network starts on Self-pay. You change the gas payer one network at a time with Change gas payer.

Self-pay suits users who already hold the network's currency, and networks that charge no gas. With EOA wallets, nothing on the organisation's side needs funding, but every signer who runs short stops until someone funds that signer. On a network that charges no gas, users can already send from their own wallets, so Relayer-paid or Paymaster-paid only adds an extra step there and Self-pay is simpler.

Relayer-paid suits users who keep EOA wallets and should never hold gas. The organisation funds one wallet per network instead of one per user. A meta transaction is a transaction the user signs and another wallet submits. The user's wallet signs a request. The relayer wallet sends that request to the platform's forwarder contract and pays the fee, and the target contract records the user as the sender. The relayer cannot change the request, because the forwarder checks the user's signature before it runs it. In Activity, such a transaction shows the user as the sender and the relayer as the on-chain sender.

Paymaster-paid suits smart-wallet users who should never hold gas. The bundler wallet submits each operation and fronts the gas, and the paymaster's deposit at the EntryPoint contract pays it back in the same transaction. Both must stay funded. Choosing Paymaster-paid turns sponsorship on for that network, and choosing Self-pay turns it off. The paymaster contract stays deployed while sponsorship is off, and turning it off does not refund the deposit.

How a write reaches the chain on one network. On a network that charges no gas, the same route runs and no fee is paid.

What Relayer-paid does not coverCopy Anchor Link

The relayer pays only for transactions it can relay. Four limits decide what happens to the rest:

• The forwarder accepts signatures from EOA wallets only, so a transaction from a smart-wallet sender fails at once.
• When the target contract does not accept the forwarder, the user's own wallet pays for that transaction, as with Self-pay.
• The relayer does not fund native currency that a call sends with it, so such a transaction fails at once.
• When the user's custody provider cannot sign the request, the transaction fails with an error that names the provider.

You can cancel a relayed transaction until it is confirmed. After the relayer submits it, a cancel makes the relayer send an empty transaction in its place, at the same position in the relayer's queue and at a higher fee. When the empty transaction confirms first, the platform does not send the user's request again, and the user's wallet signs nothing new. The signed request stays valid at the forwarder until its deadline, about 40 minutes after signing. In that time, anyone who copied the request from the network can still submit it to the forwarder.

Each signed request has a deadline. When the network confirms the relayer's transaction after that deadline, the forwarder rejects it and the user's request does not run. The platform then has the user's wallet sign the request again and the relayer sends it again, up to three times. After a fourth rejection, the transaction fails with the forwarder's reason. The platform does not sign again when the user's position in the forwarder's order moved after the first signature, because the request may already have run. The transaction then fails instead.

One relayed transaction per wallet at a timeCopy Anchor Link

The forwarder runs each user's requests in a fixed order, and a request it did not run leaves that order unchanged. The platform therefore sends one relayed transaction per user wallet per network at a time. The next one from the same wallet waits until the previous one completes. Transactions from different users do not wait for each other. A user who starts five transfers in a row sees them confirm one after another, not together.

When the relayer runs out of fundsCopy Anchor Link

A relayed transaction that the relayer cannot pay for does not fail at once. The platform pauses it and opens a funding ask that names the relayer wallet, which appears under Open funding asks. A top-up that covers the ask releases every transaction waiting on that relayer. Work still waiting when the network's funding window closes fails with the gas required error, DALP-9087.

Changing who paysCopy Anchor Link

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 between gas payers 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. Until the relayer holds enough, user transactions on that network wait. Switching it back to Self-pay stops the relayer paying, and the relayer keeps its balance. It shows as Idle under All wallets, where an admin can withdraw the balance. If you switch that network back to Relayer-paid later, the platform uses the same relayer wallet and its balance again.

Shared gas walletsCopy Anchor Link

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.

Each row shows the wallet's job, its balance in the network's native currency, its address with a copy button, an explorer link when the network has an explorer, and a status:

• Active · above or Active · below, followed by the wallet's top-up level. A wallet reads below when its balance is under 0.1 of the network's native currency. The platform makes that judgment, not the Console.
• Active when the platform has no balance reading or top-up level for the wallet yet. The balance then reads No reading yet, which is different from a balance of zero.
• Active · holds refunds for the refund splitter. A balance there is unswept refunds.
• Idle for a wallet the current gas payer does not use. When it still holds a balance, the row notes that the balance is left over from an earlier mode.
• No gas charged here on a network that charges no gas. No wallet needs a balance there.

The page does not list wallets that deployment configuration names for platform tasks. Operator wallet covers those.

Size a top-upCopy Anchor Link

When an ask is open, send at least the amount the sheet names as needed. The larger amount it shows also covers fee changes before the transfer lands. Operator wallet covers how a funding requirement calculates that recommendation.

Without an open ask, the sheet suggests the amount that covers the organisation's warning days at the last seven days' rate of reserve spend. 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. When no spend is recorded, the sheet shows no suggestion. The warning days are the gas tank alarms.

A first top-up has no ask history to size from, because that history starts only when a shortfall happens.

Check this page on a schedule, not after an operation fails for lack of gas. A wallet that empties does not fail the work it pays for at once: the platform pauses that work and resumes it automatically once the wallet is funded again. Each shortfall carries a funding window set per network, and work still waiting when that window closes fails with the gas required error, DALP-9087.

Choosing how to respondCopy Anchor Link

Check the latest balance, the wallet's job, and any open ask before you fund a wallet that reads below its top-up level.

Advanced gas settingsCopy Anchor Link

The advanced section of the Change gas payer sheet shows the settings behind the gas payer on the sidebar network. It has no effect on custody credentials, which are on the Custody page, or on on-chain roles, which are on Admins & roles.

With EOA wallets, the section 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, the section is Advanced: bundler, gas tank and sponsorship. It shows the addresses of the EntryPoint and the paymaster on the network, or Not deployed. It also opens the gas tank alarms and the refund split, and shows the signing key once the organisation has a paymaster on the network. Without the Admin, Gas Manager, or System Manager role, these controls are unavailable. The platform accepts a key rotation from the System Manager role only.

Set gas tank alarmsCopy Anchor Link

Select Gas tank alarms to open Low-balance alarms. Enter the warning and critical alarms in days of runway left: whole numbers of at least 1, with the critical alarm fewer days than the warning alarm. The warning days also size the suggested top-up.

Set the refund splitCopy Anchor Link

A sponsored operation's gas cost can return in part after settlement. The refund splitter divides each amount it receives between the submission reserve, which is the bundler wallet, and the sponsorship reserve, which is the paymaster deposit. Select Refund split and enter the submission reserve's share in basis points, a whole number from 0 to 10,000. The rest goes to the sponsorship reserve. The refund split lives on the splitter contract, so saving it asks for your wallet verification to sign the update.

The split only divides value that reaches the splitter. Each reserve keeps draining from its own spend, whatever the split.

Rotate the signing keyCopy Anchor Link

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 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.

TroubleshootingCopy Anchor Link

The page reads Transaction funding could not be read

The funding read for the sidebar network failed. Select Try again. A wallet that reads No reading yet gets its first reading on the platform's own schedule.

The page shows a different network than expected

The page follows the network selected in the sidebar network switcher. Select the network there. A link to this page cannot choose the network.

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. Balances come from the platform's periodic chain read, so a new deposit can take a short time to appear. A transfer to the paymaster lands in its EntryPoint deposit, and a transfer to the refund splitter moves on to the bundler wallet and the paymaster deposit, so check those rows.

The transfer will not confirm

Look up the transaction by its hash in a block explorer for that network. A transaction that stays pending can mean a low gas fee, a pending earlier nonce, or a network problem. The Console cannot change that. Speed up or replace the transaction from the wallet or service you sent it from.

You sent to the wrong network

A transfer confirmed on the wrong network cannot move itself to the right one. Recovery depends on that network and the wallet you sent from. Fund the wallet again on the network the sheet names.

A wallet still reads below its top-up level after funding

Confirm that the funded amount lifted the balance above 0.1 of the network's native currency. A partial top-up can leave the wallet below the mark.

The gas required error, DALP-9087, names a wallet this page does not list

That error also fires when a participant's own wallet runs short of gas for their own request. That wallet is not a shared gas wallet. DALP-9087 names the wallet that came up short. Its ask appears under Open funding asks, where you can fund it.

User transactions wait after a switch to Relayer-paid

The relayer wallet on that network is empty or not funded enough yet. Select the network in the sidebar, then select Add funds on the relayer wallet or Fund on its open ask. Waiting transactions resume once the top-up lands, within the network's funding window.

A user still pays gas on a Relayer-paid network

The transaction called a contract that does not accept the platform's forwarder, so the user's own wallet paid for it. Relayer-paid covers only contracts that accept the forwarder. Fund that user's wallet for these transactions.

A relayed transaction fails and names the custody provider

That custody provider cannot sign the request the relayer submits for the user. Relayer-paid cannot relay for wallets held with that provider. Move those wallets to a provider that can sign it, or use Self-pay on the networks those users transact on.

A user's transactions confirm one at a time

The platform sends one relayed transaction per user wallet per network at a time, because the forwarder runs each user's requests in a fixed order. The next one starts when the previous one completes. This is expected, and it does not slow down other users.

The gas payer choices are read only

With EOA wallets, only an owner or administrator of the organisation, or a platform administrator, can change the gas payer. With smart wallets, the Admin, Gas Manager, or System Manager role can. When the organisation uses smart wallets and the network is not ready for them yet, the choices stay read only.

Relayer-paid or Paymaster-paid is unavailable

Relayer-paid works with EOA wallets only, and Paymaster-paid with smart wallets only. Paymaster-paid appears only when the deployment offers smart wallets. Change the wallet type on Wallet type. The move to smart wallets cannot be undone.

Withdraw does not appear or the withdrawal fails

Withdraw appears only under All wallets, on an idle relayer or bundler wallet that holds a balance, on a network that charges gas, and only for the Admin role. A failed withdrawal names its cause: the address is not a wallet the organisation pays fees from on this network, a paymaster deposit cannot be withdrawn, or the amount is more than the wallet can send now. For the last one, select Edit, then Withdraw all to take the current maximum.

Smart-wallet operations fail because the bundler wallet's custody policy held a bundle for approval

The bundler wallet signs every bundle the organisation submits, so it must sign without a custody approval policy. When the custody provider holds a bundle for approval, rejects it, or lets the approval expire, the platform fails the transactions in that bundle at once and names the policy in the failure. It does not sign the bundle again. Exempt the bundler wallet from approval policies in your custody provider, then submit the transactions again.

The refund split value is rejected

Enter a whole number of basis points between 0 and 10,000. The control checks the range before it saves, so a value outside it stays blocked rather than clamped.

One reserve keeps draining faster than the other after a split change

The refund split changes nothing about how fast each reserve is spent. If one reserve keeps falling, top up that wallet directly.

Turning sponsorship off or rotating the signing key affects an operation already in flight

Check the operation's status before retrying. The paymaster validates a sponsorship ticket against its current signer, so a ticket signed with the previous key can fail if the rotation confirms first.

Frequently asked questionsCopy Anchor Link