Transaction funding

Transaction funding decides who pays the network fee, called gas, for the organisation's transactions. It also tells you, for every network the organisation has enabled, whether transactions on it can pay for gas, which wallet pays, and where to send a top-up. The section has three tabs. Funding shows the balances and the verdict for every network at once, and is where you top up or withdraw from a paying wallet. Advanced accounts holds the configuration behind smart-account transactions: the capability itself, gas sponsorship, the refund split, the low-runway alarms, and the signing key. Meta transactions sets the organisation's account mode while its users keep plain wallets: each user pays their own gas, or an organisation wallet called the relayer pays it for them.

Come here before users start to transact, to choose who pays, and again on a schedule, to keep the paying wallet funded. The account mode applies to every user in the organisation at once. Choose an account mode compares the three modes and what each one costs.

This section replaces the earlier Advanced accounts and Operator wallets pages. A bookmark to either old page, or to the older platform-settings and admin addresses for them, lands here in one redirect: the old Operator wallets addresses open the Funding tab, and the old Advanced accounts addresses open the Advanced accounts tab. Each redirect keeps the query string and the fragment.

The sidebar shows one Transaction funding entry under Infrastructure in every account mode. The Meta transactions tab is always present. The Advanced accounts tab appears only when the deployment has the account-abstraction feature turned on. Without that feature, the tab is hidden and its URL redirects to the Funding tab.

Changing sponsorship, 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 payer'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 an account modeCopy Anchor Link

The account mode decides who pays gas when a user of the organisation signs a transaction. It is one organisation-wide setting with three values, and only one is active at a time. The mode does not change the network fee itself. It changes which wallet pays it and what you must keep funded.

Self-pay suits users who already hold the network's currency, and networks that charge no gas. Nothing on the organisation's side needs funding, but every signer who runs short stops until someone funds that signer.

Relayer-paid suits users who keep plain 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.

Advanced accounts suits organisations that need on-chain approval rules, account recovery, or sponsorship policies. It needs the deployment's account-abstraction feature, and the platform does not accept a move back to either plain-wallet mode.

What relayer-paid mode 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 plain wallets only, so a transaction from a smart-account sender fails at once.
• When the target contract does not accept the forwarder, the user's own wallet pays for that transaction, as in self-pay mode.
• 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, opens a funding requirement that names the relayer wallet, and shows the network as Blocked. A top-up that covers the requirement 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.

Switching modesCopy Anchor Link

Switch between self-pay and relayer-paid on the Meta transactions tab. Move to advanced accounts on the Advanced accounts tab. A new organisation picks its first mode during onboarding. The transactions that deploy the organisation are paid by the deploying wallet in every mode.

A switch changes how new transactions are paid. A transaction the platform already prepared for the relayer still goes through the relayer. Users keep the same wallet addresses in every plain-wallet mode, so a switch moves no assets and changes no permissions.

Entering relayer-paid mode creates a relayer wallet on each active network. Until a relayer holds enough, user transactions on its network wait. Leaving relayer-paid mode, in either direction, stops the relayer paying, and the relayer keeps its balance. It shows as Idle on the Funding tab, where you can withdraw the balance.

Network statusCopy Anchor Link

Each network has one status. The verdict sentence, the card, and the home dashboard's Transaction funding row all use it. When several apply, the worst one wins, in this order:

A network that charges no gas is always No funding needed, whatever its wallets hold, and its card never shows a warning or error colour. On a reserves network, the required payers are the bundler wallet, and the paymaster deposit while sponsorship is on. On a relayer network, the relayer wallet is the only required payer. The refund splitter, configured operator wallets, and any payer the current account mode does not use are listed for reference and do not set the network's status.

How a network pays gas. While advanced accounts are on but a network is still setting up, that network reads Setting up.

Who pays gas on a networkCopy Anchor Link

On a network where reserves or the relayer pay gas, the focused block lists every operator walletAn operator wallet lets your users transact without holding native gas: the platform pays the network fee, and you fund and monitor the wallet that covers it.Read the concept the platform tracks on that chain. Each row shows the wallet's role, a sentence about what it does, its address, what its balance measures, the measured amount at four decimals in the network's native currency, and a status.

