Operator Wallet
An 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.
Two provisioning paths feed one tracked wallet kind. Console flags a low balance with no delay applied. The paging alert waits fifteen minutes to confirm it before firing.
An operator wallet lets your organization's users submit account-abstraction transactions without ever holding native gas themselves. The platform pays the network fee from a wallet it holds on your behalf, funded by whoever operates the deployment. Two provisioning paths land in one tracked classification: a wallet listed for monitoring, and the organization's own bundler wallet.
Operations configured for a funding pause wait for funds and can resume before the deadline runs out. 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, and setting your own alert threshold, is your decision.
Why the platform needs its own wallets
Account-abstraction operations are not any one participant's to pay for. When your users submit them, something has to bundle the operations and pay the network's gas token to land them on chain, and the platform does that through a wallet it holds on your behalf. Whoever operates the deployment funds that wallet, and no participant ever sees it as something they own or control.
An operator wallet running out of native token is not a problem to hand off to a participant. It is an operational problem you own, and the queue stalls long before anything fails outright. That gap is why the platform watches these balances continuously rather than waiting for a failed transaction to surface the shortfall.
Watching the balance, and what a low reading means
Balance monitoring includes wallets listed in deployment configuration and organization bundler wallets. One native-balance collector reads each such wallet's balance on its own chain and records it the same way regardless of which kind it is. That collector runs inside the platform's indexing system, the same system that first discovers each wallet. It drains an event-driven refresh queue on a fixed per-chain tick, so a balance update is not something a person has to trigger. Two separate surfaces then watch that stored balance against a low-balance cutoff, 0.1 of the chain's native token by default: the payer status in Console's Transaction funding section, and a monitoring alert. Each one applies the cutoff independently rather than reading it from a shared source, and only the alert's cutoff can currently be moved off that default.
Console's Transaction funding section lists the wallets tracked this way on each network where reserves pay gas, with the role each one plays. 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 actually zero. 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. Who pays gas on a network covers how to read the list and where deployment configuration registers a wallet for it.
The two surfaces do not update on the same rhythm. Console's payer status marks a wallet as low the moment its recorded balance crosses the cutoff. The alert is more patient by design: it 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 Console for several minutes before the alert confirms it and fires.
They can also disagree for a second reason, and today that one is unresolved rather than intentional. The Console payer status and the alerting rule are meant to read the same cutoff. Only the alert currently reads it as a deployment setting, dalp.observability.nativeBalance.lowThreshold, and the alert text names it so an operator reading the page knows what to change. The payer status applies its own fixed 0.1 native and does not read that setting. Move the alert threshold and the two surfaces report different wallets as low.
The cutoff is 0.1 whole units of the chain's own native currency, on every chain. The indexer divides each balance by that chain's decimals before publishing it, so the one figure means the same amount everywhere. The cutoff measures native-token units, not a common fiat value across networks.
What happens when a wallet empties
An operator wallet that empties does not fail the work it pays for, and expecting a failure is how an incident gets misread. When a wallet cannot cover what it owes, the platform pauses that work, records a funding requirement against the organization, and waits. Nothing is broadcast to the chain, so nothing is half-done. Queued account-abstraction operations return to the queue rather than failing, and the next run picks them up. 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. An integration with no Console open can subscribe to the funding.requirement.raised, funding.requirement.resolved, and funding.requirement.expired webhook events to learn the same thing. No separate transaction status marks a request as paused for funding, so a caller polling a transaction sees it sitting rather than failing.
The queue holds while you fund. The only thing the clock changes is 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 chain. Once it elapses, the paused work stops waiting and fails with the gas required error, DALP-9087, naming the address and the shortfall. A queue becomes an incident at that moment, which is why a low reading deserves attention 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 repeats this for a bounded number of rounds that roughly covers the funding window. Only when those rounds run out, or when the sponsorship expired before signing finished, is the operation failed rather than requeued. 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 on an operator wallet almost always calls for one response: top the wallet up. Two narrower responses exist for specific situations. Raising the alert threshold only makes sense when gas costs or chain economics on that chain have genuinely moved. That threshold is a deployment setting rather than a Console control, and the Console payer status keeps its own fixed cutoff, so the two disagree once the threshold is raised. Waiting instead of funding only makes sense when a transfer already sent will clear the dip before the funding window closes. Transaction funding walks through choosing between the three 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 organization'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 rather than the bundler wallet's balance alone. It is not the number the low-balance cutoff above watches, so treat it as a second signal to check rather than a value that pages anyone. Transaction funding is where that runway is charted.
Nothing tops these wallets up automatically, with one narrow exception. When a sponsored operation settles, part of its gas cost returns as a refund. A splitter contract routes a configured share of that refund to the organization's bundler wallet instead of letting all of it settle to the paymaster's deposit. Two settings decide how much reaches the bundler this way: the share itself, set in basis points, and a sponsorship toggle that redirects the entire refund to the bundler when sponsorship is off. That mechanism only moves value the deployment already holds. It never creates funds, and it never reaches a wallet you registered for monitoring.
This is also a different failure from the gas required error, DALP-9087, a participant can see in Console for their own request. That error names the caller's own resolved executor wallet, never a shared operator wallet, so a participant seeing it needs to fund their own wallet rather than report an operator-wallet shortage.
Two provisioning paths, one classification
Two independent bootstrap passes populate that tracking. The first pass registers wallets an operator has explicitly listed for monitoring. The second reads each organization's own managed wallets and classifies them the same way: the bundler wallet, which sponsors gas for that organization's account-abstraction operations, and the relayer wallet, which pays gas for its meta transactions when the organization uses relayer-paid mode. Both passes record the wallet under the same classification, which is what lets one metric query cover both wallet kinds without knowing which path registered any particular wallet.
Both passes are reconciliations that repeat on a schedule rather than one-shot steps run once at startup. A bundler wallet belonging to a system the platform has not yet indexed is left unresolved and picked up on a later pass. A deployment converges on the correct wallet set over time this way, instead of depending on everything being indexed in the right order the first time.
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 threshold continuously, so a single reading at or above it restarts the fifteen-minute window. Console has no window to reset: its payer status follows the recorded balance and moves with it. A wallet hovering around the cutoff can therefore flicker in Console for a long time without ever paging anyone, which matters when you are treating a quiet pager as proof the balance is healthy.
Why does a wallet at zero not page on a development chain?
Because 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. Console agrees on such a chain: its Transaction funding section marks the network as needing no funding and never marks its wallets low.
Can both provisioning paths register the same wallet twice?
No. Both passes record the wallet under the same classification in the same tracking record, so a wallet reached by both paths is tracked once, read by one collector, and listed once in Console. Which path registered a wallet makes no difference to how it is watched or alerted on afterwards, so there is nothing to deduplicate and no ordering between the passes to get right.
Two workflows stall on the same wallet. Do I get two funding requirements?
No, one. Only one funding requirement can be active per organization, per wallet, per chain, 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, and they can do different jobs. 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.
Maker-checker
Maker-checker keeps a single mistaken instruction or a single compromised account from moving money, filing a report, or approving a corporate action alone.
Ledger Data
Ledger Data lets an integration answer a holder list, a transfer history, or a compliance check with one query, instead of decoding chain events itself.