Deployment topology
Client-facing deployment topology for DALP, covering runtime zones, network responsibility lines, EVM access, custody and data dependencies, operator ownership, and the recovery points used for HA and DR planning.
DALP deployments separate operator access, backend execution, durable workflow state, data storage, custody integration, and EVM network access. This page helps infrastructure, security, and operations teams decide where DALP fits in their environment.
For installation steps, use Self-hosting. This page is the architecture view.
Deployment terms
| Term | Meaning in DALP architecture |
|---|---|
| SaaS | SettleMint operates the DALP application runtime and shared platform services for the client under the agreed service model. |
| Managed deployment | SettleMint operates a client-specific DALP environment while the client still governs business roles, custody, and networks. |
| Customer-hosted | The client operates the DALP runtime in its own cloud, Kubernetes, OpenShift, or data-centre environment. |
| Air-gapped | A customer-hosted environment with no routine public internet path; external dependencies must be mirrored or brokered. |
| Hybrid | DALP runs in one controlled environment while selected dependencies, such as custody, RPC, storage, or monitoring, sit elsewhere. |
| Private chain | An EVM-compatible network operated for a restricted participant set rather than a public network. |
| Public-chain connectivity | DALP reaches a public EVM network through a configured RPC endpoint or node and inherits that network's visibility model. |
Runtime topology
Common deployment scenarios
These diagrams show where the main responsibility line sits. They do not prescribe a vendor or hosting product.
Runtime zones
| Zone | Contains | Exposure model |
|---|---|---|
| Public or controlled access zone | Asset Console, API ingress | Reached by operators, administrators, and approved integrations |
| Backend services zone | Unified API, Execution Engine workers, Chain Indexer, Chain Gateway, feeds | Internal service network with only intentional ingress and egress |
| Data and durable state zone | PostgreSQL and Durable Execution Engine, with backup or restore paths where the deployment uses them | Internal-only data plane |
| External or separately governed systems | Custody provider, EVM RPC endpoint or node, secrets backend, object storage, backup storage, observability stack | Governed by client, platform operator, or third-party provider contracts |
The exact infrastructure can vary by deployment, but these responsibility lines should remain visible in the design. Combining zones for a small environment changes the risk profile; it does not remove the responsibility line.
Component deployment responsibilities
| Component | Runs as | State profile | Primary operator concern |
|---|---|---|---|
| Asset Console | Web application | Stateless application runtime | Availability, TLS, routing, session-safe access |
| Unified API | Backend service | Uses PostgreSQL and Durable Execution Engine | Authentication, rate limiting, API health, database connectivity |
| Execution Engine | Durable worker services | Durable Execution Engine journals and workflow state | Workflow registration, worker health, transaction progress |
| Chain Indexer | Background service | PostgreSQL indexer schema/checkpoints | RPC access, catch-up progress, schema/version health |
| Chain Gateway | Network access service | Health and routing state | RPC endpoint availability, failover behavior, network configuration |
| Feeds services | Backend services | PostgreSQL feed records | Provider credentials, update cadence, stale data handling |
| PostgreSQL | Managed or self-hosted database | Persistent application and read data | Backup, restore, retention, access control, capacity |
| Durable Execution Engine | Durable execution runtime | Persistent workflow journals | Persistence, registration, recovery, capacity |
| Signer/custody backend | Local signer, DFNS, Fireblocks, or HSM-backed path depending on configuration | Provider-owned signing and approval state | Key governance, approval policy, provider availability |
| EVM RPC/node | Managed provider or operated node | Chain access and event history | Network selection, archive/history needs, rate limits, incident routing |
Private or permissioned chain provisioning
A private or permissioned DALP deployment still follows the same topology: DALP runs the application runtime, workflow workers, indexer, data plane, and gateway services in the selected environment, then connects those services to an EVM-compatible network selected for the asset programme. The network can be a client-operated private EVM network, a SettleMint-managed network, or a separately governed node/RPC endpoint.
| Provisioning area | DALP provides | Client, operator, or third party provides |
|---|---|---|
| Runtime platform | Containers, Helm chart inputs, service entry points, and environment values | Kubernetes or OpenShift cluster, namespaces, storage classes, ingress, DNS, TLS, and RBAC |
| Support services | Integration points for PostgreSQL, Redis, object storage, telemetry, backups | Managed services or approved in-cluster alternatives, credentials, retention, and backup policy |
| EVM network access | Chain Gateway and Chain Indexer connectivity to the configured EVM endpoint | Private EVM network or node/RPC operation, validator membership, archive/history policy, and incident route |
| Contract setup | Post-deployment contract wiring, address recording, and indexer sync checks | Deployment approval window, environment access, network parameters, and promotion approval |
| Signing and custody path | Signer integration boundary for transaction construction, approval, and status | HSM, custody provider, approval policy, key ceremony, maker-checker rules, and recovery process |
Provisioning normally starts with the self-hosting prerequisites, then platform deployment, post-deployment setup, verification, and handoff. A private-chain deployment adds explicit network decisions before installation: who operates validator and RPC nodes, which endpoints DALP may reach, how chain membership changes are approved, how archive or event history is retained for the indexer, and who owns RPC/node failover during incidents.
Out of the box, DALP supplies the product runtime, charts, services, EVM connectivity surfaces, contract deployment process, and indexer model. The institution or its infrastructure provider supplies the hosting environment, network operation model, custody/key governance, backup targets, recovery evidence, and any chain-specific controls that sit outside the DALP application runtime.
Bank IT review view
Bank architecture and security teams usually need the same deployment facts in a control-review format. Use this view to split the DALP runtime from the systems the institution must govern directly.
| Review area | Scope coverage | DALP component responsibility | Institution or operator decision |
|---|---|---|---|
| Runtime placement | Covered by DALP | Asset Console, Unified API, Execution Engine, Chain Indexer, Chain Gateway, and feeds run in the selected DALP deployment environment. | Choose managed, customer-hosted, air-gapped, or hybrid placement and approve the network paths between zones. |
| Durable state | Covered by DALP | PostgreSQL stores application and indexed operating data. The Durable Execution Engine stores workflow journals. | Define backup, restore, retention, access review, and RTO/RPO targets for the party operating the data plane. |
| Chain access | Standard integration | Chain Gateway and Chain Indexer use the configured EVM RPC endpoint or operated node. | Select the EVM network, RPC provider or node operator, archive/history requirements, rate limits, and incident escalation path. |
| Signing and custody | Standard integration | DALP calls the configured signer or custody path for transaction signing and approval-dependent actions. | Govern keys, approval policy, signer availability, provider onboarding, and custody operations outside the DALP application runtime. |
| Observability | Standard integration | DALP services emit logs, metrics, and traces to the configured telemetry sink. | Decide log retention, sensitive-data handling, dashboard ownership, alert routing, and incident-command process. |
| Secrets and storage | Standard integration | DALP reads configured secrets and object-storage locations where the deployment uses them. | Approve the secrets backend, rotation process, storage location, encryption controls, and administrative access. |
| Custody policy | Externally governed | DALP consumes the approved signer or custody path. | Define wallet ownership, maker-checker policy, key ceremony, approval requirements, and custody operating procedures outside DALP. |
Use the scope coverage column when reusing this material in architecture questionnaires. It gives reviewers a stable answer pattern: DALP covers the application runtime and durable workflow model, standard integrations cover the connected enterprise systems, and custody policy remains outside DALP unless the institution separately defines that operating model.
Recovery posture by topology
Use this page to draw the runtime choice. Use the high-availability pages to choose the recovery pattern.
The topology shows which component owns state. The recovery plan sets the restore target for each stateful surface, the acceptable data-loss window, and the team or provider that owns drill evidence.
| Recovery surface | What the topology must show | Recovery planning note |
|---|---|---|
| Application runtime | Ingress, Asset Console, Unified API, workers, Chain Gateway, Chain Indexer, and feeds | Place runtime services across the selected Kubernetes or OpenShift availability zones when the deployment uses the cloud-native baseline. |
| Durable data plane | PostgreSQL, Durable Execution Engine journals, backup storage, restore access, and retention owner | Set RTO and RPO with the party operating the data plane. Treat restore tests and measured recovery time as the evidence, not the target itself. |
| EVM access and indexing | RPC endpoint or node, Chain Gateway, Chain Indexer, and indexer catch-up path | Keep RPC failover and indexer replay separate from database restore. Chain state remains the source of truth when the indexer catches up after an outage. |
| Custody and signing | Signer or custody provider responsibility, approval policy, provider availability, and escalation path | Align signer recovery with the custody owner. DALP can keep workflow state, but transaction signing waits for the configured signer path. |
| Monitoring and incident response | Logs, metrics, traces, alert routes, dashboard owner, and incident commander | Alerting must cover the service, data plane, queues, RPC access, indexer lag, and custody reachability. The incident process remains an operating responsibility. |
DALP does not publish one universal RTO or RPO from this topology page. Those targets depend on the selected availability pattern, provider contracts, capacity, backup design, and restore drill results.
Use High availability to choose a pattern and Backup and recovery to plan restore evidence before making an external commitment.
What runs where
| Component | SaaS or managed deployment | Customer-hosted or air-gapped deployment | Hybrid note |
|---|---|---|---|
| Asset Console | Runs in the managed DALP application environment | Runs in the client runtime environment | Expose only through the client's approved ingress pattern. |
| Unified API | Runs in the managed DALP backend environment | Runs in the client backend services zone | Keep API ingress and service-to-service paths explicit. |
| Execution Engine | Runs with the managed backend workers and Durable Execution Engine integration | Runs with the client backend workers and local Durable Execution Engine runtime | Signing, RPC, and workflow recovery depend on the connected providers. |
| Chain Indexer | Runs in the managed backend and writes to the managed data plane | Runs in the client backend and writes to the client data plane | Public-chain indexing still depends on the selected RPC or operated node. |
| Chain Gateway | Runs in the managed backend services zone | Runs in the client backend services zone | Treat every external RPC endpoint as a separate network trust decision. |
| PostgreSQL | Operated under the managed service model | Operated by the client or its infrastructure provider | Backup, retention, and access review follow the party operating the data plane. |
| Durable Execution Engine | Operated under the managed service model | Operated by the client or its infrastructure provider | Recovery targets must match the workflow durability requirement. |
| Signer/custody backend | Connected as a separately governed provider or client-owned path | Connected to the client's HSM, signer, or custody provider path | Approval policy and key administration remain with the custody owner. |
| EVM RPC/node | Connected through managed RPC configuration or agreed node access | Operated or selected by the client | Public-chain RPC and private-chain nodes can coexist when both are configured. |
Network responsibility lines
| Responsibility line | Traffic crossing it | Control to review |
|---|---|---|
| User to console/API | Browser sessions, API requests | TLS, authentication, session policy, API keys, WAF/rate limiting |
| Console to Unified API | Authenticated application calls | Same-origin or controlled API routing, cookie/session behavior |
| API to backend workers | Workflow submissions and service calls | Internal service authentication, health checks, retry behavior |
| Backend to data plane | PostgreSQL and Durable Execution Engine traffic | Network isolation, credentials, encryption in transit where configured |
| Backend to custody provider | Signing requests, approval status, broadcast delegation | Provider credentials, approval policy, operational escalation path |
| Backend/indexer to EVM network | RPC calls, transaction broadcast, log/event ingestion | Chain ID, RPC endpoint trust, rate limits, reorg handling, confirmation policy |
| Backend to observability | Logs, metrics, traces | Data classification, retention, access control |
Failure domains and isolation points
| Failure domain | Isolated by | What fails first | RTO/RPO expectation | What should remain reviewable |
|---|---|---|---|---|
| Console or ingress outage | Public access zone separated from backend state | Operator UI or external API entry | Set RTO for operator access restoration; RPO is normally not affected because durable state stays outside the zone. | Backend state, workflow journals, chain state, and audit logs |
| Backend worker outage | Durable workflow state in Durable Execution Engine | New or resumed execution steps | Set RTO for worker capacity restoration; RPO follows the Durable Execution Engine journal target for in-flight workflows. | Submitted workflow state and prior transaction outcomes |
| PostgreSQL or data-plane outage | Data zone isolated from application ingress | API reads, dashboards, and indexed operating views | Set database RTO and backup RPO with the party operating PostgreSQL. | Chain source of truth and recovery backups |
| Durable Execution Engine outage | Workflow runtime separated from API ingress | Long-running action progress and retries | Set Durable Execution Engine RTO and journal RPO to match the workflow durability requirement. | API request logs and chain transactions already submitted |
| Custody provider outage | Custody provider outside the backend services zone | Transaction signing and approval-dependent actions | Set RTO/RPO with the custody or signer provider because approval state and key operations sit outside DALP. | Pending workflow state, provider status, and operator actions |
| RPC or node outage | Chain Gateway and indexer responsibility | Transaction broadcast, confirmations, and event ingestion | Set RPC/node RTO with the provider or node operator; RPO follows the chain source of truth and indexer catch-up. | Existing indexed data, pending workflow state, and alerts |
| Observability outage | Telemetry sink separated from transactional state | Dashboards, alerting, and trace search | Set telemetry RTO/RPO with the observability operator; transactional recovery must not depend on the telemetry sink. | Application state, workflow journals, chain events, and retained local logs |
Environment model
| Environment type | Purpose | EVM network pattern | Operating note |
|---|---|---|---|
| Development | Local development and deterministic validation | Local EVM such as Anvil | Convenience signing and local services are acceptable for development only |
| Staging | Integration testing and operational rehearsal | Testnet or private test network | Should resemble production topology where the risk review depends on topology |
| Production | Live regulated asset operations | Selected EVM-compatible production or private network | Custody, monitoring, backup, and incident routing must match the operating model |
Configuration changes should be explicit. A staging environment that uses a different custody path, RPC provider, or data-retention model is not equivalent to production for those controls.
Deployment decisions to make
| Decision | Options to evaluate | Why it matters |
|---|---|---|
| EVM network | Public EVM network, private EVM-compatible network, or testnet for non-production use | Determines finality, visibility, RPC requirements, and operational controls |
| Custody and signing | Local development signer, DFNS, Fireblocks, or HSM-backed setup where supported by deployment | Determines approval flow, signer availability, and key governance |
| Database operation | Managed PostgreSQL or self-hosted PostgreSQL | Determines backup, restore, encryption, capacity, and access model |
| Durable Execution Engine operation | Managed runtime pattern or self-hosted runtime as supported by deployment | Determines workflow durability and recovery responsibilities |
| RPC access | Managed RPC provider, operated node, or co-located node | Determines rate limits, reliability, event history, and escalation path |
| Observability | Existing enterprise stack or deployment-specific logging/metrics/tracing | Determines incident response, retention, and access review |
| Object storage and secrets | Provider choices aligned with client controls | Determines where sensitive configuration and files are governed |
Ownership matrix
| Responsibility | DALP supplies | Client/operator must define |
|---|---|---|
| Application deployment | Containers, service entry points, configuration model | Runtime platform, ingress, secrets, certificates, environment separation |
| Workflow operation | Durable execution services and status model | Capacity, alerting, recovery procedure, maintenance windows |
| Data persistence | Schema and application/indexer data model | Backup/restore policy, retention, access controls, disaster recovery |
| Chain connectivity | RPC clients, gateway, indexer ingestion | Network choice, RPC/node provider, rate limits, escalation path |
| Signing | Signer integration responsibility line | Custody provider, approval policy, key administration |
| Monitoring | Health signals and telemetry hooks | Dashboards, paging, retention, incident command |
Limits
| Limit | Consequence |
|---|---|
| No single prescribed topology | The docs describe responsibility lines; the client deployment must map them to its infrastructure |
| EVM-only network access | Non-EVM networks require a separate architecture and are not part of this deployment topology |
| No implicit custody policy | DALP can integrate with signer paths, but the institution owns key and approval governance |
| No availability claim here | Availability depends on the deployed topology, providers, capacity, support model, and tested recovery evidence |
Where to go next
- Self-hosting for installation and platform prerequisites
- High availability for topology patterns
- Operability for monitoring, database, and failure-mode guidance
- Integrations for custody providers, compliance providers, and supported networks
Quality attributes for regulated operations
Client-facing quality-attribute view of DALP architecture, covering security, reliability, operability, data consistency, performance constraints, and audit evidence without making SLA or legal claims.
Data domains
Client-facing data-domain map for DALP, showing which records are on-chain, which are off-chain, which are indexed, and who owns each governance decision.