Quality attributes
Assign security, reliability, operability, and evidence questions to the layer that owns them: request control, durable execution, on-chain enforcement, or indexed visibility. Each layer has a distinct failure mode and a distinct support path.
DALP separates request control, durable execution, on-chain enforcement, and indexed visibility into distinct layers. Each layer has a specific job: the platform accepts requests, submits transactions, enforces asset rules, and makes results visible. Reach for this page after lifecycle after issuance when a review asks how the architecture handles security, reliability, operability, consistency, performance, or audit evidence.
SLA terms, audit certifications, legal obligations, and privacy guarantees belong in the relevant contract and assurance material. Continue with deployment topology when the review needs to understand runtime placement and ownership.
Quality map
Use this table as the first-pass map. Each row names the quality attribute, the DALP mechanism behind it, and the question a reviewer should be able to answer.
| Attribute | DALP mechanism | Client review question |
|---|---|---|
| Security | Authentication, role checks, wallet verification, custody integration, contract enforcement | Whether access controls, signing gates, and on-chain enforcement cover every layer |
| Reliability | workflow engine-backed durable workflows, transaction status tracking, retry, and reconciliation paths | Whether operators can inspect and resume long-running blockchain operations |
| 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
Four layers handle distinct stages of a request: authentication and authorization, durable execution, on-chain asset enforcement, and indexed visibility. Each layer has its own failure mode and its own support path.
Each layer has a different job. The platform can authenticate a request and still reject it at authorization. The workflow engine can accept a workflow and then wait for custody approval. The platform can submit a transaction and leave it not yet indexed. A dashboard can show the last indexed state while indexing is still in progress.
For support and audit review, start with the layer that owns the question. Authentication and authorization questions go to the request layer. Signing delays and retries go to the execution layer. Compliance rule outcomes go to the asset-control layer. Reconciliation and read-visibility questions go to 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 | Choosing which compliance modules to enable, configuring them, and keeping their settings current |
| Public-chain exposure | The platform treats public-chain privacy 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 record and resolves receipts when available. When a confirmed transaction has a block number, the route checks whether the indexer has reached that block. For batch operations, you can also retrieve the hashes associated with the workflow state.
| Scenario | Architectural behavior |
|---|---|
| Multi-step asset creation | Runs as a durable workflow so you can track deployment, configuration, role grants, claims, minting, and unpause steps |
| 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 | The platform journals durable workflow state 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 let you distinguish pre-broadcast, broadcast, confirmed, and indexed 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 key question is not whether every view is instantaneous. Know 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 the 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 | Plan it 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 sits across off-chain platform records and on-chain artifacts. Use the matrix to pick the right artifact for each 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 | You must map technical controls to your 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
Lifecycle after issuance
How DALP operators manage an issued asset after deployment, from the asset detail workspace through supply, transfer, pause, role, compliance, feature, and audit operations.
Deployment topology
Where DALP components run, which runtime zones they occupy, which systems they depend on, and which operating responsibilities remain with the client across SaaS, customer-hosted, air-gapped, and hybrid placements.