Architecture one-pager

Read this after the architecture overview when your review asks which system owns a specific decision. The map gives each area a clear owner: operator workspaces, API calls, transaction lifecycle, compliance checks, signing, pricing, on-chain enforcement, indexed evidence, and shared platform services.

The short version

Eight product systems describe the platform. They are responsibility boundaries, not eight deployable services. Operators, compliance teams, treasury, and integrators work in the Operations Console, which drives one Platform API. The Transaction Lifecycle Engine runs every write end to end: it checks each transfer with Compliance & Identity, signs through Custody & Settlement, prices with Market Data, and writes to the Asset Registry contracts on your selected EVM network. The Ledger Index reads chain events back for query and audit, and the Core Platform carries all of it. One DAPI image runs as three required roles: API, Workflow Engine runner, and Ledger Index.

The runtime boundary is equally deliberate: the Platform API, Workflow Engine, and Ledger Index retain separate process ownership while sharing one release, PostgreSQL data plane, and typed application graph. Each deployment sets its role explicitly; there is no combined process or role default. The platform contract is the observable request, workflow, and indexed-read behaviour described on this page.

The Platform API keeps its public versions as two separate declaration roots. Those declarations contain only transport-safe schemas and route metadata; domain capabilities own the Effects that perform the work, the API server binds their typed handlers to one exact mounted version, and the backend host alone owns the public paths and retained operational routes. This ownership prevents a v2 transformation from changing v1 implicitly, and it makes a missing, duplicate, or wrong-version route binding a startup failure rather than a partially available API. Streaming routes use the same declarations and keep declared failures typed, while unexpected post-commit failures are redacted at the stream boundary before they can become public events.

Server-side SDK and CLI clients compress eligible buffered JSON and text request bodies with gzip when the original body is between 1 KiB and 16 MiB. Browser requests stay unchanged. The Platform API host supports gzip and deflate. It also supports Brotli and Zstandard. Decoding runs ahead of authentication and route handling. The host applies the request deadline and separate 16 MiB limits to the encoded and decoded body, so a stalled upload, malformed payload, unsupported encoding, or oversized result fails without entering domain code. Downstream handlers receive the same plain bytes as they receive from an uncompressed request.

Upgrade the Platform API host before clients enable compression, or upgrade both sides together. The client never retries without compression, so a state-changing request is not sent twice after an uncertain result.

The role trio is also the backend's versioning and recovery boundary. A release moves its API contracts, durable coordination, and event projections together; database migrations complete before the new role pods become ready. Operators can therefore reason about one immutable backend version without collapsing the distinct responsibilities inside it.

The backend release is a bytecode-enabled Bun executable in a non-root distroless image. One manifest publishes native Linux variants for AMD64 and ARM64. Both variants use the same application version and platform contract. The image installs no packages at startup. Bun serves HTTP while the application scope coordinates graceful drain and durable-work release.

The Core Platform applies one identity contract to telemetry. Every record carries the deployment environment and release version. The service and replica supply execution identity. Request and workflow records use bounded labels for their operation and outcome. Collector redaction and cardinality controls run before routing; sampling is collector policy. Grafana uses versioned dashboards and alert rules, so an operator can move from an alert to the process and request that triggered it without searching message text. A running workflow that stops advancing past the configured pending and no-mutation thresholds raises dalp_ddwf_workflow_stalled from the same execution-status projection the platform-status panel reads, so a wedged organization deploy is visible in PromQL without scraping logs.

The runner and indexer roles have a startup obligation. A role joins its durable work partition as soon as its coordination runtime opens, which is earlier than the point at which it is ready. Every capability therefore registers before any startup work that reaches the database or a chain endpoint, so a role pod never holds durable work it cannot serve. API pods use only the cluster client and own no shard, schedule, or fleet listener. The Ledger Index binding its deployment after registration rather than before it is that rule applied, not an implementation detail.

The Platform API also owns the opt-in readiness decision for onboarding while the Ledger Index rebuilds. A request with the documented Prefer directive is rejected with a retry hint when indexed state is not ready. A request without the directive keeps the normal workflow behavior. The HTTP host only projects that decision onto the response, so it cannot maintain a second readiness model that drifts from the deployment operation.

