# Advanced accounts architecture

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



DALP advanced accounts lets a participant execute platform-managed work through a smart account instead of sending every transaction directly from an externally owned account.

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

This path combines DALP smart accounts, ERC-4337 UserOperations, the EntryPoint, validator modules, bundlers, and optional paymaster sponsorship. Use the [advanced accounts concept](/docs/architecture/concepts/account-abstraction) for the concept view. For operational API calls, see [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).

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 sponsors gas for eligible advanced accounts transactions. DALP exposes funding, signer-key rotation, and enablement controls through the 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. You choose a participant and executor. When advanced accounts 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 you still need 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, not a simple signer count. Read the signer list before you change 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 you rely on advanced accounts 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]

Each smart account lane runs through an exclusive bundler queue. When the lane head becomes unsafe to continue, DALP bounds retry attempts and releases the queue on retry exhaustion. A watchdog sweep then moves any 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 you resubmit or approve 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 you decide whether to resubmit, cancel, or investigate the dependency.

| Situation                                    | DALP behaviour                                                                                        | What to do                                                                                                |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| 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.