A Paymaster can change how an eligible smart-account operation is funded from the customer’s point of view. It does not remove network gas: execution still settles technical gas on the network, and a sponsor or customer-fee arrangement must provide the corresponding funding under an agreed policy.
Design the flow by separating three decisions: which operations qualify, who bears the economic cost, and how the network’s gas settlement is funded and reconciled. Eligibility depends on the configured network and supported settlement asset. Neither universal sponsorship nor an automatic transaction subsidy is implied.
Separate gas from the customer fee
Technical gas is the network’s execution cost, settled according to the network and account-abstraction configuration. A customer-facing fee is a separate policy decision: an institution may sponsor an eligible operation or may charge an approved fee under the configured model. A zero-fee customer experience therefore means that another party bears the cost, not that execution is free.
Track protocol gas, customer-facing charges, any sponsor budget, implementation or managed-service charges, and network reserves as separate items. This makes responsibility and reconciliation clearer for finance and operations teams. The precise customer disclosure, accounting treatment, and institutional policy are determined by the bank and are not established by the Paymaster mechanism itself.
Customer experience and gas settlement follow related lanes
- Customer laneRequests an operation under the institution’s documented experience.
- Policy laneChecks eligibility, settlement asset, approvals, and configured limits.
- Sponsor laneFunds permitted operations when sponsorship policy applies.
- Network laneExecutes the operation and settles technical gas.
- Reconciliation laneRecords customer fees and sponsor funding separately.
Define sponsorship eligibility
The institution should identify which smart-account operations may qualify, which accounts or applications are in scope, what policy conditions apply, and how exceptions are reviewed. Eligibility is not universal. It depends on the configured settlement asset, network behavior, and agreed Paymaster policy, so an application request alone cannot make an unsupported operation eligible.
The ERC-4337 Paymaster architecture has funding and operational requirements, including the applicable native EntryPoint deposit and stake. The responsible party must define funding ownership, permitted use, monitoring, and replenishment. These resources are not supplied automatically by the platform, do not come from network reserves by implication, and do not establish a fixed allowance for every customer.
Assess settlement assets and limits
An eligible operation may use an approved settlement token for customer-facing fee collection where the configured policy supports it. Token compatibility requires technical assessment of registration, conversion, settlement, and authorization behavior. Naming an arbitrary stablecoin in an application request does not make it compatible, and no particular asset or fee conversion rate is promised by this guide.
Set explicit limits and exception handling for the selected policy, then assign monitoring and approval roles. Consider what happens when sponsor funding is insufficient, a requested asset is ineligible, a charge cannot be reconciled, or an application changes its request. Test these outcomes in an agreed environment and document which system is authoritative for each part of the customer and network record.
An eligible operation passes policy before gas is settled
- Operation requestA smart account submits an operation for evaluation.
- Eligibility checkConfigured asset, policy, and limit conditions are assessed.
- Funding decisionThe agreed sponsor or customer fee path is selected.
- Gas settlementNetwork execution settles the required technical gas.
- Reconcile recordsCustomer charges and sponsor expenditure are recorded distinctly.
Operate and reconcile the policy
Operations teams need to monitor native gas funding independently from customer fee collection and the institution’s asset reserves. Define who reviews eligibility changes, who replenishes the applicable deposit or stake, how service interruptions are escalated, and which records support reconciliation. The agreed operating scope should state what the institution manages and what services are provided by others.
Before production, exercise successful, rejected, ineligible, and underfunded paths using approved test data. Reconcile the smart-account result, network record, sponsor funding movement, and any customer-facing charge. Validate limits and approvals as configured, then review the evidence with product, finance, engineering, and operations stakeholders before committing to a customer experience.