# Account abstraction model Source: https://docs.settlemint.com/docs/architects/architecture/concepts/account-abstraction How DALP uses smart accounts, UserOperations, EntryPoint routing, bundlers, paymasters, and validators without replacing identity or compliance controls. Account abstraction lets a DALP participant execute transactions through a smart account instead of sending every transaction directly from an externally owned account. The smart account becomes the executor, while DALP keeps participant identity, asset policy, custody approval, and transaction outcome checks in their own layers. ## How the layers fit together [#how-the-layers-fit-together] Account abstraction has several layers. Each layer answers a different question in the transaction path. | Layer | Question it answers | DALP behaviour | | ---------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Participant | Who is acting in the platform? | DALP keeps the participant, organisation scope, roles, and identity model separate from the executor wallet. | | Smart account | Which on-chain account executes the call? | A smart account is an account contract deployed through the account factory and used as the transaction executor. | | UserOperation | What does the account abstraction transaction request contain? | DALP builds the operation that the smart account validates and the EntryPoint executes. | | Validator module | Who is allowed to approve this operation? | Installed validators enforce the smart account's signing rules. Multisig thresholds use signer weights, not a simple signer count. | | Bundler | Who submits valid operations to the chain? | The bundler accepts and simulates UserOperations, then submits valid operations to the configured EntryPoint. | | EntryPoint | Which contract coordinates validation and execution? | The EntryPoint receives UserOperations, calls the smart account validation path, and executes the requested call when validation succeeds. | | Paymaster | Who can sponsor gas? | A funded and enabled system paymaster can sponsor eligible account abstraction transactions. Otherwise the smart account needs enough native token balance. | ## What to verify before using it [#what-to-verify-before-using-it] Before you choose the smart account route for an operation, verify four things: 1. The selected chain supports the EntryPoint used by the bundler. 2. The smart account has the validator and signer threshold your operating model requires. 3. The paymaster is funded and enabled when the transaction should be sponsored. 4. The integration reads the final transaction outcome from tracking, indexed state, or webhooks after submission. These checks keep the execution model separate from the business decision. Account abstraction can change who submits and pays for an operation, but it does not make an otherwise unauthorised mint, transfer, or policy change valid. ## Example: sponsored multisig operation [#example-sponsored-multisig-operation] A sponsored multisig operation shows why these layers stay separate. Suppose a participant submits an asset operation from a smart wallet that requires a signer threshold and uses a system paymaster. The example uses the same public surfaces documented in [Smart wallets](/docs/developers/developer-guides/api-integration/smart-wallets), [System paymasters](/docs/developers/developer-guides/api-integration/system-paymasters), [Bundler JSON-RPC](/docs/developers/developer-guides/api-integration/bundler), and [Transaction tracking](/docs/developers/developer-guides/operations/transaction-tracking). | Step | What DALP checks | Result | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | 1. Resolve the smart wallet route | The selected wallet is a smart wallet, and the chain has an EntryPoint and bundler route. | DALP prepares a UserOperation instead of a direct externally owned account transaction. | | 2. Check signer authority | The initiating address must be a registered signer with enough weight for the wallet policy. | A non-signer is rejected before DALP previews or signs the UserOperation. | | 3. Resolve sponsorship | If paymaster sponsorship is enabled, the operation needs an eligible system paymaster and sponsorship data. | If no paymaster can sponsor the operation, DALP rejects the sponsored route rather than submitting an unfunded UserOperation. | | 4. Collect multisig approval | DALP previews the UserOperation, reserves the nonce, and returns a pending approval for the required co-signers. | The operation waits for smart-wallet approval before submission. | | 5. Read completion state | After approval and submission, the integration reads the outcome from transaction tracking, indexed state, or webhooks. | The smart account path still ends in the same outcome checks as other DALP operations. | In this example, sponsorship only changes gas funding. Multisig approval only changes who can approve the smart-account operation. Asset permissions, compliance modules, custody rules, and final transaction status still decide whether the asset operation completes. ## What account abstraction does not replace [#what-account-abstraction-does-not-replace] Account abstraction is an execution model, not a compliance or custody shortcut. | Control | Relationship to account abstraction | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity and claims | The participant identity remains the compliance subject. A smart account can execute a transaction without becoming the participant identity model. | | Asset policy | Transfer, mint, and eligibility rules still come from the configured asset contracts and compliance modules. | | Platform roles and API access | DALP still checks organisation scope, API permissions, and role requirements before submitting platform-managed work. | | Custody policy | Custody provider and HSM approval rules stay separate from the smart account validator model unless the deployment connects them deliberately. | | Transaction status | Integrations still need transaction tracking, indexed state, or subscribed webhooks after submission. | ## Production checks [#production-checks] Before relying on account abstraction in a regulated workflow, verify the operational surfaces that control execution. * Supported EntryPoint: call the [Bundler JSON-RPC reference](/docs/developers/developer-guides/api-integration/bundler) with `eth_supportedEntryPoints`. * Smart wallet signers and threshold: use the [Smart wallets API guide](/docs/developers/developer-guides/api-integration/smart-wallets). * Paymaster funding: use [System paymasters](/docs/developers/developer-guides/api-integration/system-paymasters) for API checks. * Paymaster setup: use the [operator setup guide](/docs/operators/user-guides/platform-setup/account-abstraction-control-center) for account abstraction settings. * Transaction completion: use [Transaction tracking](/docs/developers/developer-guides/operations/transaction-tracking) after the operation is submitted. ## Related pages [#related-pages] * [UserOperations](/docs/architects/architecture/concepts/user-operations) for the smart-account request model. * [Bundlers](/docs/architects/architecture/concepts/bundlers) for the submission layer. * [Paymasters and gas sponsorship](/docs/architects/architecture/concepts/paymasters-and-gas-sponsorship) for sponsored gas checks. * [Account abstraction architecture](/docs/architects/architecture/components/infrastructure/account-abstraction) for the infrastructure component view. * [Smart wallets](/docs/developers/developer-guides/api-integration/smart-wallets) for signer, threshold, validator, and wallet endpoints. * [Bundler JSON-RPC](/docs/developers/developer-guides/api-integration/bundler) for supported EntryPoint discovery behaviour. * [Signing flow](/docs/architects/architecture/flows/signing-flow) for custody and approval sequencing.