# DALP Execution Engine

Source: https://docs.settlemint.com/docs/architecture/components/infrastructure/execution-engine
The DALP Execution Engine orchestrates digital asset lifecycle operations
with guaranteed delivery, automatic retry handling, and transparent failure
recovery, ensuring complex multi-step processes complete reliably even
through system failures.




## Overview [#overview]

The DALP Execution Engine coordinates multi-step operations across platform components. Workflows persist at each step, enabling reliable completion despite process restarts, network failures, or partial execution errors.

Blockchain operations present unique orchestration challenges. Transaction confirmation requires minutes rather than milliseconds. Gas prices fluctuate unpredictably. Nonce conflicts occur under concurrent load. The DALP Execution Engine addresses these realities through purpose-built workflow patterns.

## The challenge of blockchain orchestration [#the-challenge-of-blockchain-orchestration]

Traditional request-response patterns fail for blockchain operations. A single asset issuance may require:

1. Verify investor eligibility
2. Deploy token contract
3. Wait for deployment confirmation
4. Configure compliance rules
5. Mint initial supply
6. Register with identity provider
7. Notify stakeholders

Each step can fail independently. Steps 2-5 involve blockchain transactions that may take minutes. Naive implementations lose state if the process restarts between steps.

## Workflow patterns [#workflow-patterns]

### Persistent state machines [#persistent-state-machines]

Every workflow maintains persistent state that survives process boundaries. State transitions record to storage before execution proceeds. Restart recovery reads last persisted state and continues from that checkpoint.

### Exactly-once semantics [#exactly-once-semantics]

Workflow steps execute exactly once regardless of retries or restarts. Unique operation identifiers prevent duplicate blockchain transactions. Idempotency keys ensure side effects occur only on first execution.

### Virtual object pattern [#virtual-object-pattern]

Long-running entities like transaction nonces maintain consistent state through virtual objects. Concurrent access serializes through the execution engine. No distributed locking or coordination protocols required.

## Workflow architecture [#workflow-architecture]

<Mermaid
  chart="`flowchart TB
  subgraph ENTRY[&#x22;Entry points&#x22;]
    API(Unified API)
    CONSOLE(Asset Console)
  end

  subgraph ENGINE[&#x22;DALP Execution Engine&#x22;]
    WF(Workflow Handlers)
    STATE(State Store)
  end

  subgraph EXEC[&#x22;Execution targets&#x22;]
    KG(Key Guardian)
    TS(Transaction Signer)
    CR(Contract Runtime)
  end

  API --> WF
  CONSOLE --> WF
  WF --> STATE
  WF --> KG
  WF --> TS
  WF --> CR

  style API fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style CONSOLE fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style WF fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style STATE fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style KG fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style TS fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style CR fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff`"
/>

## Failure recovery [#failure-recovery]

### Automatic retry [#automatic-retry]

Transient failures trigger automatic retry with exponential backoff. Retry policies configure per-operation based on expected failure patterns. Blockchain transaction retries increment gas prices to resolve stuck transactions.

### Compensating transactions [#compensating-transactions]

Permanent failures trigger compensating workflows. If token minting fails after contract deployment, the engine initiates contract pause and investor notification workflows. Partial state never persists without explicit handling.

### Dead letter handling [#dead-letter-handling]

Operations exhausting retry budgets route to dead letter queues. Operations teams receive alerts for manual intervention. Replay mechanisms enable resumption after root cause resolution.

## Observability [#observability]

The engine provides complete visibility into workflow execution:

**State inspection**: Current state and history for any workflow instance accessible through administrative interfaces.

**Distributed tracing**: Correlation identifiers flow through all workflow steps. Trace spans capture timing and outcomes for performance analysis.

**Progress dashboards**: Real-time views of active workflows by type and state. Bottleneck identification through queue depth monitoring.

**Audit logs**: Every state transition records for compliance review. Retention policies ensure availability for regulatory examination periods.

## See also [#see-also]

* [Transaction Signer](/docs/architecture/components/infrastructure/transaction-signer) for blockchain operations
* [Key Guardian](/docs/architecture/components/infrastructure/key-guardian) for secure key storage
* [Observability](/docs/architecture/operability/observability) for monitoring dashboards
* [Unified API](/docs/architecture/components/platform/unified-api) for API entry point
* [Asset Console](/docs/architecture/components/platform/asset-console) for UI entry point