Two provisioning paths feed one tracked wallet kind, flagged low in the Console at once and by the paging alert after fifteen minutes below the cutoff.
An operator wallet is a wallet the platform sends from and pays network fees with for your users: the organisation's bundler wallet, its relayer wallet, or a wallet the deployment lists for monitoring. The organisation funds its bundler and relayer wallets, and the deployment operator funds the wallets its configuration lists.
Work pauses for funds by default and resumes when the wallet is funded inside the funding window. Other terminal conditions, such as an expired sponsorship, can still end an operation for reasons unrelated to gas.
Nothing tops a wallet listed for monitoring up for you, and no target balance or runway is published for it. Sizing the top-up is your decision. The low-balance cutoff is fixed at 0.1 of the chain's native currency and is the same for the alert and the Console.
Why the platform needs its own wallets
When your users submit account-abstraction operations or meta transactions, something has to send them and pay the network's gas token to land them on chain. The platform does that from wallets it holds for the organisation: the bundler wallet sends user operations and pays their gas up front, and the relayer wallet sends meta transactions. Under Paymaster-paid the paymaster deposit repays the bundler, so users hold no native gas. Under Self-pay each smart wallet repays it. No participant owns or controls these wallets. The alternative, each user holding native currency, is the Self-pay choice that Gas sponsorship compares.
A participant cannot fix an empty operator wallet, so the organisation or the deployment operator owns that problem. The queue stalls long before anything fails, so the platform watches these balances continuously instead of waiting for a failed transaction.
Watching the balance, and what a low reading means
Balance monitoring covers the wallets listed in deployment configuration and each organisation's bundler and relayer wallets. A wallet is tracked once, whichever way it was registered, and the platform refreshes each recorded balance on its own, so nobody triggers an update by hand.
Two surfaces watch that recorded balance against one low-balance cutoff of 0.1 of the chain's native token: the payer status on the Console's Transaction funding page, and a monitoring alert. The platform publishes the cutoff for each network alongside the balances, and the alert compares each wallet against that published figure, so both surfaces use the same cutoff. They can still list different wallets: the Console judges the paymaster on its deposit, and the alert also watches wallets the deployment lists for monitoring. The cutoff has no deployment setting. A deployment that still sets dalp. fails to install the monitoring chart until the setting is removed.
The Console's Transaction funding page lists the organisation's shared gas wallets on the network the sidebar has active, such as its relayer wallet and its bundler wallet, with the job each one does. It shows the balance the platform last recorded and a status the platform judges, and it tells apart a balance nobody has read yet from a balance that is zero. It does not list wallets that deployment configuration names, and it has no control that registers a wallet for tracking. Its top-up sheet gives the address and a suggested amount for a transfer you send from another wallet. Shared gas wallets covers how to read the list.
The two surfaces do not update on the same rhythm. The Console payer status marks a wallet as low the moment its recorded balance crosses the cutoff. The alert only fires once the balance has stayed below the cutoff continuously for fifteen minutes, so a brief dip that a top-up transaction is already correcting does not page anyone. A wallet can therefore show as low in the Console for several minutes before the alert confirms it and fires.
The cutoff is 0.1 whole units of the chain's own native currency, on every network. The platform divides each balance by that chain's decimals before publishing it, so the one figure means the same native amount everywhere, with no common fiat value across networks.
What happens when a wallet empties
When an operator wallet empties, the platform pauses the work it pays for, records a funding requirement against the organisation, and waits. A paused write has not been broadcast, so it has no partial effect on chain. A queued account-abstraction operation is held as BLOCKED until the payer is funded. How gas is paid and funded covers the requirement and the writes that fail instead of pausing.
The funding requirement is the signal to look for. It names the wallet, the shortfall and a recommended amount to send, and it moves from active to resolved on its own once the money arrives. A paused transaction request keeps its state, and its status read names the open requirement in activeRequirement.
An integration with no Console open can subscribe to funding., funding. and funding. to learn the same thing. The funding event catalogue explains each event. These events need an explicit subscription, because the default subscriptions skip them.
The queue holds while you fund, and the clock decides only whether the work you were waiting on is still there at the end.
The wait is bounded. Each funding requirement has a window set per network. Once it elapses, the paused work stops waiting and fails with the gas required error, DALP-9087, naming the address and the shortfall. Act on a low reading before the alert confirms it.
One related failure looks similar and behaves differently. An account-abstraction operation the platform has already agreed to sponsor has its own expiry, and funding a wallet does not extend it. When a sponsorship expires while the operation waits in the bundler, before anything is submitted, the platform prepares the operation again with a fresh sponsorship and signs it again. It does this up to three times. An operation the caller signed itself is not prepared again and fails at once. After the third renewal lapses, or when the sponsorship expired before signing finished, the operation fails. The message a participant sees then says the sponsorship expired before it reached the chain, that nothing was submitted and nothing was charged, and that they can start again. If a multi-party approval was collected for it, that approval has to be collected again too.
Deciding what to do about a low reading
A low reading calls for a top-up. Waiting instead of funding only makes sense when a transfer already sent clears the dip before the funding window closes. The cutoff itself is not adjustable: the alert and the Console payer status read the same 0.1 mark, so neither can be moved without the other. Transaction funding walks through choosing between the two and the steps for each.
There is no configured target balance for a wallet listed for monitoring, and nothing measures how fast it spends, so there is nothing to project into a runway for it. What the platform gives you instead is per-shortfall guidance: when a funding requirement is raised, it recommends an amount that covers the measured cost with headroom on top. Size a routine top-up for that kind of wallet from your own history of those recommendations.
The organisation's bundler wallet is different. The platform already tracks its seven-day gas burn and combines it with the paymaster deposit and the refund splitter's own balance to record a runway in days for that chain, a spending-rate picture a monitored wallet has no equivalent of. That recorded runway spans the whole refund loop, not the bundler wallet's balance alone. The low-balance cutoff does not watch it, so treat it as a second signal that pages no one. Transaction funding uses that spending rate to suggest a top-up amount.
Nothing tops these wallets up automatically, with one narrow exception. The refund splitter routes a configured share of each gas refund to the organisation's bundler wallet. It only moves value the organisation already holds, and it never reaches a wallet listed for monitoring.
The gas required error, DALP-9087, names the wallet that was refused, in its data.address. When that is the participant's own wallet, the participant funds it. When it is a shared gas wallet, such as the relayer wallet, the bundler wallet or the paymaster deposit, the organisation does.
Frequently asked questions
Does the fifteen-minute confirmation reset if the balance briefly recovers?
Yes. The alert fires only when the balance has stayed below the cutoff continuously, so a single reading at or above it restarts the fifteen-minute window. The Console has no window to reset: its payer status follows the recorded balance. A wallet hovering around the cutoff can flicker in the Console for a long time without paging anyone, so a quiet pager is no proof that the balance is healthy.
Why does a wallet at zero not page on a development chain?
The alert excludes chains that report their gas as free. On a chain where transactions cost nothing, zero is the expected resting balance of every wallet, so paging on it would be noise. The exclusion applies at any balance, not only at zero. The Console agrees on such a chain: its Transaction funding page marks the network as needing no funding and never marks its wallets low.
Two workflows stall on the same wallet. Do I get two funding requirements?
No, one. Only one funding requirement can be active per organisation, per wallet, per network, so a second piece of work short on the same wallet attaches to the existing requirement instead of raising its own. The workflows share the requirement, but each checks the funds it needs before continuing. Concurrent spending can require another top-up.
What does the recommended amount on a funding requirement cover?
Two numbers travel with a requirement. The amount that releases the pause is what the refused work itself needed, measured at the refusal with a buffer for fee drift. When the platform has a forecast for the remaining work, the recommended total is larger and sized so one transfer can cover the whole run. When it does not, the recommendation is the same amount as the shortfall. Sending only the smaller amount is valid and releases the pause, but the wallet can run short again a few steps later and raise a new request.