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.
DALP's quality model covers controlled execution, durable evidence, and clear operating state. This page maps DALP behaviour to the main quality questions for regulated operations.
The platform separates request control, durable execution, on-chain enforcement, and indexed visibility. The split shows where DALP accepts requests, submits transactions, enforces asset rules, and makes results visible. SLA terms, audit certifications, legal obligations, and privacy guarantees belong in the relevant contract and assurance material.
Quality map
Use this table as the first-pass review map. Each row names the quality attribute, the DALP mechanism behind it, and the client review question it supports.
| Attribute | DALP mechanism | Client review question |
|---|---|---|
| Security | Authentication, role checks, wallet verification, custody integration, contract enforcement | Whether access, signing, and asset-state controls are layered |
| Reliability | Durable Execution Engine-backed durable workflows, transaction status tracking, retry and reconciliation paths | Whether long-running blockchain actions can be inspected and resumed |
| Consistency | Chain events indexed into PostgreSQL-backed read models | Where the platform reads from and how current state becomes visible |
| Operability | Health checks, observability hooks, failure-mode documentation, explicit component ownership | Which teams need to monitor and recover each layer |
| Performance | API/database reads separated from block-time-bound writes | Which operations are instant, which are chain-bound, and which are queued |
| Evidence | API records, workflow state, transaction hashes, contract events, indexed views | Which artifacts support operational review and audit preparation |
Control layers
Each layer has a different job. A request can be authenticated but still fail authorization. A workflow can be accepted but wait for custody approval. A transaction can be submitted but not yet indexed. A dashboard can show the last indexed state while the chain is still being processed.
For support and audit review, start with the layer that owns the question. Authentication and authorization questions belong at the request layer. Signing delays and transaction retries belong at the execution layer. Compliance rule outcomes belong at the asset-control layer. Visibility and reconciliation questions belong at the indexed-read layer.
Security qualities
| Concern | DALP architecture response | Client responsibility |
|---|---|---|
| User access | Authenticated console and API routes, session handling, API keys, and role-aware middleware | Identity-provider policy, user lifecycle controls, administrator assignment |
| Transaction authorization | Wallet verification and role checks before blockchain writes | Role governance, segregation of duties, operating procedures |
| Signing | Signer abstraction supports local development signing and external custody-provider paths | Custody-provider setup, approval policy, key ceremony, signer administration |
| On-chain compliance | SMART Protocol contracts enforce configured identity and compliance rules before state changes | Selecting, configuring, and reviewing the required compliance modules |
| Public-chain exposure | Public-chain privacy is treated as a separate architecture concern, not hidden behind application access permissions | Deciding what data belongs on-chain and which EVM network is appropriate |
Reliability qualities
DALP treats blockchain writes as stateful workflows rather than single synchronous calls. The transaction-status path reads the platform transaction record and resolves receipts when available. When a completed transaction has a block number, the route checks whether the indexer has reached that block. Batch workflows can also expose the transaction hashes associated with the workflow state.
| Scenario | Architectural behavior |
|---|---|
| Multi-step asset creation | Runs as a durable workflow so deployment, configuration, role grants, claims, minting, and unpause steps can be tracked |
| Signer or custody delay | Transaction status remains visible while approval or signing is pending |
| RPC or broadcast failure | The transaction path can retry or surface a failed state depending on the failure type |
| Service restart during execution | Durable workflow state is journaled outside the application process |
| Chain visibility lag | Operator reads update after the indexer sees and processes chain events |
| Stuck or uncertain transaction status | Reconciliation and status pages are used to distinguish pre-broadcast, broadcast, confirmation, and indexing states |
Consistency model
| Data view | Source of truth | Consistency expectation |
|---|---|---|
| Token balance and asset state | EVM contract state | Final after chain inclusion and confirmation policy |
| Operator dashboard state | Indexed chain events plus platform database records | Follows indexer freshness and platform records |
| Transaction status | Platform transaction records, durable workflow state, chain receipts, and indexed events | Moves through accepted, signing, broadcast, confirming, indexed, failed, or canceled states |
| User and organization data | PostgreSQL application tables | Database-transaction consistency |
| Audit and action evidence | Platform records plus chain transaction and event evidence | Split across off-chain records and on-chain artifacts |
The important client decision is not whether every view is instantaneous. The review question is which source is authoritative for each decision. If a transaction is complete on-chain but absent from an operator view, treat the chain receipt and indexed read model as separate evidence surfaces until the indexer catches up.
Performance qualities
| Operation type | Usual bound | Operator implication |
|---|---|---|
| Console navigation | API and database read performance | Reads are designed for operator workflows and reporting, not direct chain scraping |
| API reads | Database query shape and indexed data freshness | Fast reads depend on maintained indexes and current indexed state |
| Blockchain writes | Workflow queueing, signer approval, gas, block time, confirmations, indexer catch-up | Operators should expect visible progress states rather than a single synchronous response |
| Asset deployment | Multiple contract transactions and post-deployment configuration | Treated as an operational workflow, not a one-click instant action |
| Large historical sync | RPC limits, block-range partitioning, database write throughput | Operational planning should include indexer catch-up time after backfills or network disruption |
Evidence matrix
Evidence is distributed across off-chain platform records and on-chain artifacts. Use the matrix to decide which artifact answers each review question before exporting records or escalating a support case.
| Review question | Evidence location |
|---|---|
| Who submitted the action? | Authenticated API or console records, user/session metadata, audit records |
| Was the action accepted for execution? | Transaction request and durable workflow records |
| Was custody approval required? | Signer or custody-provider status plus DALP transaction status |
| Did the transaction reach the chain? | Transaction hash and EVM receipt |
| Which contract rule applied? | Contract call path, events, compliance module configuration, indexed state |
| What can an operator see now? | Console/API read model after indexing |
Limits
| Limit | Why it matters |
|---|---|
| No SLA stated here | Architecture patterns do not define contractual availability, support response, or recovery-time terms |
| No legal compliance guarantee | Technical controls must be mapped to the client's legal and regulatory obligations |
| No hidden privacy layer | On-chain data visibility depends on the selected EVM network and the data written to contracts/events |
| No instant finality claim | Blockchain writes remain subject to transaction inclusion, confirmation policy, and indexer freshness |
| No provider availability claim | Custody, RPC, object storage, secrets, and observability providers remain part of the full operating model |
Where to go next
- Deployment topology for runtime zones and network paths
- Data domains for source-of-truth decisions
- Failure modes for operational degradation paths
- Wallet verification for the per-request signing gate
- Source verification and auditability for deployment-source and audit-review evidence
- Signing flow for the transaction signing sequence
Principles and scope
Client-facing architecture responsibilities for DALP, written for review teams evaluating regulated digital asset operations on EVM networks.
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.