UserOperations
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.
Requires: account abstraction enabled for the deployment.
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:
- DALP selects the participant, chain, smart account, owner signer, and executor route for the request.
- If the route uses a smart account, DALP builds the UserOperation payload for the requested contract call.
- The configured owner signer or multisig policy authorises the UserOperation before submission.
- The bundler simulates the payload, submits it to the configured EntryPoint, and follows the operation through inclusion.
- DALP records the transaction result through transaction tracking, indexing, and webhook events.
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. |
userOpHash | The hash used to track the operation through signing, bundling, and transaction confirmation. |
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 |
| Which signer or threshold can approve it? | Smart wallet approvals and smart wallet thresholds |
| Which EntryPoint receives supported operations? | Bundler JSON-RPC |
| Who pays gas for the operation? | System paymasters |
| How does an integration confirm the result? | Transaction tracking |
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
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
- Account abstraction model explains the full smart-account model.
- Bundlers explains the submission layer.
- Paymasters and gas sponsorship explains sponsored gas checks.
- Smart wallet approvals explains owner and multisig approval flows.
Account abstraction 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.
Bundlers
How DALP uses bundler-compatible discovery while keeping UserOperation submission behind the platform execution path.