The Operations Console applies that same Prefer wait contract to operator mutations. When a write settles inside the request, or when it finishes later under a deferred terminal outcome, the Console refreshes the same lists, detail reads, and action queues for the affected scope. Immediate success and deferred completion therefore cannot diverge on which screens go stale. A slow mint, approve, freeze, or settlement cannot leave a detail page on pre-settlement data while an index row already shows the new state. Wallet and asset list ownership stays with the packages that read those records; the systems capability does not take a second path to the same wallet state.

Which runner or indexer replica owns a given piece of durable work is decided by PostgreSQL rather than by agreement between replicas. Each owning replica holds its shards as session advisory locks on one reserved connection, so ownership ends exactly when the session ends and a crash needs no timer to resolve. The cost of that choice is that the reserved connection is the ownership: a lock operation that overruns its deadline gives up every shard on that replica at once. How much work that costs scales with the configured shard count, which is why the platform runs a count sized to its replicas rather than the engine default.

The Transaction Lifecycle Engine also owns the handoff between custody-provider evidence and platform transaction state. It records a provider rejection as a terminal outcome before entering an approval wait, and it adopts a confirmed provider transaction only after the missing hash is safely attached to the persisted transaction. This keeps retries, operator status, and Ledger Index tracking aligned with the external side effect that actually occurred.

When the Platform API or Ledger Index converts a value, the input includes its unit and supported decimal places. The Core Platform decodes that complete input before arithmetic, keeps the exact value immutable during calculation, and encodes it only for an API response, persistent record, or chain payload. A missing unit or unsupported precision fails the operation before a workflow or indexed write. Each conversion also names its rounding policy instead of relying on JavaScript floating-point arithmetic. This prevents values that share the same digits from being combined across assets, networks, or units.

The Platform API is also where an external system's failure becomes a platform failure. Identity-provider, compliance-provider, and custody-provider errors are translated at the API boundary into the platform's own error catalog, which assigns each condition a stable identifier, an HTTP status, a retryability verdict, and reviewed caller-facing text. Two consequences follow for a reviewer. Integrators code against the platform's catalog rather than a provider's error vocabulary, so a provider change does not become an integration change. And conditions a caller must not be able to distinguish, such as whether an organisation exists or whether the caller merely cannot see it, are deliberately mapped to one response, so the error surface does not become an oracle for state the caller is not entitled to read.

On-chain failures pass through the same catalog. When a SMART Protocol contract rejects an operation, such as an unfunded dividend schedule, a claim window that has not opened, or an interest treasury top-up against a paused schedule, the revert is translated into a catalogued platform error with the same stable identifier, status, and retryability verdict as any provider failure. The retryability verdict is the reviewer-relevant part: conditions that resolve with time or funding are marked retryable, while validation rejections are terminal, so an integrator's retry policy can key on the catalog instead of parsing revert data.

That same rule decides who may read an issuer's aggregate yield position. A dividend or interest yield instrument records per holder figures in the Ledger Index, and the Platform API can sum them into one issuer facing number: how much dividend is still claimable or has expired back to the treasury, and how much interest is pending as of an indexed moment. Those sums are the issuer's view of what it still owes, not a holder's, so the Platform API gates them on the token governance role rather than plain read access. A user who can attach and configure the feature sees the figure, a holder does not, and the Operations Console shows the same number behind the same permission the API enforces, so what the screen reveals and what the API allows cannot drift apart.

The two balance-based yield features also answer the same two trust questions the same way when a token combines yield with conversion: which feature may settle a holder's interest into a conversion (one governance-named consumer, set once) and which addresses earn nothing (a governance-managed list, correctable, that the platform fills with a Lock conversion escrow). Because interest yield and fixed treasury yield expose that surface under the same names and semantics, token creation wires either one through a single path, and the escrow rule is one platform policy rather than a per-feature exception.

