# Paymasters and gas sponsorship

Source: https://docs.settlemint.com/docs/architects/concepts/paymasters-and-gas-sponsorship
How DALP uses system paymasters to sponsor eligible account abstraction transactions without changing identity, custody, or asset policy checks.



## Overview [#overview]

A paymaster is the account abstraction component that can sponsor gas for eligible smart-account transactions. In DALP, paymaster sponsorship changes who funds gas. Paymaster sponsorship does not change the participant, asset policy, custody approvals, or final transaction outcome checks.

## Installation and enablement [#installation-and-enablement]

DALP adds the paymaster node to organization deployment only when Account Abstraction is globally enabled and the chain Directory contains a `paymaster-signer` entry. On eligible chains, organization deployment 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 proxy before deploying a new one. That replay path keeps onboarding idempotent: the workflow can bind the staged signer key to the existing proxy instead of creating a duplicate paymaster.

Installation is separate from runtime enablement. An installed paymaster can remain disabled for an organization. Operators enable or disable sponsorship from the Account Abstraction Control Center or through the paymaster API configuration endpoint.

## What the paymaster layer controls [#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 Account Abstraction 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 Account Abstraction 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 [#sponsorship-ticket-checks]

DALP paymasters validate sponsorship through signed tickets. A ticket authorizes one smart account sender and one call data hash for a specific organization, deadline, and maximum gas cost. The paymaster rejects the UserOperation when the sender does not match, the call data hash changes, the requested gas cost exceeds the ticket limit, the deadline is too large to encode, or the signature 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 an 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 ticket as spent by itself.

## Limits for EVM transactions [#limits-for-evm-transactions]

Paymaster sponsorship applies only to EVM account abstraction 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 still needs the full sponsorship path to be ready: Account Abstraction enabled, a Directory `paymaster-signer` entry for the chain, an installed paymaster proxy, enabled sponsorship for the organization, signer-key access, a valid sponsorship ticket, and enough paymaster native balance. If any of those conditions is missing, the smart account needs native token balance to execute the transaction.

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 [#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, whether a system paymaster is available, the wallet's native token balance, and whether the connected chain reports zero gas. Those checks help an operator decide whether a transaction can use sponsored gas or needs native tokens on the smart account.

Sponsorship is not an omnibus-wallet model. DALP does not collapse participant assets or custody decisions into one shared operating wallet. Sponsorship can centralize network-fee payment for eligible UserOperations.

The smart account, participant identity, asset policy, custody approval, and transaction result remain separate parts of the workflow.

Use this rule of thumb:

| Situation                                                         | What to check next                                                                                                  |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Sponsorship is enabled and the system paymaster is funded         | Confirm the transaction is an eligible UserOperation through a DALP smart account.                                  |
| Sponsorship is disabled, unavailable, unfunded, or not applicable | Confirm the smart account has enough native token balance for execution.                                            |
| The chain reports zero gas                                        | Confirm the 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 [#what-sponsorship-does-not-replace]

Gas sponsorship is separate from compliance and custody controls. Asset eligibility, transfer policy, signer authority, custody provider approvals, transaction indexing, and webhook delivery still need their own checks.

## Related pages [#related-pages]

* [Account abstraction model](/docs/architects/concepts/account-abstraction) for the full execution model
* [UserOperations](/docs/architects/concepts/user-operations) for the request path paymasters can sponsor
* [System paymasters](/docs/developers/api-integration/system-paymasters) for the API surface
* [Account Abstraction Control Center](/docs/operators/platform-setup/account-abstraction-control-center) for operator controls