Paymasters and gas sponsorship
How DALP uses system paymasters to sponsor eligible advanced accounts transactions without changing identity, custody, or asset policy checks.
Overview
A paymaster is the ERC-4337 component that can sponsor gas for eligible smart-account transactions. In DALP, paymaster sponsorship changes who funds gas. It does not change the participant, asset policy, custody approvals, or final transaction outcome checks. If you need to understand whether a transaction is eligible for sponsorship, start here.
Requires: advanced accounts enabled for the deployment.
Installation and enablement
DALP adds the paymaster node to organization setup only when Advanced accounts is globally enabled and the chain Directory contains a paymaster-signer entry. On eligible chains, the deployment step creates the paymaster-signer addon, resolves the chain EntryPoint, stages a signer key for sponsorship tickets, and binds that key to the deployed paymaster proxy.
If a prior deployment attempt already created the paymaster proxy, DALP reconciles the existing contract before deploying a new one. That replay path keeps onboarding idempotent: the workflow binds the staged signer key to the existing contract instead of creating a duplicate.
Installation is separate from runtime enablement. An installed paymaster can remain disabled for an organization. Operators enable or disable sponsorship from the advanced accounts control center or through the paymaster API configuration endpoint.
What the paymaster layer controls
| Question | DALP behaviour |
|---|---|
| Is a paymaster available on this chain? | The organization deployment tree includes the paymaster step only when Advanced accounts is globally enabled and the chain exposes a paymaster-signer Directory entry. |
| Is a paymaster installed for the system? | Operators can review paymaster availability from the advanced accounts control center or the paymaster API. |
| Is sponsorship enabled? | Admin, System manager, and Gas manager users can manage paymaster enablement where they have permission. |
| Is the paymaster funded? | Gas operations should check and fund the paymaster before relying on sponsored execution. |
| Which key signs sponsorship tickets? | Admin, System manager, Auditor, and Gas manager users can inspect signer-key status. Only Admin and System manager users can rotate the signer key. DALP does not expose private key material. |
| Does the smart wallet still need native balance? | If sponsorship is unavailable, disabled, unfunded, or not applicable, the smart account needs enough native token balance for execution. |
Sponsorship ticket checks
DALP paymasters validate sponsorship through signed tickets. Each ticket authorizes one smart account sender and one call data hash, bound to a specific organization, deadline, and maximum gas cost.
Rejection conditions: mismatched sender, changed call data hash, gas cost above the ticket limit, an uncodeable deadline, or a signature that does not recover to the trusted signer. For an expired ticket, the paymaster returns the ticket deadline as ERC-4337 validation data and the EntryPoint enforces expiry.
The ticket is bound to the sender and call data, not to a generic user session. If your integration needs single-use behaviour, the executed call path must consume or reject a nonce in the call data. The paymaster checks that the signed call data hash matches; it does not mark the authorization as spent by itself.
Limits for EVM transactions
Paymaster sponsorship applies only to EVM advanced accounts transactions submitted as UserOperations through DALP smart accounts and the chain EntryPoint.
It does not sponsor externally owned account transactions, direct contract calls outside the account abstraction flow, or chains where the paymaster signer addon is not available.
A sponsored UserOperation needs the full path to be ready. That means: advanced accounts enabled for the deployment, a Directory paymaster-signer entry for the chain, an installed paymaster proxy, sponsorship enabled for the organization, signer-key access, a valid ticket, and enough paymaster native balance. If any condition is missing, the smart account needs native token balance to execute.
DALP indexes only known tenant paymasters. UserOperation events that reference unknown or external paymasters do not make those paymasters part of the organization paymaster set.
Gas funding model boundaries
DALP's gas model is evaluated per smart-account transaction. The platform checks whether the wallet is indexed in the active system context, the availability of a system paymaster, the wallet's native token balance, and the gas cost reported by the connected chain. These checks help you decide whether a transaction can use sponsored gas or needs native tokens on the smart account.
Sponsorship is not an omnibus-wallet arrangement. DALP does not collapse participant assets or custody decisions into one shared operating wallet. You can use it to centralize network-fee payment for eligible UserOperations.
The smart account, participant identity, asset policy, custody approval, and transaction result remain separate parts of your workflow.
Use this rule of thumb:
| Situation | What to check next |
|---|---|
| Sponsorship is enabled and the system paymaster is funded | Verify the transaction is an eligible UserOperation through a DALP smart account. |
| Sponsorship is disabled, unavailable, unfunded, or not applicable | Check that the smart account has enough native token balance for execution. |
| The chain reports zero gas | Check chain status through operational monitoring, but do not treat zero gas as a custody or policy shortcut. |
| A direct externally owned account call is used | Treat it as outside the paymaster sponsorship path. |
What sponsorship does not replace
Gas sponsorship is separate from compliance and custody controls. You still need to verify asset eligibility, transfer policy, signer authority, custody provider approvals, transaction indexing, and webhook delivery independently.
Related pages
Bundlers
How DALP exposes an authenticated bundler JSON-RPC endpoint for ERC-4337 discovery, UserOperation submission, and ERC-7677 paymaster sponsorship.
Nonce lanes and ordering
How DALP maps UserOperations to ERC-4337 nonce lanes, why three distinct work states matter, and the trade-offs between strict, grouped, and independent ordering.