# Account abstraction

Source: https://docs.settlemint.com/docs/architecture/components/infrastructure/account-abstraction
Understand how DALP uses ERC-4337 smart accounts, EntryPoint routing, bundlers, paymasters, and validator modules for sponsored and threshold-controlled transactions.



DALP uses account abstraction to let a participant act through a smart account instead of sending every transaction directly from an externally owned account. The model combines ERC-4337 UserOperations, an EntryPoint contract, DALP smart accounts, validator modules, bundler processing, and optional paymaster sponsorship.

For operational API calls, see [Smart wallets](/docs/developer-guides/api-integration/smart-wallets), [Bundler JSON-RPC](/docs/developer-guides/api-integration/bundler), and [System paymasters](/docs/developer-guides/api-integration/system-paymasters).

## Core model [#core-model]

| Primitive        | What it does in DALP                                                                                                                                                                                                              |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Smart account    | On-chain account contract used as the transaction executor. DALP smart accounts are deployed through the account factory and validate UserOperations through installed validator modules.                                         |
| EntryPoint       | ERC-4337 contract that receives UserOperations and calls the smart account validation and execution path. DALP account factories and accounts are bound to the configured EntryPoint.                                             |
| Bundler          | Service that accepts UserOperations, simulates them, and submits valid operations to the EntryPoint. DALP exposes a bundler-compatible JSON-RPC discovery endpoint for chain ID and supported EntryPoint lookup.                  |
| Paymaster        | System add-on that can sponsor gas for eligible account abstraction transactions. DALP exposes paymaster funding, signer-key, and enablement operations through system paymaster APIs and the Account Abstraction Control Center. |
| Validator module | ERC-7579 validator installed on a smart account. DALP installs a default validator at account creation and supports validator-module management through the smart wallet API.                                                     |

Account abstraction changes who executes a transaction. It does not replace DALP identity, compliance, custody, or approval controls. A smart account still operates inside the platform's participant, role, policy, and system context.

## Transaction flow [#transaction-flow]

1. The caller chooses a participant and executor. When account abstraction routing selects a smart wallet, that wallet becomes the transaction executor.
2. DALP builds the transaction as a UserOperation for the smart account.
3. The validator module checks whether the operation is authorised. Single-signer and multisig configurations enforce different signing rules.
4. The bundler simulates and submits the UserOperation to the EntryPoint.
5. The EntryPoint calls the smart account validation path and then executes the requested call when validation succeeds.
6. If sponsorship is enabled and a paymaster applies, the paymaster handles the gas sponsorship path. Otherwise the smart account must have enough native token balance for execution.

Use [Transaction tracking](/docs/developer-guides/operations/transaction-tracking) after a mutation submits on-chain work. Account abstraction changes the execution path, but the integration still needs to poll or subscribe to the resulting transaction status.

## Smart accounts and identity [#smart-accounts-and-identity]

DALP smart accounts are wallets for participants. The account contract can store an ONCHAINID reference, but claim verification is driven by the identity registry and participant identity model rather than by treating the smart account as a standalone identity.

This split matters in regulated workflows:

* Participant identity and claims decide whether an actor satisfies transfer or asset-policy requirements.
* The smart account decides whether the requested transaction has enough signer or module authorisation.
* Role grants and API permissions still apply before DALP submits a transaction.

A smart account can therefore be the executor while the participant identity remains the compliance subject.

## Validators and multisig [#validators-and-multisig]

Every DALP smart account needs at least one validator module. DALP installs a default validator during account creation and prevents removal of the last validator so the account is not left unable to validate future operations.

For multisig wallets, the threshold is weighted. It is not a simple signer count. Read the signer list before changing the threshold and choose a value that the configured signer weights can actually satisfy. See [Smart wallets](/docs/developer-guides/api-integration/smart-wallets) for signer and threshold endpoints.

## Gas sponsorship [#gas-sponsorship]

Gas can come from two places:

| Gas mode                      | What must be true                                                                                         |
| ----------------------------- | --------------------------------------------------------------------------------------------------------- |
| Wallet-funded execution       | The smart account has enough native token balance for the operation.                                      |
| Paymaster-sponsored execution | A system paymaster is installed, funded through its EntryPoint deposit, and enabled for the organisation. |

The smart wallet gas-status endpoint reports the wallet balance, whether the chain is configured as a zero-gas chain, and whether a sponsorship paymaster is available for the effective system context. A wallet's own system is preferred for paymaster lookup; a supplied system address is only used when the wallet does not yet have a system assignment.

## Operational checks [#operational-checks]

Before relying on account abstraction in production, verify these surfaces:

| Check                              | Where to verify it                                                                                                                                                                                  |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Active EntryPoint                  | Call [Bundler JSON-RPC](/docs/developer-guides/api-integration/bundler) with `eth_supportedEntryPoints`.                                                                                            |
| Smart wallet signers and threshold | Use [Smart wallets](/docs/developer-guides/api-integration/smart-wallets).                                                                                                                          |
| Paymaster funding and enablement   | Use [System paymasters](/docs/developer-guides/api-integration/system-paymasters) or the [Account Abstraction Control Center](/docs/user-guides/platform-setup/account-abstraction-control-center). |
| Transaction completion             | Use [Transaction tracking](/docs/developer-guides/operations/transaction-tracking).                                                                                                                 |

## Related operations [#related-operations]

Smart wallet mutations, bundler JSON-RPC methods, and paymaster operations each have their own API reference page. Custody provider support, legal identity status, and chain-level privacy guarantees depend on separate platform configuration and are not defined by account abstraction alone.