# Infrastructure overview

Source: https://docs.settlemint.com/docs/architects/architecture/components/infrastructure
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.




DALP infrastructure services turn accepted platform requests into EVM operations that can be signed, submitted, confirmed, indexed, and observed.
The layer sits below the Asset Console and Unified API.
Infrastructure owns the technical execution path after DALP has selected the asset, participant, compliance route, signer route, and chain context.

Architecture reviewers, security reviewers, and operators answer one question here: which service owns each part of the execution path, and where does that responsibility stop?
For task steps, use the linked component and flow pages.

## Scope [#scope]

Reviewers get the mental model for DALP infrastructure before they inspect the component references. The page covers four review paths:

* workflow continuity from accepted platform request to terminal outcome
* signer and custody routing without turning DALP into the custody provider
* EVM connectivity, transaction submission, event indexing, and read-model freshness
* external feed values as configured workflow inputs

It does not document business approval rules, legal commitments, custody-provider controls, RPC-provider service levels, or non-EVM networks.

## Execution path at a glance [#execution-path-at-a-glance]

The request path has two review boundaries.
Platform services check whether an operation is valid for the asset, participant, policy, and chain context.
Infrastructure services carry out the EVM execution work and report the result back to platform read models.

<Mermaid
  chart="`flowchart LR
  REQUEST[&#x22;Accepted platform request&#x22;] --> WORK[&#x22;Workflow continuity&#x22;]
  WORK --> PREPARE[&#x22;Prepare EVM call&#x22;]
  PREPARE --> SIGN[&#x22;Route signing&#x22;]
  SIGN --> SUBMIT[&#x22;Submit through EVM access&#x22;]
  SUBMIT --> CONFIRM[&#x22;Confirm and index events&#x22;]
  CONFIRM --> READ[&#x22;Update Console and API read models&#x22;]

  style REQUEST fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style WORK fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style PREPARE fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style SIGN fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style SUBMIT fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style CONFIRM fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style READ fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff`"
/>

Each step can involve different deployment providers. The infrastructure layer keeps the DALP responsibility clear while still allowing operators to choose custody, RPC, observability, and feed-source implementations.

## How the services fit together [#how-the-services-fit-together]

The infrastructure layer is the execution backbone between DALP's business-facing platform and the EVM networks it operates on.
A user request becomes a managed workflow. The platform validates the business context. Infrastructure services preserve progress, prepare the chain operation, request signatures through the configured custody path, submit the transaction, and update application read models after chain events are indexed.

<Mermaid
  chart="`flowchart TB
  subgraph USERS[&#x22;Users and integrations&#x22;]
    CONSOLE(Asset Console)
    API(Unified API, CLI, and SDK)
  end

  subgraph PLATFORM[&#x22;Platform decisions&#x22;]
    IDENTITY(Identity and participants)
    POLICY(Asset rules and compliance path)
    WORKFLOW(Lifecycle workflow)
  end

  subgraph INFRA[&#x22;Infrastructure layer&#x22;]
    ENGINE(Workflow execution service)
    RUNTIME(EVM contract runtime)
    SIGNER(Transaction signing route)
    GUARDIAN(Key-control boundary)
    GATEWAY(EVM access gateway)
    INDEXER(Event indexing service)
    FEEDS(Feed-value service)
  end

  subgraph EVM[&#x22;EVM networks and providers&#x22;]
    RPC(EVM RPC endpoints)
    CONTRACTS(Smart contracts)
    EVENTS(Chain events)
    CUSTODY(Custody and HSM providers)
    SOURCES(External feed sources)
  end

  CONSOLE --> IDENTITY
  API --> IDENTITY
  IDENTITY --> POLICY
  POLICY --> WORKFLOW
  WORKFLOW --> ENGINE
  ENGINE --> RUNTIME
  RUNTIME --> SIGNER
  SIGNER --> GUARDIAN
  SIGNER --> GATEWAY
  GATEWAY --> RPC
  RPC --> CONTRACTS
  CONTRACTS --> EVENTS
  EVENTS --> INDEXER
  GUARDIAN --> CUSTODY
  SOURCES --> FEEDS
  FEEDS --> WORKFLOW
  INDEXER --> API

  style CONSOLE fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style API fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style IDENTITY fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style POLICY fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style WORKFLOW fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style ENGINE fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style RUNTIME fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style SIGNER fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style GUARDIAN fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style GATEWAY fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style INDEXER fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style FEEDS fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style RPC fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style CONTRACTS fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style EVENTS fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style CUSTODY fill:#f5a623,stroke:#c78314,stroke-width:2px,color:#fff
  style SOURCES fill:#f5a623,stroke:#c78314,stroke-width:2px,color:#fff`"
/>

The separation gives client teams two review paths.
Product and compliance teams can focus on the Asset Console, Unified API, identity model, asset rules, and workflows.
Technology, security, and operations teams can review signing, EVM connectivity, retries, read-model freshness, and deployment-specific providers.

## Decision path for reviewers [#decision-path-for-reviewers]

Start with the operation you need to explain, then open the detail page for the service that owns that part of the operation.

| Review question                                  | Read next                                                                                                                                                                                                                      | What the page defines                                                                                                                                  |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| How does DALP keep a multi-step operation alive? | [Execution Engine](/docs/architects/architecture/components/infrastructure/execution-engine)                                                                                                                                   | Workflow orchestration, retry handling, failure recovery, and how lifecycle operations continue across infrastructure steps.                           |
| How are transactions prepared and sent?          | [Contract Runtime](/docs/architects/architecture/components/infrastructure/contract-runtime), then [Transaction Signer](/docs/architects/architecture/components/infrastructure/transaction-signer)                            | ABI encoding, contract calls, state queries, gas handling, nonce coordination, signing, and broadcasting.                                              |
| Where are signing keys controlled?               | [Key Guardian](/docs/architects/architecture/components/infrastructure/key-guardian), plus [Account abstraction](/docs/architects/architecture/components/infrastructure/account-abstraction) when smart accounts are in scope | Local, custody-provider, HSM-backed, and ERC-4337 signing paths, including which component controls key material and smart-account execution.          |
| How does DALP reach EVM networks?                | [Chain Gateway](/docs/architects/architecture/components/infrastructure/chain-gateway) and [EVM RPC Node](/docs/architects/architecture/components/infrastructure/evm-rpc-node)                                                | RPC routing, upstream configuration, failover, direct JSON-RPC access, transaction submission, state queries, and supported EVM connectivity patterns. |
| How do chain events become application state?    | [Chain Indexer](/docs/architects/architecture/data-availability/chain-indexer)                                                                                                                                                 | Event ingestion, event-to-domain translation, historical blockchain state, and queryable read models for applications and integrations.                |
| How are external prices and values supplied?     | [Feeds system](/docs/architects/architecture/components/infrastructure/feeds-system)                                                                                                                                           | Price and foreign-exchange feed types, subject scopes, feed resolution, and where feed values enter DALP workflows.                                    |

The detail pages are the public reference set for the overview above.
Component names remain visible because those names are the stable documentation entry points.
The surrounding tables describe public responsibilities instead of exposing deployment-specific internals.

## Review sequence [#review-sequence]

Read the page in this order when you need a fast architecture review:

1. Use the execution path diagram to place the operation.
2. Use the decision table to choose the component reference.
3. Use the ownership table to separate DALP behavior from operator and provider responsibilities.
4. Use the related pages for detailed flows or component contracts.

## Operating model [#operating-model]

Operators configure and monitor infrastructure services.
End users and integrations do not call infrastructure components directly. They use the Asset Console, Unified API, CLI, SDK, or documented integration endpoints.

That split keeps the user-facing workflow stable while operators can change custody backends, RPC providers, deployment topology, feed sources, and observability wiring behind it.

![Infrastructure monitoring with real-time API metrics](/docs/screenshots/monitoring/api-monitoring-overview.webp)

## Ownership and limits [#ownership-and-limits]

| Area                        | DALP infrastructure covers                                                                                  | Operator or provider owns                                                                                                        | Not covered                                                                               |
| --------------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Workflow execution          | Coordinating infrastructure steps, retrying supported operations, and preserving progress.                  | Deployment sizing, operational runbooks, monitoring response, and incident escalation.                                           | Business approval rules, legal sign-off, or asset-policy decisions.                       |
| Signing and custody         | Preparing signing requests and routing them through the configured signer path.                             | Custody-provider configuration, HSM operation, key ceremonies, access policies, and contractual custody commitments.             | A blanket custody guarantee or replacement for the selected custody provider's controls.  |
| EVM connectivity            | Routing contract calls, transaction submission, reads, retries, and failover through configured EVM access. | RPC provider selection, private-network access, endpoint credentials, throughput planning, and network availability commitments. | Non-EVM networks, bridge guarantees, settlement finality promises, or RPC-provider SLAs.  |
| Indexed state and feed data | Turning supported chain events into read models and resolving configured feed values.                       | Feed-source contracts, data-vendor controls, source freshness monitoring, and deployment-specific reconciliation procedures.     | Legal valuation, market-data licensing commitments, or external source accuracy promises. |

## Component responsibilities [#component-responsibilities]

| Responsibility                      | Infrastructure services involved                                                                                                                                                                                                                                                           | What client reviewers should understand                                                                                                            |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow continuity                 | [Execution Engine](/docs/architects/architecture/components/infrastructure/execution-engine), [Transaction Signer](/docs/architects/architecture/components/infrastructure/transaction-signer)                                                                                             | Multi-step lifecycle requests are coordinated, retried, and resumed without exposing raw infrastructure steps to users.                            |
| Signing and custody                 | [Key Guardian](/docs/architects/architecture/components/infrastructure/key-guardian), [Transaction Signer](/docs/architects/architecture/components/infrastructure/transaction-signer), [Account abstraction](/docs/architects/architecture/components/infrastructure/account-abstraction) | Signing routes can use local signing, custody providers, HSM-backed signing, or ERC-4337 execution paths.                                          |
| EVM network access                  | [Contract Runtime](/docs/architects/architecture/components/infrastructure/contract-runtime), [Chain Gateway](/docs/architects/architecture/components/infrastructure/chain-gateway), [EVM RPC Node](/docs/architects/architecture/components/infrastructure/evm-rpc-node)                 | Contract calls, transaction submission, RPC routing, failover, and chain reads are handled below the platform interfaces.                          |
| Queryable state and external values | [Chain Indexer](/docs/architects/architecture/data-availability/chain-indexer), [Feeds system](/docs/architects/architecture/components/infrastructure/feeds-system)                                                                                                                       | Chain events become application read models, while feed data remains an operator-controlled input for workflows that need trusted external values. |

## What stays outside this layer [#what-stays-outside-this-layer]

Infrastructure services do not replace the platform's identity, compliance, asset, or policy model.
The services execute the operation after the platform has selected the asset, participant, compliance path, signer route, and chain context.

Infrastructure services also do not make legal, custody, RPC-provider, or availability promises by themselves.
Those commitments depend on the selected deployment architecture, custody backend, network providers, monitoring setup, and contractual operating model.

## Related architecture pages [#related-architecture-pages]

* [Component catalog](/docs/architects/architecture/components) for the full platform inventory
* [Platform layer](/docs/architects/architecture/components/platform) for the interfaces that call into infrastructure services
* [Key flows](/docs/architects/architecture/flows) for cross-service operation sequences