# UserOperations Source: https://docs.settlemint.com/docs/architects/architecture/concepts/user-operations How UserOperations carry smart-account requests through DALP's smart wallet, bundler, EntryPoint, signing, and transaction tracking path. A UserOperation is the ERC-4337 request object that lets a smart account validate and execute a transaction through an EntryPoint contract. DALP uses UserOperations when a request must run through a smart wallet path. The UserOperation carries the execution payload, but participant identity, asset rules, signer policy, gas sponsorship, and transaction status stay in their own DALP controls. ## How DALP uses UserOperations [#how-dalp-uses-useroperations] UserOperations sit between the caller's request and the on-chain transaction. They are the smart-account execution envelope, not the full business process. The path has five responsibilities: 1. DALP selects the participant, chain, smart account, owner signer, and executor route for the request. 2. If the route uses a smart account, DALP builds the UserOperation payload for the requested contract call. 3. The configured owner signer or multisig policy authorises the UserOperation before submission. 4. The bundler simulates the payload, submits it to the configured EntryPoint, and follows the operation through inclusion. 5. DALP records the transaction result through transaction tracking, indexing, and webhook events. ## What the UserOperation carries [#what-the-useroperation-carries] | Field or concept | What it means in DALP | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | `sender` | The smart account that executes the call. | | `callData` | The encoded smart-account call DALP wants the account to run. | | `nonce` and nonce key | The ordering lane for the smart account. DALP uses nonce lanes so one pending operation does not have to block unrelated lanes. | | `signature` | The owner signature or encoded multisig signatures required by the smart account validator. | | `paymaster` fields | Optional gas sponsorship data. See [paymasters and gas sponsorship](/docs/architects/architecture/concepts/paymasters-and-gas-sponsorship). | | `userOpHash` | The hash used to track the operation through signing, bundling, and transaction confirmation. | ## What DALP controls outside the UserOperation [#what-dalp-controls-outside-the-useroperation] A UserOperation proves that a smart account can execute a specific call. It does not answer every regulated-platform question by itself. | Question | Where DALP answers it | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Which smart wallet can execute the call? | [Smart wallet API overview](/docs/developers/developer-guides/api-integration/smart-wallets) | | Which signer or threshold can approve it? | [Smart wallet approvals](/docs/developers/developer-guides/api-integration/smart-wallet-approvals) and [smart wallet thresholds](/docs/developers/developer-guides/api-integration/smart-wallet-thresholds) | | Which EntryPoint receives supported operations? | [Bundler JSON-RPC](/docs/developers/developer-guides/api-integration/bundler) | | Who pays gas for the operation? | [System paymasters](/docs/developers/developer-guides/api-integration/system-paymasters) | | How does an integration confirm the result? | [Transaction tracking](/docs/developers/developer-guides/operations/transaction-tracking) | ## Lifecycle states [#lifecycle-states] DALP tracks UserOperations before and after bundler submission so operators can distinguish queueing, execution, and terminal outcomes. | State | Meaning | | ------------ | --------------------------------------------------------------------------------------------------------------------- | | `PENDING` | The operation is accepted and waiting for preparation. | | `BLOCKED` | Another operation in the same nonce lane must finish first, or capacity is not yet available. | | `PREPARING` | DALP is reserving nonce capacity, estimating fees, building call data, or collecting the required signature material. | | `SUBMITTING` | DALP is sending the operation through the bundler path. | | `BUNDLED` | The bundler accepted the operation for inclusion. | | `MINED` | The operation reached a transaction on-chain and is waiting for the required confirmations. | | `CONFIRMED` | DALP observed the confirmed transaction result. | | `FAILED` | Preparation, signing, bundling, or execution failed. | | `EXPIRED` | DALP stopped waiting for inclusion before the operation reached a terminal on-chain result. | ## Idempotency and ordering [#idempotency-and-ordering] DALP queues UserOperations per organisation, chain, smart account, and nonce lane. The queue keeps FIFO order inside a lane and can prepare independent lanes in parallel when capacity allows it. When a caller supplies an idempotency key, DALP indexes it with the request payload. A repeated request with the same key and same payload resolves to the existing operation. A repeated key with a different payload is a conflict. This keeps retries from creating duplicate smart-account submissions. ## Related pages [#related-pages] * [Account abstraction model](/docs/architects/architecture/concepts/account-abstraction) explains the full smart-account model. * [Bundlers](/docs/architects/architecture/concepts/bundlers) explains the submission layer. * [Paymasters and gas sponsorship](/docs/architects/architecture/concepts/paymasters-and-gas-sponsorship) explains sponsored gas checks. * [Smart wallet approvals](/docs/developers/developer-guides/api-integration/smart-wallet-approvals) explains owner and multisig approval flows.