Execution Engine
The DALP Execution Engine coordinates long-running asset lifecycle operations with workflow-runtime-backed workflows, persisted workflow progress, signer routing, transaction state transitions, and stalled-workflow metrics.
Overview
The Execution Engine is the DALP layer that turns an accepted asset lifecycle request into durable platform work. It hosts workflow-runtime-backed services for asset, identity, feed, smart-wallet, bundler, approval, transaction, reconciliation, monitoring, and webhook workflows.
Use this page when you need to understand where long-running work is coordinated and where that responsibility stops. It does not replace the API reference, the transaction signing flow, custody-provider setup, or operational runbooks.
Why DALP needs durable workflows
Asset lifecycle requests can cross API validation, wallet routing, signer or custody approval, EVM transaction submission, receipt confirmation, indexer catch-up, and reconciliation before they become visible state. Local validation can finish quickly. Provider approval, quorum approval, receipt confirmation, and indexer catch-up can take longer.
The Execution Engine keeps those steps out of a single HTTP request lifecycle. Accepted work is journaled as workflow progress, and callers can receive an immediate pending result while the workflow continues through approval, broadcast, confirmation, or a terminal failure.
Architecture model
The ddwf worker starts a workflow runtime endpoint, binds DALP workflow services, registers the endpoint with workflow runtime when auto-registration is enabled, and starts recurring monitoring, reconciliation, and exchange-rate refresh work. The HTTP health server is available before asynchronous startup completes, so liveness checks can run while telemetry, registration, and workflow bootstrap continue.
What the engine coordinates
| Concern | Engine responsibility | Boundary |
|---|---|---|
| Workflow hosting | Binds DALP workflow and virtual-object services to a workflow runtime endpoint. | The workflow runtime provides the durable runtime. DALP registers and calls its services through configured ingress and health endpoints. |
| Transaction execution | Reads the stored operation, resolves the signer route, validates direct EOA or provider-broadcast contract targets, appends DALP attribution, and moves transaction state through approval, broadcast, confirmation, completion, failed, blocked, or dead-letter outcomes. | The signer or custody provider owns private-key operation and provider policy decisions. SMART Protocol contracts own on-chain rule enforcement. |
| Nonce serialization | Uses a per-organization, signer-address, and chain partition for direct transaction submission, so one sender on one chain is processed through an exclusive queue. | It does not create finality or cross-chain replay protection. Chain ID, network behavior, and contract design still matter. |
| Approval waits | Keeps sign-only approval, Luna quorum approval, Fireblocks approval polling, and smart-wallet multisig approval in durable workflow paths. | Approval policy remains in the configured signer, custody provider, HSM, or smart-wallet threshold. |
| Status reads | Stores workflow phase, transaction id, and error state for the transaction execution workflow's shared status handler. | Public operational status still comes from the relevant API, console surface, transaction record, and indexed read model. |
| Observability | Emits workflow registration, startup, bound-service, completed-workflow, stalled-workflow, and exchange-rate scheduler metrics through OpenTelemetry. | Dashboards, alerts, retention, and evidence packaging are deployment and operations responsibilities. |
Workflow patterns
Persisted workflow state
The transaction execution workflow stores status phases as submitting, awaiting-approval, confirming, completed, blocked, or failed. Its shared status read returns the current phase, transaction id, and error message when one is present.
The engine uses workflow-runtime journaled steps for operations that must survive replay. For example, provider type resolution, contract validation, state transitions, approval waits, and confirmation checks run inside workflow context rather than relying only on process memory.
Terminal and retryable failures
DALP distinguishes terminal workflow failures from transient infrastructure failures. The workflow runtime retry helper rethrows terminal errors immediately and retries other workflow runtime client errors with fixed backoff. Transaction execution uses terminal errors for validation and policy outcomes that should not be treated as temporary platform outages.
When a smart-wallet user operation cannot proceed because the queue is blocked, DALP records a blocked transaction outcome with BLOCKED_BY_QUEUE. Other failed queue outcomes move the transaction to a failed state. Pre-broadcast terminal failures can move a transaction into a dead-letter state so it does not remain stuck in preparation or signing.
Approval and confirmation continuity
Routes with external approval can return a pending marker before the workflow is done. A smart-wallet multisig route can return pending approval while a follow-up approval workflow owns on-chain submission. A sign-only provider route can return pending policy approval while the workflow waits for the approved signed transaction, broadcasts it, and confirms it.
After broadcast, the engine starts confirmation monitoring for the chain and checks the transaction receipt. When a confirmed receipt includes a block number, DALP can wait for the indexer to catch up before marking asynchronous consumers as completed.
Virtual objects for serialized work
Long-running sender state is serialized through workflow runtime virtual objects. The transaction processor owns per-sender and per-chain processing for nonce-sensitive direct EVM transactions. Bundler, approval, monitoring, reconciliation, and other workflow services use their own service keys for the state they own.
Virtual objects reduce the need for application-level distributed locks, but they are scoped controls. They protect the keyed workflow state they own. They do not replace custody policy, database consistency checks, contract validation, or chain confirmation.
Replay-safe logging and compensation
The durable package adds replay context to logs so replayed handler attempts can be tagged with workflow invocation metadata and duplicate logs can be suppressed during journal replay. DALP also has a saga helper for workflows that need compensating actions: successful steps register compensations, and failures run those compensations in reverse order.
Use those patterns as architecture signals, not as a blanket promise that every workflow has a compensation path. A workflow documents its own terminal states, cleanup behavior, and caller response.
Operational visibility
The engine emits application-level OpenTelemetry metrics under the dalp.ddwf meter. The metric set includes:
| Metric | What it indicates |
|---|---|
dalp.ddwf.endpoint.registrations | workflow runtime endpoint registration attempts labeled by outcome. |
dalp.ddwf.services.bound | Number of DALP workflow services bound to the endpoint. |
dalp.ddwf.startup.duration_ms | Time from telemetry initialization to the worker being fully started. |
dalp.ddwf.workflow.completed | Workflow handler attempts that reached success or a terminal error, labeled by workflow type and outcome. |
dalp.ddwf.workflow.stalled | workflow invocations classified as stalled at observation time. |
dalp.ddwf.exchange_rate.schedulers.active | Number of bootstrapped exchange-rate refresh schedulers. |
Stall detection is query-time logic. An invocation is stalled when it has been pending beyond the configured pending threshold and has not mutated state beyond the configured no-mutation threshold. The worker samples workflow runtime admin query data when the OpenTelemetry exporter observes the gauge, rather than keeping a long-lived in-process cache.
What this does not mean
| Misread | Correct interpretation |
|---|---|
| "Durable workflow" means every transaction succeeds. | Durable workflow means progress, waits, retries, and terminal outcomes are coordinated through the workflow runtime. Contract reverts, policy denials, missing contract code, provider failures, and chain failures can still end in failed, blocked, or dead-letter states. |
| "Retries" mean callers should resubmit freely. | Callers should use the documented idempotency key and status surfaces. A retry with different executor selection can be rejected instead of attaching to the earlier transaction. |
| "Virtual object" means global serialization. | Serialization is scoped by service and key, such as one signer address on one chain. Unrelated signers and services can continue processing. |
| "Metrics" means a built-in evidence-retention policy. | The engine emits metrics and workflow status. Alerting, retention, reports, and regulatory evidence packaging depend on the deployment and operating model. |
See also
- Architecture overview for the platform control model
- Transaction Signer for signer routes, custody approval, nonce controls, and confirmation behavior
- Contract Runtime for typed contract reads, writes, and transaction construction
- Asset Console for the human operator surface above the execution layer
- API error reference for durable execution dependency errors exposed through the public API
Infrastructure overview
The infrastructure layer coordinates the execution services that preserve DALP workflows, prepare EVM transactions, route signing, submit chain operations, index events, route RPC traffic, and provide trusted feed data behind the platform interfaces.
Account abstraction
Understand how DALP uses ERC-4337 smart accounts, EntryPoint routing, bundlers, paymasters, and validator modules for sponsored and threshold-controlled transactions.