How the Ledger Index is scaled follows from where reorganisations are possible. One replica owns each chain's live ingest, because the range near the chain tip can still change and only one writer can hold a coherent view of it. Settled history cannot change, so it is divided into leased ranges that every indexer replica claims and processes. Rebuilding the read model is therefore work for the indexer pool, while following the tip stays with a single owner per chain. The chain owner also carries the recurring maintenance for its chain: it folds recorded movements into their running totals up to the point where the chain can no longer reorganise, and it prunes the bookkeeping rows that finality and a fixed retention window make unreachable. Reads stay correct at any maintenance cadence, because every read sums the movements that are not yet folded; the maintenance bounds how much unfolded history each read must sum.

The Ledger Index owns one further responsibility that shapes what the platform can answer quickly. Derived measures such as value over time are recorded as the events that cause them arrive, rather than recomputed from full history each time they are read. That keeps historical queries bounded by the period requested instead of by the platform's age, and it makes those measures part of the indexed read model that a release can require to be rebuilt. How often those recorded movements are folded into the history read model is a deployment setting: a drain interval and a per-pass row ceiling. An operator tunes history freshness against database load without changing what is recorded.

The same rebuild is what decides how the Ledger Index treats work that depends on indexed state without belonging to any one chain, such as classifying each organisation's operator and bundler wallets. A rebuild empties the read model and refills it over time, so that work is owned by a cluster-wide pass that repeats and converges instead of a step that runs once at start. What it cannot resolve yet, it resolves on a later pass.

Six points matter in most reviews:

1. DALP is EVM-focused. It does not make non-EVM chains native DALP execution environments.
2. Product systems separate responsibilities, and the backend runs one explicit API, runner, or indexer role per process. API pods serve requests, runner pods own workflows and schedules, and indexer pods own chain ingestion. One daily runner owner removes settled webhook receipt, delivery, and event audit rows after 30 days in bounded, skip-locked batches; pending, provisional, active replay, and test rows remain outside that policy. Each role tolerates dependency loss during its boot window through duration-bounded in-process relaunches before its health port first binds; after first bind it fails fast and the platform restarts the pod.
3. DALP keeps workflow authorisation, transaction signing, and on-chain compliance as separate control boundaries rather than treating any one boundary as the whole control plane.
4. DALP stores operational data off chain for workflow and review, while asset ownership and rule enforcement live in smart contracts on your selected EVM network.
5. Backend scaling is constrained by an explicit PostgreSQL connection budget. Every role connects to PostgreSQL directly, but the client-only API role costs fewer connections than the shard-owning runner and indexer roles. A release gate prices each role, including rollout overlap, inside the database connection limit, so no intermediate connection pooler is deployed.
6. Shard and chain ownership is held by a PostgreSQL advisory lock rather than an expiring lease, so exclusion is enforced by the database and never by a clock. A partitioned replica therefore stalls the work it owns instead of that work being taken from it while it may still be running. Availability of ownership is improved by detecting dead peers sooner, never by allowing two owners.

How to read the architecture in a review

Start with the system that owns the decision you are checking. A request enters through the Operations Console or the Platform API and moves through the Transaction Lifecycle Engine. The Workflow Engine gates each transfer through the Compliance Engine, which reaches your compliance and KYC providers where configured. It signs through Key Management under custody-provider policy, prices with Market Data feeds, and broadcasts through your EVM RPC provider to the SMART Protocol contracts in the Asset Registry. The Ledger Index turns emitted events into the read model the Platform API serves, and Event Delivery streams confirmations and webhooks to downstream consumers. The Core Platform carries the data platform, observability, document storage, and shared libraries under all of it.

Use that flow to make procurement and security reviews concrete:

What runs inside DALP

Control responsibilities

DALP checks each request through a series of gates before it proceeds.

The authentication system owns one organization and role lookup for both interactive sessions and API credentials. This keeps revocation, membership, and failure behavior aligned across the Platform API.

