Account abstraction
What account abstraction is in plain terms, how DALP chooses the smart account or EOA route, and why execution stays separate from identity and policy.
Account abstraction lets a managed smart account submit transactions for a participant. A smart account is a contract account that DALP operates on the participant's behalf, in contrast to an externally owned account (EOA), which is a plain wallet controlled by a single private key. When DALP uses paymaster sponsorship, gas can be paid by the platform instead of from the participant's own wallet.
In DALP, account abstraction is an execution route. It changes how a transaction reaches the chain and who pays for the gas. It does not change who the participant is, which asset rules apply, or whether an operation is allowed.
That distinction matters when you read DALP's signing, paymaster, and transaction-queue docs. For the component view, see the account abstraction component under Infrastructure.
Key terms on this page. First mention links to the architecture glossary: smart account, UserOperation, EntryPoint, bundler, paymaster, validator module, and EOA.
Why it exists
Two institutional barriers motivate account abstraction. A plain externally owned account model cannot address either one cleanly.
New participants cannot transact without funded gas
An externally owned account needs native token balance before it can submit a single transaction. For institutional onboarding this is a coordination problem: a new participant cannot act on-chain until someone funds their wallet, yet proving eligibility, creating identity, and completing first-touch operations are themselves on-chain steps.
A system paymaster solves this directly. A paymaster is a contract that pays gas on a participant's behalf. DALP runs one per chain, so a participant's smart account can execute its first transactions without holding native token. Gas is paid centrally by the operator, not by the participant. This is gasless onboarding.
Governed accounts need more than one approver
Treasury accounts and regulated organisations often require several authorised people to approve a transaction. A single private key, which is all an externally owned account provides, cannot express that rule.
DALP addresses this with a weighted multisig validator, a pluggable rule installed on the smart account that requires a signing threshold before the account accepts an operation. Each signer carries a weight, and the operation proceeds only when the collected signatures meet the configured threshold. Weighting matters when one approver should count for more than another, which a simple signer count cannot represent.
How DALP chooses the execution route
DALP chooses the execution route in the transaction queue before it builds the on-chain operation. The default route uses the participant's smart account only when account abstraction is enabled for the platform and for the organisation. If either setting is off, DALP uses the participant's externally owned account route.
An API request can ask for a specific route with the X-Executor header. X-Executor: smart-wallet uses the smart account route only when account abstraction is enabled for the platform and for the organisation. For person participants, DALP can use an existing smart account or provision one when the account factory and signing wallet are available. If the smart account route cannot be resolved, DALP rejects the override rather than silently falling back to another executor. X-Executor: eoa uses the EOA route for person participants, even when account abstraction is otherwise available. Organisation participants cannot use the EOA override; their route follows the default or smart account path for the current platform and organisation settings.
This selection is part of routing, not authorisation. The selected route supplies the effective executor address for the queued transaction, then the normal platform, identity, policy, custody, and on-chain checks still decide whether the operation can proceed.
What account abstraction does not decide
Account abstraction governs which account submits a transaction and how gas is paid. It governs none of the following.
| Control | How it relates to account abstraction |
|---|---|
| Participant identity | The participant and their claims remain the compliance subject, regardless of which wallet executes the transaction. |
| Asset policy | Transfer rules, eligibility checks, and mint limits apply to the operation itself, not to the execution route. |
| Custody approval | Hardware security module and custody provider approvals stay separate from the smart account's signing rules. |
| Platform roles | Organisation scope and API permissions are checked at the platform layer before any transaction is built. |
| Transaction outcome | Indexed state, webhooks, and completion tracking apply after on-chain execution, regardless of the execution route. |
This separation is intentional. A sponsored transaction does not expand what a participant is permitted to do, and a multisig approval does not substitute for a custody policy. Keeping execution separate from policy is what lets a deployment adopt gasless onboarding or threshold approval without redesigning its compliance model.
How operators see it
Operators do not work with the protocol machinery directly. These capabilities appear in the platform as a feature called advanced accounts, with gasless transactions (paymaster sponsorship) and multi-approver accounts (the weighted multisig validator). Operators configure enablement and funding from the advanced accounts control center. The platform handles transaction routing, submission, and gas accounting underneath.
Built on ERC-4337 and ERC-7579
DALP uses two Ethereum standards. ERC-4337 is the account abstraction substrate: it defines the transaction-request format (the UserOperation), the contract that validates and runs those requests (the EntryPoint), the service that submits them (the bundler), and the paymaster interface. ERC-7579 adds the module system that lets one smart account install different validation rules, such as a single-owner key or the weighted multisig.
Using published standards means the smart account, bundler, and paymaster interact through documented interfaces rather than a proprietary path. The mechanics of each part live under Infrastructure.
How DALP keeps a smart account lane recoverable
A smart account has ordered nonce lanes. DALP keeps dependent operations in order by selecting only the head UserOperation from each sender and nonce key, then choosing between independent lanes by priority fee. A later operation in the same lane waits behind the current head instead of overtaking it.
That ordering is useful only if the head can be recovered. DALP uses four recovery boundaries for account abstraction execution:
| Recovery boundary | What DALP does | What it protects |
|---|---|---|
| Bounded handler retry | Account abstraction queue and mempool handlers use a bounded retry policy and release their exclusive lock instead of holding a stuck lane forever. | A transient infrastructure wedge should not freeze every later operation for the same smart account. |
| Head-of-lane recovery | A recovery monitor detects a wedged queue head, quarantines that invocation, fails the affected head, and lets the next operation in the lane continue. | Operators get a terminal failure to investigate instead of an invisible stalled queue. |
| Nonce reconciliation | DALP confirms the nonce when the operation reached the chain, and releases it when the operation was dropped, expired, or never submitted. | Follow-up operations do not reuse a consumed nonce or get stranded behind a nonce that never landed. |
| Transaction tracking evidence | The queue status, transaction hash, block number, and error message remain the operator's evidence path for the operation outcome. | Integrations can check the status before retrying or submitting a replacement operation. |
For retry decisions, use the platform transaction status first. If the status is still in progress, keep polling. If it is terminal, use the recorded error, transaction hash, and receipt evidence to decide whether to fix inputs, fund infrastructure, or submit a new operation. See transaction tracking for the developer workflow.
When you review a smart account recovery incident, read this section with the bundler, UserOperation, and nonce lane pages.
Use workflow engine recovery only after the transaction status or operator health checks show a stuck workflow that needs an operator action.
Where to go next
This page is the why. For how it works, read these under Components > Infrastructure.
| Read next | For |
|---|---|
| Account abstraction component | The architecture overview of how the layers connect. |
| Account abstraction design | The central executor gate and the invariants that keep routing correct. |
| Account abstraction security | How sponsorship, signing keys, and account controls bound the execution layer. |
| UserOperations | The request a smart account validates and the EntryPoint runs. |
| Bundlers | The submission layer. |
| Paymasters and gas sponsorship | How sponsored gas is checked, funded, and bounded. |
| Nonce lanes and ordering | How independent operations run in parallel while dependent ones stay ordered. |
Asset policy
Understand how DALP combines identity records, compliance modules, lifecycle hooks, and governance controls to decide whether regulated token operations can execute.
Claims and identity
Understand how participants, wallet registration, OnchainID claims, trusted issuers, claim topics, and token compliance expressions work together in DALP.