# Advanced accounts design

Source: https://docs.settlemint.com/docs/architects/components/infrastructure/advanced-accounts/advanced-accounts-design
How DALP's account abstraction layer is structured, why the transaction queue owns the EOA-vs-smart-wallet decision, and the invariants that keep the system consistent across setup, invitations, and ordinary transaction flow.



## The central thesis [#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 advanced accounts 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 operation and the account that executes it may differ.

## Why a single decision point, not distributed checks [#why-a-single-decision-point-not-distributed-checks]

DALP resolves a single execution path 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 routing choice and do not add their own branches such as "use the EOA during onboarding."

The queue reads two inputs: the organisation's advanced accounts setting and an optional executor override on the request (the `X-Executor` header). See [Transaction signer](/docs/architects/components/infrastructure/transaction-signer) for the full route-resolution, signing, and nonce model. This page explains why the choice is centralised and what invariants it upholds.

Centralising the choice matters for correctness in a durable execution model. When a queued step runs again, the platform must produce the same on-chain sender as the first attempt. If two code paths resolved the executor independently, a setting change between the original attempt and the replay would change the sender and turn an idempotent retry into a conflicting transaction. With one decision point, the route is locked once and replayed consistently.

The single point also simplifies auditing. When you reconstruct what executed and from which account, you read one resolved route rather than re-derive a choice spread across callers.

## Why organisation setup stays on the EOA path [#why-organisation-setup-stays-on-the-eoa-path]

A newly created organisation has no smart wallet yet. The setup process creates bundler configuration, paymaster authorisation, role assignments, identity metadata, and indexer state. None of that infrastructure is available to route the very transactions that create it.

The setup process keeps advanced accounts disabled during bootstrap and enables it only as its final step, after all supporting infrastructure is confirmed on-chain and indexed.

Do not paper over an early failure by adding a route-local "fall back to the EOA during onboarding" branch. If a write belongs to the setup sequence, it must run before advanced accounts is enabled. If you run it after, the organisation's infrastructure is already live and the write is eligible for the normal smart wallet path. No legitimate middle case exists.

<Mermaid
  chart="sequenceDiagram
    participant DW as Deployment process
    participant Queue as Transaction queue
    participant Chain

    DW->>Queue: deploy smart wallet (AA off, routes EOA)
    Queue->>Chain: submit from EOA
    DW->>Queue: configure bundler and paymaster (EOA)
    Queue->>Chain: submit from EOA
    DW->>Queue: assign roles, create identity (EOA)
    Queue->>Chain: submit from EOA
    DW->>DW: all infrastructure confirmed and indexed
    DW->>DW: switch advanced accounts on
    Note over DW: From here, ordinary writes route through the smart wallet"
/>

## Smart wallet deployment paths [#smart-wallet-deployment-paths]

You can deploy a smart wallet 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: it deploys the account on-chain, adds a management key on the participant identity, and registers the wallet in the identity registry before returning. The platform deploys and registers the wallet as part of that synchronous call.

That flow works differently. When the queue processes the new-participant operation, the participant has no on-chain identity yet.

### On-demand deployment for invited participants [#on-demand-deployment-for-invited-participants]

When an advanced-accounts organisation invites a new participant, that participant has no on-chain identity yet and no deployed smart wallet to look up.

The invitation flow uses counterfactual addressing. Before the queue submits anything, it predicts the smart wallet address from the account factory's deterministic formula and records that address alongside 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 and checks that it matches the recorded prediction. If the predicted smart wallet has no code yet, the queue attaches the account-factory initialisation data so the wallet deploys inside the same UserOperation.

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

The key invariant: your integration never supplies a trusted identity address. The queue derives the identity address inside the verified transaction workflow from the calldata and the operation target. The system trusts that derivation, not any address passed in from outside.

## Signing and execution as separate concerns [#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 advanced accounts 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. The execution path can change, for example when an operator updates the bundler configuration, without invalidating previously issued claim signatures.

## Account modularity and its limits [#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, you can add new validator types, such as session keys, additional multisig schemes, or hardware attestation, without replacing the account contract.

## Related pages [#related-pages]

* [Transaction signer](/docs/architects/components/infrastructure/transaction-signer) for how the queue resolves routes, signs, and serialises nonces across every execution path.
* [Advanced accounts concept](/docs/architecture/concepts/account-abstraction) for why DALP adopts account abstraction and where the boundary sits.
* [Advanced accounts security](/docs/compliance-security/security/advanced-accounts-security) for how sponsorship tickets, signing keys, and account-management rails bound the execution layer.
* [UserOperations](/docs/architects/components/infrastructure/advanced-accounts/user-operations) for how a UserOperation is built and moved from queue to chain.
* [Paymasters and gas sponsorship](/docs/architects/components/infrastructure/advanced-accounts/paymasters-and-gas-sponsorship) for how the platform checks and funds sponsored gas.
* [Nonce lanes and ordering](/docs/architects/components/infrastructure/advanced-accounts/nonce-lanes-and-ordering) for ordering across concurrent UserOperations.