One reporting rule sits underneath all of these gates: a condition the platform detects is reported on a channel that can be queried. Backend services log as structured JSON, and warnings raised through Bun's Node-compatible process API are republished into that same stream under the dapi.process category instead of being left as unparsed stderr text. An auditor can therefore treat absence of evidence in the log stream as evidence, which is not true of a runtime that lets some of its own diagnostics bypass the logger.

These gates share one resolution of the caller's situation rather than each working it out separately. Within a single request, the organisation, network, system, identity registry, and trusted-issuers registry are resolved once and then read by every gate that needs them. That matters for review: it means two checks in the same request cannot answer against different systems because an administrator changed a network or redeployed a system while the request was in flight. The two negative outcomes stay distinguishable: a system that is not active on the requested network reports no registries, and every gate treats that as a refusal, while a failed lookup is reported as a retryable platform error rather than being presented as an absent system.

This split matters when you review as an auditor:

• Authentication proves who is calling, and whether that interactive session has enrolled login two-factor authentication when the deployment requires it.
• Credential verification is a separate control from IP rate limiting. Login second-factor verify and wallet signing confirmation share one failure budget keyed by account id. The authentication package owns admission, failure, and success transitions for that budget; active lockouts are never dropped to reclaim in-process map slots. IP-scoped rate limits and durable account lockout remain complementary across replicas. Refusals carry remaining-attempt or cool-down fields instead of a generic forbidden outcome.
• Console identity changes (sign-out, organisation switch, acting-as) clear identity-bound client cache before the next paint so a later session cannot read the prior identity's responses from colliding query keys.
• Authorization decides whether the caller may perform the requested operation, including privileged configuration reads that the Console also hides.
• Signing policy decides whether a transaction can be signed.
• SMART Protocol contracts decide whether a state change is valid on chain.
• The error catalog decides what a rejected caller is told, and what stays undisclosed.

System discovery is organization-owned, not a chain-wide catalog

Reading or listing systems through the Platform API answers for the caller's active organization on the selected network. The platform resolves the organization's system mapping for that network, then serves only that system. Naming another organization's system address returns the same not-found outcome as an unknown address, so the response cannot be used to probe which systems exist. While a deployment is still pending or deploying, network readiness errors surface as typed client refusals rather than an empty list that looks like true absence. Callers without an organization can still read the pre-onboarding default shape so the Console can render before the first organization exists.

List and read share that ownership rule for both the frozen and versioned surfaces, and both honor the network selected by the request. Continue to Authentication and Authorization.

The network an organization starts on is a choice, and the platform bounds it

The first system an organization deploys no longer has to land on the platform default network. Onboarding asks which network to use, and the platform answers that question before the organization exists. The read is therefore authorized by the session alone, not by an organization membership.

The offered set is smaller than the catalog on purpose. A network is offered only when it is enabled, resolves to a chain, and that chain already carries a bootstrapped system factory. One entry is offered per chain, even when the catalog knows that chain under several names. A platform-wide switch turns the choice off entirely, which collapses the offer to the default network and leaves onboarding behaving exactly as it did before the choice existed.

A network that cannot host a system is never offered, and it is also never accepted. The deploy applies the same test the offer applied, so a bad choice is refused before onboarding starts rather than leaving a person with an organization that can never finish. An empty offer is a truthful answer rather than a failure, and the Console shows it as one.

Which networks the platform serves is not only a deploy-time decision

The set of EVM networks DALP serves comes from two places, and both are part of the control surface. The deployed configuration declares a baseline set. A platform administrator can then register, change, or remove a network at runtime through the Platform API, without a redeploy. The runtime registry is an overlay on the baseline, not a replacement for it: removing a registry entry that shadows a configured network restores the configured one, while removing an entry for a network the configuration never declared takes that network away.

Two rules bound what an administrator may do, and they are what a reviewer should check. The default network is a configuration decision and can never be set by a runtime write. And a write is refused when it would leave a chain that organisation systems are still deployed on with no enabled network. The platform will not strand live systems to satisfy a catalog edit. Both refusals are reported as specific client errors naming the network at fault, not as generic failures.