A payer reads Low when its measured balance is below 0.1 of the network's native currency. The platform makes that judgment, not the Console. Not read yet means the platform has not read the balance yet, which is different from a balance of zero. A payer the current account mode does not use reads Idle and keeps its balance, unless an open funding requirement names it. That case is a transaction that started in an earlier mode and still waits on that wallet.

Deployment configuration registers a configured operator wallet. This section cannot add one: ask whoever operates your deployment. Once registered, the wallet appears here on the platform's own schedule.

In self-pay mode, the focused block for a gas network lists open signer funding requirements first, then any idle payer the organisation still holds.

Reserve runwayCopy Anchor Link

The runway chart plots the reserve runway, in days, over the platform's recent runway readings. It draws a dashed warning line and a dashed critical line at the organisation's low-runway alarm days, and states the current runway, for example About 12 days left. When no reserve spend is recorded yet, the chart says so instead of drawing a line.

Below the chart, a freshness line states when the shown balances were read, using the oldest reading among the payers. Balances come from the platform's periodic chain read, not a live query, so a new deposit can take a short time to appear.

Size a top-upCopy Anchor Link

When a funding requirement 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 requirement, 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.

A configured operator wallet has no runway. Size its routine top-up to its typical spend over the interval before you plan to check this section again, so it stays clear of the low mark between visits. A first top-up has no funding-requirement history to size from, because that history starts only when a shortfall happens.

Check this section 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 chain, 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 payer's role, and any open funding requirement before you fund a payer marked Low or Empty.

Meta transactions tabCopy Anchor Link

The Meta transactions tab sets the account mode for an organisation whose users keep plain wallets. Use it to switch between self-pay and relayer-paid, and to see at a glance whether each relayer can pay. Choose an account mode explains what each mode costs.

Switch between self-pay and relayer-paidCopy Anchor Link

Open the Meta transactions tab. Under Account mode, select Self-pay or Relayer-paid (meta transactions). A dialog states what changes:

• To relayer-paid: "The platform creates a relayer wallet on each active network. User transactions wait until that relayer wallet holds enough funds. User wallet addresses do not change."
• To self-pay: "Each user's wallet pays its own network fees again. The relayer wallet keeps its balance, which an admin can withdraw from the Funding tab. User wallet addresses do not change."

Select Switch to apply it, or Cancel to keep the current mode. The selector reads Saving the account mode. while the platform applies the change, then shows Account mode changed. When the change fails, the tab shows the reason and the selector returns to the stored mode. Only an owner or administrator of the organisation, or a platform administrator, can change the mode. Anyone else sees the selector unavailable, with that reason.

When the organisation uses advanced accounts, the tab shows Advanced accounts is active in place of the selector, because an organisation cannot switch back from advanced accounts. On a deployment with the account-abstraction feature, Open Advanced accounts opens that tab.

Check relayer fundingCopy Anchor Link

In relayer-paid mode, the tab lists the relayer wallet for each active network that charges gas under Relayer funding. Each row reads Enough, or Needs funding when the relayer is empty, low, or not read yet. Add funds opens the Funding tab focused on that network, where you top up the relayer. Right after a switch, a row can read that the relayer wallet is not visible yet. It appears shortly after the switch.

Advanced accounts tabCopy Anchor Link

The Advanced accounts tab configures the reserves, the sponsorship policy, and the signing key behind the organisation's smart-account transactions. The bundler submits these transactions, and the paymaster pays for sponsored gas. Balances and top-ups are on the Funding tab, and the tab links there. Sponsorship, the refund split, the alarms, and the signing key apply to the network the sidebar has active. On a network that charges no gas, the Gas sponsorship block shows No gas reserves required and offers only Technical details.

The tab has no effect on custody credentials, which are on the Custody page, or on on-chain roles, which are on Admins & roles.

Enable advanced accountsCopy Anchor Link

