# Operators act, the platform sponsors gas

Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/account-abstraction
Smart wallets and sponsored gas are now part of the core operating model. Operators take actions without holding native tokens, under role boundaries you define.



**Operators act and the platform handles gas. Smart wallets are now part of the core operating model, with sponsored transactions running under the role boundaries you already define.**

<Video src="/media/dalp-3-0/account-abstraction.mp4" title="Smart wallets and sponsored gas: DALP 3.0" description="Operators act without holding native tokens; the platform sponsors gas under role boundaries you define." />

<Spotlight
  eyebrow="Account Abstraction"
  title="Act on the chain, without managing it"
  aside="<FactList items={[
  { label: &#x22;Built on&#x22;, value: &#x22;ERC-4337&#x22; },
  { label: &#x22;Operator gas&#x22;, value: &#x22;Sponsored by the platform&#x22; },
  { label: &#x22;Native token held&#x22;, value: &#x22;None&#x22; },
  { label: &#x22;Identity&#x22;, value: &#x22;EOA and smart wallet, as one&#x22; },
]} />"
>
  Until now, every on-chain operation required the submitting party to hold and spend a native token. That made gas a custody problem layered on top of an operations problem. In DALP 3.0, the platform sponsors gas under boundaries you set, resolves smart wallets and signing keys to one identity, and lets operators focus on the work, not the plumbing.
</Spotlight>

On most chains, every account that can transact is an externally owned account: one private key paired with one required balance of the chain's native token. Fund the key or the transaction fails. That makes daily operations a quiet infrastructure tax. Someone has to custody each key, keep each balance above zero, and notice when it falls short. Across multiple operators and multiple networks, that tax is a significant operational surface with no compliance benefit.

The problem runs deeper than cost. When an operator submits a transaction from a hot key, the compliance system sees the key's address, not the operator's identity. Transfer restrictions, allow-list lookups, and audit trails all anchor on the submitting address. The key and the identity are separate things that your compliance system has to stitch together after the fact, every time.

Account abstraction separates submission from authorization. An operator packages their intent as a UserOperation rather than a raw transaction. A programmable wallet executes the intent. A paymaster covers the gas. Rules run before the operation reaches the chain. The result is an operating model where your operators submit work and the platform handles the mechanics.

## How it works [#how-it-works]

<Pipeline
  caption="From operator action to settled transaction. Gas is handled by the platform at every step."
  stages="[
  { title: &#x22;Intent&#x22;, detail: &#x22;The operator takes an action through the Console or Platform API. No native token balance required on their account.&#x22; },
  { title: &#x22;Validate&#x22;, detail: &#x22;The system paymaster checks a signed sponsorship authorization (operator role, transaction type, gas ceiling, and expiry) before coverage is granted.&#x22; },
  { title: &#x22;Sponsor&#x22;, detail: &#x22;The platform pays the gas. The transaction is submitted through the bundler; the operator's smart wallet executes it.&#x22; },
  { title: &#x22;Resolve&#x22;, detail: &#x22;The smart wallet and its associated signing key are resolved to one identity before any compliance check or registry operation fires.&#x22; },
  { title: &#x22;Settle&#x22;, detail: &#x22;The action lands on-chain. Compliance controls apply to the right account, regardless of which address signed.&#x22; },
]"
/>

The complexity concentrates in two places that matter most to a regulated operation: the moment before work reaches the chain, and the moment a compliance check asks which identity acted. Sponsorship is earned by passing explicit rule checks, not granted automatically, so the system paymaster is a control point, not just a convenience. Because the smart wallet and its signing key resolve to one identity before anything downstream fires, the operation lands in the audit trail attributed to the right party, not the key that happened to submit it.

## Why it matters [#why-it-matters]

<BeforeAfter
  before="{
  title: &#x22;Gas as an operations problem&#x22;,
  points: [
    &#x22;Each operator holds a key and must keep it funded with the chain's native token.&#x22;,
    &#x22;A depleted balance silently blocks every action until someone tops it up.&#x22;,
    &#x22;Multiple operators across multiple networks multiply the custody and monitoring surface.&#x22;,
    &#x22;Compliance controls must treat the signing key as a separate identity from the operator.&#x22;,
  ],
}"
  after="{
  title: &#x22;With account abstraction&#x22;,
  points: [
    &#x22;Operators act through smart wallets with no native token balance required.&#x22;,
    &#x22;The platform sponsors gas under the role boundaries you define.&#x22;,
    &#x22;Low-balance alerts surface before a shortfall stops work; setup is idempotent and recovers cleanly.&#x22;,
    &#x22;Smart wallet and signing key resolve to one identity before any compliance check fires.&#x22;,
  ],
}"
/>

The compliance dimension is what separates account abstraction from a developer convenience. On most chains, every transfer restriction and registry lookup operates on the address that submitted the transaction. When that address is a hot key held by an operator rather than the identity the compliance system tracks, every check has to bridge the indirection or miss it. Resolving the smart wallet and signing key to a single identity before any check or registry operation fires closes that gap at the platform level. The controls you configure apply to the right address regardless of how the instruction reached the chain.

## Built on ERC-4337 [#built-on-erc-4337]

Account abstraction in DALP is built on ERC-4337, the Ethereum standard that adds programmable transaction handling without modifying the chain's core protocol. Understanding the standard makes it easier to reason about what the platform guarantees and where those guarantees are grounded on-chain.

<Callout title="No migration required">
  Existing externally owned accounts and their permissions continue to work. Account abstraction is additive: opt operators into smart wallets and paymaster sponsorship incrementally.
</Callout>

ERC-4337 introduces a new object called a UserOperation: a signed intent rather than a raw transaction. Instead of broadcasting directly to the network, a wallet packages its intent as a UserOperation and sends it to a separate peer-to-peer layer, the alternative mempool. Specialized nodes called bundlers collect UserOperations, verify them, and submit them to the EntryPoint on-chain as a single batched `handleOps` call. The EntryPoint is the shared, audited contract at the center of the ERC-4337 system. It validates each UserOperation, coordinates with the paymaster, and dispatches execution to the operator's wallet.

### Smart wallets [#smart-wallets]

These programmable wallets, also called smart accounts, execute within this flow. Unlike an externally owned account, which is nothing more than a private key, a deployed contract can encode logic: weighted multisig policies, role-scoped session keys, spending limits, and recovery mechanisms.

Our implementation follows ERC-7579, the modular account standard. Validation rules attach as composable modules: swap out a validator without replacing the wallet itself. Each operator gets a lightweight proxy pointing at a shared implementation. When we ship an improvement, we update the shared implementation and every proxy inherits it at once. No per-operator migration. The platform also supports weighted multisig validation: assign different signing weights to different keys, set a threshold, and the wallet enforces it before any operation proceeds.

### System paymaster [#system-paymaster]

Sponsored gas is the part of ERC-4337 that matters most to operations, and it is worth understanding precisely because the platform's control sits here.

A separate sponsoring contract agrees to pay the gas for a given UserOperation. To do so, it pre-deposits a balance of the chain's native token with the EntryPoint. That reserve is the pool the gas is drawn from. When a UserOperation names a paymaster, the EntryPoint calls its validation function before executing anything and asks whether it will cover this specific request. The sponsor runs its checks and answers yes or no. A rejection costs nothing and stops the operation before it touches the chain. An approval causes the EntryPoint to execute the work, then deducts the exact gas spent from the deposit and reconciles the cost in a final accounting step. The operator who triggered the transaction never holds or spends a native token at any point.

That validation call is the whole mechanism. Anything the contract can inspect, it can make gas coverage conditional on. Our system paymaster uses this window as a policy engine backed by signed authorizations. Before the EntryPoint commits a single unit of gas, it verifies a cryptographically signed sponsorship authorization (EIP-712 format) that encodes the operator's role, the permitted calldata, the organization scope, a hard gas ceiling, and an expiry deadline. The authorization is signed off-chain by a trusted platform signer, then presented with the UserOperation. If any field mismatches or the deadline has passed, the operation is rejected at no cost. Access is earned by passing every check, never granted by default. An unauthorized or out-of-policy request is rejected before it costs anything, rather than being paid for and unwound after the fact.

The sponsoring contract's deposit is live operational infrastructure. We monitor it and raise a low-balance alert before it can stall an operator, so gas sponsorship stays funded without a manual top-up routine.

### Network coverage [#network-coverage]

On public EVM networks, we connect to the canonical ERC-4337 EntryPoint already deployed by the community. On private or permissioned networks where no canonical instance exists, we deploy one locally. The same wallet behavior and paymaster sponsorship are available regardless of whether the chain is a public L1, an L2, or a permissioned network. We operate the bundler path between the alternative mempool and the EntryPoint, so the UserOperation flow is a platform capability rather than infrastructure you manage. The full ERC-4337 execution path, from UserOperation through bundler, EntryPoint, paymaster, and programmable wallet, runs entirely under platform control with the same open standard underneath it on every supported network.

## Availability [#availability]

Programmable wallets, system paymasters, and account abstraction are generally available in DALP 3.0 on all supported EVM networks.

[Understand account abstraction →](/docs/architecture/concepts/account-abstraction) · [System paymaster reference →](/docs/api-reference/wallets/system-paymasters) · [Smart wallets →](/docs/api-reference/wallets/smart-wallets)