A network's RPC endpoints are edited through their own API call, but they are not an independent decision: endpoints are probed against one chain, and the network they belong to can be moved or removed while that probing runs. Both edits therefore take the same database lock and run one at a time, and the endpoint write re-checks the network against the catalog after it gets the lock. An administrator who loses that race is told the network is gone or has changed chain, and writes nothing. The alternative is silent: endpoints reappearing for a network that was just removed, or endpoints kept for a chain the network no longer runs on.

Those saved pools also drive live RPC routing for indexing and for the Platform API. An administrator who rotates credentials or replaces endpoints sees the change take effect on both paths after a successful save. Endpoint URLs must not embed credentials, a query string, or a fragment. Secrets belong in the encrypted auth field.

The list surface reports where each network came from, so "configured" and "registered at runtime" stay distinguishable in review. Continue to Deployment topology.

Which systems the index follows is a platform decision, not a chain fact

A chain can carry systems the platform has no reason to index, including systems another installation deployed against the same contracts. DALP therefore keeps a platform ledger of which systems the Ledger Index may follow, one row for each chain and system address it has seen announced. A system with no row counts as out of scope, so the gate is closed by default and an unknown system cannot reach a read model by accident.

Two writers fill that ledger, and a reviewer should keep them apart. The platform writes it for the systems it creates: an organization deployment puts its own new system in scope at the moment the address first exists, and a redeploy that replaces an address takes the replaced one out of scope in the same step. A platform administrator writes it for everything else, by turning a known system on or off. Ordinary organization members have no say in it, because scope is a platform-wide operating decision and not an organization setting.

The consequence to check in review is what a change does and does not move. Turning a system off leaves its indexed data in place and stops further indexing from the next processed range. Turning one on sends its full history through backfill, so the effort is proportional to how long the system has run, not to how long it was out of scope. Neither direction needs a restart or a reindex. Continue to Ledger Index.

An environment lives in exactly one directory world

Every deployed contract on a chain (systems, identity registries, identity factories) is reachable through a Directory contract. The platform configuration names exactly one Directory address per chain, and that address is the authority. A chain can hold several Directory generations at the same time, for example after a contract redeployment, and the index records each of them. Only the configured address answers the question "which Directory does this environment use".

A system the platform already holds keeps resolving through the Directory generation that created it. That system belongs to that generation. The platform needs the link to attribute the identities and assets the system holds.

The operating consequence is that a move to a Directory at a new address is a data migration, not a configuration edit. Two generations that serve one chain is an alertable condition. The deploy path also refuses to create a replacement system when a stored system address is one the index cannot confirm.

Closing an account does not erase compliance history or strand live control

Self-service account deletion is available on the Platform API authentication surface, and it is gated. The caller must confirm by email while signed in. The platform refuses the delete when the account is the last owner of an organisation, when an on-chain identity is still bound to the person, or when indexed token holdings remain. Those ownership and identity checks are enforced again at the database boundary so concurrent deletes cannot leave an organisation ownerless or leave a live identity without a user.

Hard delete retires active wallets and the live KYC profile. It keeps the participant anchor and the KYC version and document history that regulators and reviewers need. After deletion, privileged review is organisation-scoped: only an on-chain accepted registration in that organisation's identity registry, or documents stored for that organisation, authorize access. A pending or rejected registration request is not enough. Continue to Identity and compliance.

Deployment responsibilities

DALP can run in managed, customer-hosted, hybrid, private-chain, and restricted-network patterns depending on the operating model. The division is consistent across patterns: DALP services operate the eight systems in the diagram. The selected EVM network, custody provider, RPC service, identity sources, pricing sources, payment rails, and operational approvals remain explicit dependencies.

For hosting, networking, high availability, backup, recovery, or restricted-network detail, continue to Deployment topology and Operability for your context.

Reader paths

What this page does not claim

DALP does not make every external system part of its native platform control. Custody-provider quorum rules, bridge design, liquidity venues, payment rails, source data methodology, public-network validator behaviour, non-EVM execution environments, and physical-asset reserve attestations each need their own review. DALP integrates with selected external systems where configured, but that integration is not the same as native platform control.