The capability card at the top of the tab shows whether advanced accounts are off, active, active with a warning, or still setting up. Select Enable Advanced accounts and confirm to route the organisation's new transactions through managed smart accounts. The setting is organisation-wide, and the platform does not accept turning it off again. Smart wallet explains why. The Gas sponsorship settings and the token role migration list appear once advanced accounts are on. When the organisation is in relayer-paid mode, the confirmation also states that the relayer wallet stops paying network fees and keeps its balance, which an admin can withdraw from the Funding tab.

Turn gas sponsorship on or offCopy Anchor Link

Open Manage in the Gas sponsorship block, then select Enable gas sponsorship or Disable gas sponsorship. Enabling takes two confirmations and deploys a paymaster contract for the organisation. The contract stays deployed if you later turn sponsorship off. Disabling means users pay their own gas. The reserves stay set up, and disabling does not refund the current reserve balance.

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 pays the bundler to include a transaction, and the sponsorship reserve, which funds the paymaster on the organisation's behalf. Open Manage, then Refund split (advanced), 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 Gas sponsorship block shows the result as the percentage of each deposit that goes to the sponsorship reserve.

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

Set low-runway alarmsCopy Anchor Link

Open Manage, then 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 Funding tab uses these days for the runway chart's lines, for the Low status while sponsorship is on, and for the suggested top-up.

Rotate the signing keyCopy Anchor Link

The signer key is the custodial key that signs sponsored transactions. Rotate it when it may be compromised: open Manage, then Rotate signing key. The option appears only once the organisation has a paymaster. The current key stops working as soon as the new one takes effect.

Technical detailsCopy Anchor Link

Technical details shows protocol-level state for platform implementers. It changes nothing. Edit sponsorship, the alarms, and the refund split from Manage.

Tokens needing role migrationCopy Anchor Link

This list names tokens whose participants still hold roles on their signing addresses rather than on their smart accounts, with the affected participant count and the token admins. Each token's admin runs the migration from that token's page.

TroubleshootingCopy Anchor Link

A network reads Unavailable

The funding read for that network failed, or no required payer has a balance reading yet. Select Try again on its attention row. A payer that reads Not read yet gets its first reading on the platform's own schedule.

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, and the freshness line shows when they were last read. 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 payer again on the network the sheet names.

A payer still reads Low 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 payer below the mark.

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

That error also fires when a participant's own executor wallet runs short of gas for their own request. That wallet is not an operator wallet. DALP-9087 names the wallet that came up short, so compare the address with the payer list before you fund anything here.

User transactions wait after a switch to relayer-paid

The relayer wallet on that network is empty or not funded enough yet. Open the Meta transactions tab, find the network that reads Needs funding, and select Add funds. Waiting transactions resume once the top-up lands, within the network's funding window.

A user still pays gas in relayer-paid mode

The transaction called a contract that does not accept the platform's forwarder, so the user's own wallet paid for it. Relayer-paid mode 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 mode cannot relay for wallets held with that provider. Move those wallets to a provider that can sign it, or use self-pay mode for the organisation.

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 account mode selector is unavailable

Only an owner or administrator of the organisation, or a platform administrator, can change the account mode. When the tab shows Advanced accounts is active, the organisation has moved to advanced accounts, and that move cannot be undone.

Withdraw is unavailable or the withdrawal is refused

Withdraw needs the Admin role and a balance above zero. A refusal 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.

The Advanced accounts tab is missing

The deployment does not have the account-abstraction feature turned on. The Funding tab still works, and each network that charges gas reads Signers pay in self-pay mode, or takes its status from the relayer wallet in relayer-paid mode.

A control is unavailable

Ask an Admin, Gas Manager, or System Manager to make the change. Those are the only roles the tab's controls accept.

Transactions stop routing through the bundler

Check the network's status and the reserve runway on the Funding tab, then the sponsorship state on the Advanced accounts tab. A depleted reserve or disabled sponsorship is why a smart-account transaction that used to be sponsored now needs a funded wallet. No other reserve pays automatically.

Smart-account transactions 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's runway keeps falling, top up that reserve directly.

Disabling sponsorship or rotating the signing key affects a transaction 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