Account abstraction

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, Bundler JSON-RPC, and System paymasters.

Core model

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

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 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

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

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 for signer and threshold endpoints.

Gas sponsorship

Gas can come from two places:

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

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

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.