# Account abstraction architecture

Source: https://docs.settlemint.com/docs/architects/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 account abstraction lets a participant execute platform-managed work through a smart account instead of sending every transaction directly from an externally owned account.

**Requires:** account abstraction enabled for the deployment. When it is disabled, use the direct externally owned account route instead of the smart account route.

The route combines DALP smart accounts, ERC-4337 UserOperations, the EntryPoint, validator modules, bundlers, and optional paymaster sponsorship. Use the [account abstraction model](/docs/architecture/concepts/account-abstraction) for the concept view. Use [Smart wallets](/docs/api-reference/wallets/smart-wallets), [Bundler JSON-RPC](/docs/api-reference/wallets/bundler), and [System paymasters](/docs/api-reference/wallets/system-paymasters) when you need operational API calls.

Identity, claim topics, and trusted issuers stay in the [claims and identity model](/docs/architecture/concepts/claims-and-identity).

<Mermaid
  chart="flowchart TD
    Caller[Participant or integration] --> DALP[DALP API, roles, and policy checks]
    DALP --> Wallet[Smart account route]
    Wallet --> UO[UserOperation]
    UO --> Validator[Validator module]
    Validator --> Bundler[Bundler simulation and submission]
    Bundler --> EntryPoint[EntryPoint]
    EntryPoint --> Call[On-chain asset or platform call]
    Paymaster[System paymaster] -. sponsors eligible gas .-> UO
    Call --> Outcome[Transaction tracking, indexed state, and webhooks]"
/>

## 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 EntryPoint (version 0.9) 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 advanced accounts 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/developers/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/api-reference/wallets/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/api-reference/wallets/bundler) with `eth_supportedEntryPoints`.                                                                                      |
| Smart wallet signers and threshold | Use [Smart wallets](/docs/api-reference/wallets/smart-wallets).                                                                                                                    |
| Paymaster funding and enablement   | Use [System paymasters](/docs/api-reference/wallets/system-paymasters) or the [advanced accounts control center](/docs/operators/platform-setup/advanced-accounts-control-center). |
| Transaction completion             | Use [Transaction tracking](/docs/developers/operations/transaction-tracking).                                                                                                      |
| Recovery evidence                  | Use [Failure modes](/docs/architects/operability/failure-modes) and transaction records to review retries, blocked work, and operator recovery after dependency failures.          |

## Bundler recovery boundary [#bundler-recovery-boundary]

A smart account lane is processed through an exclusive bundler queue. If the lane head becomes unsafe to continue, DALP bounds retry attempts, releases the queue when retry exhaustion is reached, and uses a watchdog sweep to move a recoverable stuck head to a failed terminal state so later queued work can continue.

This recovery path protects the DALP queue. It does not prove that the original business operation succeeded.

Treat the failed UserOperation as an operational event. Review transaction tracking, logs, alerts, and the affected workflow state before resubmitting or approving a replacement operation.

Validate the recovery decision in this order:

1. Confirm the transaction request reached a terminal state in [Transaction tracking](/docs/developers/operations/transaction-tracking). If it is still active, keep polling instead of sending a replacement operation.
2. Check the active EntryPoint, smart wallet signer threshold, gas mode, and paymaster funding against the operational checks above.
3. Match the failure to the recovery model in [Failure modes](/docs/architects/operability/failure-modes): retry, fail closed, fail over, or manual recovery.
4. Compare the transaction record, receipt, logs, alerts, workflow state, and runbook notes before deciding whether to resubmit, cancel, or investigate the dependency.

| Situation                                    | DALP behaviour                                                                                        | Operator action                                                                                           |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Bundler simulation or submission fails       | The UserOperation fails or retries according to the bundler queue policy.                             | Check the wallet gas mode, paymaster funding, EntryPoint support, and transaction status before retrying. |
| A lane head becomes stuck                    | The watchdog can quarantine the stuck head, reconcile the reserved nonce, and let the lane move.      | Review the failed operation and decide whether to resubmit, cancel, or investigate the dependency.        |
| RPC, paymaster, or external dependency fails | Account abstraction cannot make the dependency healthy; affected work waits, fails, or blocks safely. | Restore the dependency and compare recovery evidence against the deployment runbook.                      |

## Related operations [#related-operations]

Smart wallet mutations, bundler JSON-RPC methods, paymaster operations, transaction tracking, and failure-mode guidance each have their own 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.