Platform Architecture
Platform Architecture is how DALP divides one platform into named systems: what each owns, what crosses its boundary, and where reversibility ends.
Console and the Platform API both hand a request to the Transaction Lifecycle Engine, which calls Asset Registry, Compliance and Identity, and Custody and Settlement to make its decision. What settles becomes part of Ledger Data, alongside Market Data's pricing feed. Core Platform underlies every system shown.
The Transaction Lifecycle Engine orchestrates accepted on-chain writes; rules, keys, and history each stay with their own authoritative system.
Acceptance does not prove completion. Before broadcast, cancellation depends on the request's state; after broadcast, the network decides which transaction confirms.
Compliance rules live inside the asset itself and run at the moment value would move, not as a check layered on afterward.
Deciding what to build, integrate, or run
Platform Architecture is how DALP divides itself into named systems with distinct responsibility, so you can integrate against exactly the boundary you need. Knowing where each boundary sits tells you what you can safely integrate against, what you would need to operate yourself, and which decisions the platform already makes for you.
Two of those systems are the ones you touch. Console is the single surface an operator runs the platform through; the Platform API is the single surface an integrator builds against. Everything else sits behind those two surfaces. Write orchestration lives in the Transaction Lifecycle Engine, token rules in Asset Registry, and identity checks in Compliance and Identity. Signing lives in Custody and Settlement, the read model in Ledger Data, and the pricing feed in Market Data. You consume what they do through Console or the Platform API. You do not operate them directly unless you run a full DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept.
Start from the constraint that is hardest to move. A data-residency rule or a restriction on who may operate the infrastructure decides the path on its own, because no configuration makes an operated system private from its operator: that constraint forces a self-run DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept. Absent that constraint, integrating against the Platform API is the default: a product built on it never touches custody or indexing directly, and inherits their behavior instead of reimplementing it. Either way, the responsibility boundary decides what you own.
What changes day to day, and what does not
For day-to-day operation, Platform Architecture surfaces as one console and one backend, even though several named systems sit behind them. Console is the single surface for running the platform day to day. The Transaction Lifecycle Engine, the Platform API, and Ledger Data all run together inside one merged backend application. There is one process family to watch.
HTTP serving, durable workflows, and chain indexing share the backend process. They scale and restart together, while individual responsibilities can degrade independently. What stays visibly separate is what has to: the signing path inside Custody and Settlement, the ledger networks the platform follows, and outside providers such as market-data and identity-verification services. None of those live inside the merged backend, and none of them are DALP's to guarantee.
Console is one surface for a related reason, and it is assembled rather than written in one place. An operator works in several areas: asset design, participants, reporting, platform settings. Console modules contribute routes to one navigation tree. The available entries depend on deployment capabilities and the caller's permissions.
Day-to-day health is one rolled-up signal rather than a system-by-system checklist; see Platform HealthPlatform Health lets a platform admin see in one glance whether the platform is healthy right now, instead of checking a dozen dashboards.Read the concept for what that verdict covers and how it differs from a bare liveness check. Underneath all of it, Core Platform supplies the data, security, and observability foundation every other system relies on. Core Platform is not a separate thing an operator manages; its consistency is why the rest of the platform behaves predictably.
How a request becomes a settled fact
Platform Architecture fixes the sequence a request moves through. The Platform API checks and queues it, the Transaction Lifecycle Engine runs it as a durable, retryable execution that applies policy and selects a custody path, and only then does an instruction reach the ledger network it targets. Before broadcast, the request can wait for approval or funding. After broadcast, a transaction can remain pending, fail, or be replaced. Confirmation records execution, while the network's finality rules govern reorganisation risk. The figure shows those stages.
Everything through step 3 is the platform's own governed, retryable decision. After an instruction confirms, apply the network's finality rules; Ledger Data then indexes it and the platform returns a terminal Settlement Verdict.
Each system's responsibility follows from where it sits in that sequence. The Transaction Lifecycle Engine is authoritative for orchestration and ordering: it decides what runs next and durably remembers where a request stood, reusing recorded activity results after a restart. Unfinished activities can run again. Asset Registry is authoritative for the token's own rules; Compliance and Identity is authoritative for who may hold or receive; Custody and Settlement is authoritative for keys and signing. Ledger Data is authoritative for what already happened, not for what should happen next: it is a decoded, queryable copy of the chain, never a substitute for the ledger network itself. See Transaction LifecycleThe Transaction Lifecycle gives every write one auditable path to its outcome, so a same-key retry never leaves it unrecorded or runs it twice.Read the concept for the governed path a write follows in full and Ledger DataLedger Data lets an integration answer a holder list, a transfer history, or a compliance check with one query, instead of decoding chain events itself.Read the concept for how that read model stays current.
The on-chain and off-chain split follows the same line. On-chain is the asset's own rules and the transaction that moved value, both of which live on the ledger network and outlive the platform. Off-chain is everything the platform keeps to run itself: queued requests, workflow state, the indexed read model, audit records. All of it is durable, existing to make the on-chain record usable rather than to compete with it. Reconcile the recorded operation outcome with indexed activity and the network's finality rules. A chain reorganisation can revise the indexed view.
The surface you integrate with
For an integrator, Platform Architecture reduces to one surface: the Platform API, regardless of which internal system eventually does the work. It accepts a typed request over the SDK, the CLI, or direct HTTP, decodes and authenticates it, and returns either a Settlement Verdict or a status handle you can poll. A read comes back as a record the platform already decoded from the chain, not a live RPC call you would otherwise have to make and reconcile yourself.
A write can return synchronously, asynchronously as a status handle, or as a hybrid of the two. The synchronous path waits inside a bounded window you can shape with a request preference; pick it when the caller can block briefly and wants the verdict in the same response. Pick the status-handle path when the caller moves on immediately, or when a write might run longer than a caller should ever block for. All three are attachment choices on the same underlying execution: switching between them changes when you learn the outcome, never what the platform guarantees. At the queue boundary, a matching submission with the same idempotency key, sender, network, and wallet selection attaches to the existing transaction request inside its 24-hour window. An API route may perform other work before queue admission, so check its replay contract before repeating a request. Read a write's outcome from its Settlement VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept, never from acceptance, which only means the platform durably queued it.
Check completion and indexed visibility separately
A queued write that uses the indexer barrier waits for its block to become available to indexed reads. If that bounded wait expires, the error identifies the transaction and states that it succeeded on-chain while its indexed data is not ready. The platform also waits for the configured cache-invalidation interval where that delay applies. These waits serve different purposes; a confirmed transaction alone does not prove that every read is current.
External-token registration completes on-chain before historical backfill finishes. Its list entry reports that progress separately. An accepted status handle is also not a completed write: poll it for the operation outcome. Recheck the resource or indexing progress when your integration requires a specific transaction or historical range to be visible.
The Transaction Lifecycle Engine runs the durable execution behind a write. Ledger Data supplies the decoded records behind indexed reads. Use Platform Health and indexing progress to assess their operational state, alongside each request's outcome.
When a request stops short of the ledger
Platform Architecture also governs the requests that never reach the ledger network. When the chain declines an operation because the party paying for it is short of gas, that is not a decision the platform can make on the caller's behalf: someone has to send funds. The party short on gas is not always the caller's own wallet: it can be an EOA, a smart account, or a paymaster deposit, the shared infrastructure a sponsored transaction draws down instead of the caller's own balance. The platform records a durable funding requirement and pauses the operation. Funding the named subject lets it retry. Read the requirement record when a progress stream disconnects.
A caller who cannot act on a pause can opt out and receive GAS_REQUIRED immediately instead, on the same error contract as any other declined request, retryable once the named funding has been sent. Operators can list outstanding funding requirements for the organization in their session. The list excludes other organizations' requirements and does not depend on an open progress stream.
When a sponsorship window closes
Platform Architecture closes a second gate on gas-sponsored instructions, enforced by Custody and Settlement rather than the funding-subject flow above. A sponsored Smart WalletA Smart Wallet lets a tenant require several signers to agree before an instruction moves assets, with the rule enforced on chain, not by one private key.Read the concept instruction has a bounded authorization window. The platform checks chain time before broadcast and stops an expired authorization. An instruction stopped before broadcast records a failed outcome without an execution charge. Its original key continues to identify that failed request. Check the outcome before starting a new attempt with a fresh key.
The fixed values behind both gates:
| Gate | Constraint | Value |
|---|---|---|
| Funding subject short on gas | Pause before the operation fails | 24 hours on a profiled chain, 30 minutes with no profile |
| Funding subject short on gas | Live asks per funding subject | At most one, per chain |
| Sponsorship window | Authorization default | 1 hour from signing |
| Sponsorship window | Authorization cap | 2 hours from signing |
Where enforcement sits, and why there
Platform Architecture places compliance enforcement inside the asset's own on-chain contract, at the instant a transfer would move value, not as a check the platform's application code adds afterward. That placement is deliberate: it is the one point every path to a transfer must cross, no matter which system, integration, or direct chain call initiated it.
An application-layer check can be bypassed by any other route to the same contract; a rule written into the contract itself cannot. Compliance and Identity is authoritative for who may hold or receive, and the identity and claim verifications it manages travel with the token rather than living in a separate gate a caller could route around. See Compliance PolicyA Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.Read the concept for how those rules are configured and Transfer-Path ComplianceTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept for how the token enforces them at the moment of transfer.
Custody and Settlement is a separate boundary: it decides who may sign, not what rules a transfer must satisfy. A correctly authorized, properly signed transaction that violates a compliance rule still reverts on-chain. For evidence a reviewer can walk after the fact, Ledger Data holds the decoded record of what actually settled, and ReconciliationReconciliation lets your register stay the book of record while you prove it agrees with the platform's ledger, and know exactly when a gap needs a person.Read the concept is the discipline institutions run to confirm that record against their own books.
Frequently asked questions
Does upgrading a contract set break the addresses or ids an integration already calls?
No. A version upgrade repoints the same addon registry row, keyed by a fixed type identifier, to its new implementation; it does not register a second row under a new id. The component's own on-chain address, and the addresses of anything already deployed through it, do not change, so integrations retain the same addresses. Review changed behavior and interface compatibility before upgrading. See System Version for how DALP tracks that pointer per organization and what migrating actually changes.
What happens to an in-flight request if the platform restarts?
The Transaction Lifecycle Engine recovers from recorded execution state. Completed activity results can be reused; unfinished activity work can run again. Keep the original request identifier and idempotency key. Read the eventual outcome from the request's Settlement Verdict rather than assume acceptance meant it finished. While waiting, a retry from your own side attaches to the same request instead of starting a second one. The same idempotency guarantee applies to any resubmission.
What happens if a transaction fails or reverts after it is sent?
The Transaction Lifecycle Engine records the outcome as a Settlement Verdict: completed, failed, dead letter, or cancelled. A failure or revert after broadcast is one of those recorded end states, not a silent gap. Completed, failed, dead letter, and cancelled are terminal request states. Operators can requeue failed or dead-lettered requests. A completed application outcome does not remove chain reorganisation risk. See Settlement Verdict for what each state means and when it applies.
Can a transfer skip the platform and go straight to the token contract?
Yes, and the compliance rules still apply. The rules are written into the asset's own on-chain contract, so a transaction sent straight to the chain faces the same checks at the same point as one the platform orchestrated, and a non-compliant one reverts. What a direct call skips is everything the platform adds before broadcast: policy checks, custody selection, durable execution, and a recorded Settlement Verdict. What settles still appears in the read model, because Ledger Data decodes each followed block's events, not only the platform's own writes.