Gas reserves

Advanced accounts in DALP rely on two separate gas reserves: the Submission reserve and the Sponsorship reserve. They serve different purposes, carry different urgency when low, and must be managed independently.

The Submission reserve is always required. The Sponsorship reserve is only relevant when the platform actively sponsors user gas. Keeping them distinct makes the difference between an operational emergency (submission empty) and a deliberate policy choice (sponsorship off) immediately visible.

For the procedures that fund, configure, and troubleshoot these reserves, see the Gas reserves operations runbook.

The two reserves and what they fund

Submission reserve

The Submission reserve covers the cost of getting any advanced-account transaction on-chain. Every UserOperation, regardless of whether it is sponsored, must be relayed by the bundler. The bundler uses its own wallet balance to pay for that relay. That wallet balance is the Submission reserve.

The reserve is always required when advanced accounts is enabled. There is no configuration that makes it optional. If the balance drops to zero, no advanced-account transaction can be submitted. The platform stalls for every participant whose workflow depends on advanced accounts.

A low-balance alarm triggers at a fixed 0.05 ETH (or equivalent native token). Because the threshold is fixed, the primary operational signal is the balance itself rather than a configurable runway.

On any network that charges gas, the Submission reserve must hold a positive balance at all times. Every relay spends native token, so an empty reserve means no advanced-account transaction reaches the chain. The only case where funding is not required is a zero-gas network, where relays cost nothing. DALP still shows the reserve on a zero-gas network so you can confirm the chain is configured as zero-gas rather than simply unfunded. If you operate on a public or fee-charging chain, treat keeping this reserve funded as a standing operational duty, not a one-time setup step.

Sponsorship reserve

The Sponsorship reserve covers the portion of transaction gas that the platform pays on behalf of participants, enabling gasless transactions where users do not pay from their own wallets. The reserve is backed by the paymaster's deposit in the ERC-4337 EntryPoint contract.

The reserve is only meaningful when gas sponsorship is enabled. Disabling sponsorship is a deliberate operator choice, not a fault condition. When sponsorship is on and the reserve runs low, sponsored transactions begin to fail, and participants may need to pay their own gas until the reserve is replenished.

Runway is the primary monitoring signal for the Sponsorship reserve. DALP calculates it as:

runway days = sponsorship balance / (total gas sponsored in last 7 days / 7)

When there has been no sponsored activity in the last seven days, runway is blank. There is nothing to measure, so no estimate is possible.

Default alarm thresholds for sponsorship runway are 14 days (warning) and 5 days (critical). Both thresholds are configurable by a System Manager.

Why the reserves are separate

Conflating the two reserves hides a critical distinction in operational urgency.

The Submission reserve is infrastructure. Without it, the platform cannot process advanced-account transactions at all. A depleted Submission reserve is an emergency that affects every participant in every workflow.

The Sponsorship reserve is policy. Whether to sponsor gas is a deliberate decision. Turning sponsorship off, or letting the reserve run to zero while disabling sponsorship, may be entirely intentional. A depleted Sponsorship reserve means participants pay their own gas, which may be acceptable or unacceptable depending on the platform's commitments to those participants.

Separating them means operators can read the status at a glance and respond appropriately to each signal without conflating infrastructure failure with policy configuration.

The status ladder

DALP orders reserve statuses from most urgent to least urgent. The most urgent condition visible takes precedence in the display.

"Sponsorship off" is not a warning. It appears when an operator has intentionally disabled sponsorship. No action is required unless the platform is supposed to be offering gasless transactions to participants.

What happens when each reserve runs dry

When the Submission reserve empties, DALP cannot relay any UserOperation. Every participant using advanced accounts is affected simultaneously. Transactions queue up or fail at submission. Restoring normal operation requires topping up the bundler wallet and waiting for the balance to confirm on-chain.

When the Sponsorship reserve empties (and sponsorship is enabled), sponsored transactions stop. DALP either fails those transactions or falls back to requiring the participant to pay their own gas, depending on how the smart account is configured. Non-sponsored advanced-account transactions continue because they do not draw from the Sponsorship reserve.

A platform that has both reserves funded and sponsorship on is in the normal operating state: the bundler can relay, the paymaster can cover gas, and participants transact without paying from their own wallets.

Refund allocation

When a sponsored transaction produces a gas refund, DALP can split that refund between the two reserves. The configurable parameter is the Submission reserve share, expressed in basis points from 0 to 10,000 (where 10,000 = 100%). The remainder goes to the Sponsorship reserve.

For example, a Submission reserve share of 3,000 bps (30%) means that 30% of each refund goes to the bundler wallet and 70% goes back into the paymaster's EntryPoint deposit.

The split is a secondary funding mechanism. It reduces how often operators need to top up manually, but it does not replace proactive monitoring and funding. Refunds are proportional to actual gas savings, so a platform with low transaction volume should not rely on the split to maintain adequate reserves.

Related

• Gas reserves operations runbook for step-by-step funding, configuration, and troubleshooting procedures.
• Advanced accounts control center for the broader advanced-accounts infrastructure view, including bundler and paymaster status.