Account abstraction design

The central thesis

Every on-chain write in DALP passes through one transaction queue before it reaches the chain, and that queue decides whether the transaction executes from an externally owned account (EOA) or from a smart wallet. That single decision point is what keeps the system consistent across retries, parallel requests, organisation setup, and post-setup flows.

Four structural decisions follow from it:

1. The transaction queue resolves the executor, and callers only forward the result.
2. Organisation setup stays on the EOA path until the account abstraction infrastructure exists.
3. Smart wallets can be provisioned explicitly (via the smart wallet API) or on-demand when an invitation flow needs to deploy the wallet as part of identity creation. Both paths deploy the account on-chain; the on-demand path piggybacks the deployment on the first UserOperation.
4. The key that authorises an action and the account that executes it are allowed to differ.

Why a single decision point, not distributed checks

DALP resolves a single execution route for each operation inside the transaction queue, either an EOA or a smart wallet. Route handlers and durable workflows receive that resolved executor and pass it through. They do not re-evaluate the decision and do not add their own routing branches such as "use the EOA during onboarding."

The queue makes the choice from two inputs: the organisation's account abstraction setting, and an optional executor override on the request (the X-Executor header) that can force a specific route. The full route-resolution, signing, and nonce model is described in Transaction signer. This page covers why the decision is centralised and the invariants that depend on it.

Centralising the decision matters for correctness in a durable execution model. When a queued step is retried, the retry has to produce the same on-chain sender as the first attempt. If two code paths could resolve the executor independently, a setting change between the original attempt and the retry would change the sender and turn an idempotent retry into a conflicting transaction. With one decision point, the route is fixed once and replayed consistently.

It also matters for auditability. Reconstructing what executed, and from which account, means reading one resolved route rather than re-deriving a decision spread across callers.

Why organisation setup stays on the EOA path

A newly created organisation has no smart wallet yet. The bundler configuration, paymaster authorisation, role assignments, identity metadata, and indexer state are all being created by the deployment process. None of that infrastructure can be used to route the very transactions that create it.

The deployment process keeps account abstraction switched off during bootstrap and turns it on only as its final step, once all the supporting infrastructure is confirmed on-chain and indexed.

Resist the temptation to paper over an early failure by adding a route-local "fall back to the EOA during onboarding" branch. If a write belongs to the deployment sequence it should run before account abstraction is switched on. If it runs after, the organisation's infrastructure is already live and the write is eligible for the normal smart wallet path. There is no legitimate middle case.

Smart wallet deployment paths

A smart wallet can be deployed through the explicit provisioning API or through the invitation flow. The explicit path calls the smart wallet API directly, which runs a full provisioning workflow — deploying the account on-chain, adding a management key on the participant identity, and registering the wallet in the identity registry — before returning. The wallet is deployed and registered as part of that synchronous call.

The invitation flow works differently because the participant has no on-chain identity yet when the invitation is processed.

On-demand deployment for invited participants

When an account-abstraction organisation invites a new participant, that participant has no on-chain identity yet, so there is no deployed smart wallet to look up.

The invitation flow uses counterfactual addressing. Before any transaction is submitted, it predicts the smart wallet address from the account factory's deterministic deployment formula and records that predicted address together with the operation it belongs to, for example creating the participant's on-chain identity. When the queue processes the operation, it derives the expected identity address from the operation's target and calldata, checks that it matches the recorded prediction, and, if the predicted smart wallet has no code yet, attaches the account-factory initialisation data so the wallet is deployed as part of the same UserOperation.

The identity-creating UserOperation is therefore also the deployment UserOperation. The participant's smart wallet comes into existence in the same operation that creates their on-chain identity.

The invariant that matters is that callers never supply a trusted identity address. The identity address is derived inside the verified transaction workflow from the calldata and the operation target. That derivation is what the system trusts, not any address passed in from outside.

Signing and execution as separate concerns

For claim issuance, the issuer's own key signs the off-chain claim payload, and that signature is the proof that the issuer authorised the claim. The transaction that anchors the claim on-chain still routes through the queue and may execute from the smart wallet.

These are different questions answered by different keys. "Who authorised this claim" is a cryptographic attestation tied to the issuer. "Who submits the transaction" is an execution choice governed by the organisation's account abstraction setting and the queue's resolved route.

Keeping them separate means claim issuance does not require the issuer to also be the account that pays for and submits the transaction. It also means the execution path can change, for example when bundler configuration is updated, without invalidating previously issued claim signatures.

Account modularity and its limits

The smart account follows ERC-7579, so validation logic lives in interchangeable modules rather than in the account contract itself.

The account supports up to 16 validator modules and refuses to remove its last validator. That guard prevents a class of misconfiguration where an account is left with no key able to authorise operations, which would lock it permanently.

Because validation is modular, new validator types such as session keys, additional multisig schemes, or hardware attestation can be added without replacing the account contract.

Related pages

• Transaction signer for how the queue resolves routes, signs, and serialises nonces across every execution path.
• Account abstraction for why DALP adopts account abstraction and where the boundary sits.
• UserOperations for how a UserOperation is built and moved from queue to chain.
• Paymasters and gas sponsorship for how sponsored gas is checked and funded.
• Nonce lanes and ordering for ordering across concurrent UserOperations.