DALP Instance
A DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.
One instance inside a boundary you choose; everything outside it stays under your governance.
Each deployment path uses the same platform package. Enabled capabilities depend on the release, configuration, and connected services.
You choose where the platform stores its durable data. Review ledger, custody, identity-provider, and telemetry destinations against your residency and access policies.
Each instance connects to the approved EVM-compatible networks, public or private.
Why the deployment unit matters
A DALP Instance is the unit you deploy and run: one full copy of the tokenization platform, placed where your own rules demand. It does not split into a hosted core and satellite services. Each copy carries issuance, servicing, and reporting inside the same deployment boundary, wherever that boundary sits.
That matters because at regulated institutions, adoption fails on constraints before anyone reviews a feature. A platform that cannot run inside your perimeter, sign staff in through your corporate identity provider, and hand its audit evidence to your own monitoring fails the review that decides whether it runs at all. A DALP Instance answers those constraints by where it runs: you pick one of three paths, and configure the durable stores it uses. Records sent to external integrations or ledger networks also follow those systems' storage policies. The systems you connect it to stay under your own governance and receive only the traffic your configuration sends them.
The three paths differ on two things a deployment review actually tests: who holds the infrastructure, and who has to be able to reach the running system.
| Path | Choose it when | What it costs you |
|---|---|---|
| On premises | Policy or jurisdiction requires the hardware and the records to stay on premises under your own administrative control, and you have a platform team that already runs Kubernetes or OpenShift clusters. | Your team runs the cluster, applies every upgrade, and answers the alerts. Availability and recovery follow the setup you design, and your backups are what protect the off-chain records. |
| Your cloud account | A cloud account you approve is acceptable, and you would rather use managed database, storage, and multi-zone replication than run hardware for them. | The same operating duty as on premises, minus the hardware: your team still applies each upgrade and answers the alerts, and the provider's own availability model becomes part of yours. |
| Vendor-operated | You want upgrades and paging handled, or you have no platform team to run Kubernetes. | The vendor operates the cluster, and cluster access is data access rather than a smaller form of it, so this is the path to test against any policy that forbids the vendor reaching your records. Availability follows the vendor's service commitment rather than a design of your own. |
Start from the constraint that is hardest to move. A residency or vendor-access rule decides the path on its own, because no configuration makes an operated cluster private from its operator. Where no such rule binds, the question is whether you have the team: self-hosting gives you control over availability and upgrade timing and charges for it in operating work, and the vendor-run path trades the reverse. What none of the three trades away is isolation. Each instance has its own platform state and control plane. Shared infrastructure, network providers, or other external services can still affect multiple instances.
Approve each ledger network for the instance. A public EVM-compatible network uses its existing node governance. A private network lets you control who operates the nodes. Choose the network whose access and governance meet your deployment requirements.
Running an instance
Day to day, a DALP Instance is a short list of workloads on a Kubernetes or OpenShift cluster. One backend application hosts the Platform API, the Workflow Engine, 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, and it runs as one or more identical replicas. The web Console and a PostgreSQL data plane sit beside it, with object storage for documents and backups.
The runtime shape is identical across all three deployment paths; who runs each layer is what changes.
On self-hosted paths your platform team runs the cluster and applies each upgrade from the vendor's versioned releases. Promote the same release artifacts from test to production. Use release and instance attributes in telemetry to identify mixed versions during a rollout. A mismatch between parts is a defect, and it shows itself the same way: two parts of one copy reporting different versions in the same telemetry view. The fix is to finish rolling the new release out to the part still behind, or roll the ahead part back, until every part agrees again.
Every copy declares a stable, globally unique identity, stamped on every signal it exports. In the telemetry store you designate, that identity groups a whole fleet into one view, while each copy's dashboards show only itself. The identity has no default, so an install without one declared is refused. Two copies that do declare the same name are not refused: their signals merge into what the fleet view reads as one instance, and separating them again means renaming one copy's declared identity.
Recovery splits by data class: the platform can rebuild indexed chain state from the ledger, while off-chain records (approvals, identities, documents, workflow state) exist only in the copy's database, so your backups protect them.
The instance boundary
A DALP Instance draws one boundary around three zones: public access, the backend runtime, and durable data. Systems that you govern separately stay outside and connect in, including ledger nodes or remote procedure call endpoints, custody and signing, identity, outside data providers, and central telemetry.
Inside, the backend is one merged program with three faces that keep distinct duties. The Platform API authenticates callers, serves reads, and accepts writes. The Workflow Engine carries multi-step work across crashes and restarts. Ledger Data turns chain events into typed, queryable business data: holdings, transfers, balances. All three share one PostgreSQL data plane, the durable core: platform state, workflow journals, and indexed read models live there, and the replicas coordinate who owns which durable work through it. Every replica can serve all three faces.
Multi-tenancy lives inside the copy, and it has two layers. On chain, each organization operates its own set of contracts holding its registries and roles under its own rulebook, so one issuer's assets never mix with another's. Each copy also keeps a catalog of served networks, and different organizations on it can put their on-chain systems on different approved networks.
Off chain, tenant routes scope data to the authorized organization. Platform administration also has explicitly privileged cross-organization operations. Separate firms run separate copies, which share no state, no database, and no control plane. Isolation also depends on network rules, credentials, and external services. The ledger and separately governed systems keep their own state.
Organizations share one firm's copy and stay isolated on chain; a separate firm runs a separate copy that shares nothing.
The network list a copy serves has two writers: a baseline fixed when the platform is deployed, and entries a platform administrator registers at runtime. Adding a network therefore needs no redeploy, while the default network stays a change-controlled setting.
Frequently asked questions
Which of the three paths does a residency rule force?
Depends on what the rule requires. If policy or jurisdiction requires the hardware and the records to stay on premises under your own administrative control, that forces the on premises path. If a policy forbids the vendor's operations team from reaching your records, that rules out the vendor-operated path, leaving on premises or your cloud account. Neither rule picks a path by itself when it only requires a cloud account you approve, since your cloud account and on premises both keep records outside vendor reach.
Can we start on one path and move later?
Yes. The package is the same everywhere: the API surface, the software, and the records it holds do not change with a move. What changes is the operating split, who runs the cluster, applies upgrades, and answers the alerts. A later move redeploys the same package onto the new path, and the database and storage come with it. Your client code keeps targeting whichever copy's endpoint and credentials you configure, regardless of which of the three paths that copy runs on.
What leaves the boundary?
The integrations you configure, and nothing else the platform decides on its own: calls to the ledger networks you approve, to the custody and outside data providers you select, mail delivery, and telemetry to the store you designate. Each of those is a setting with an endpoint you supply, so leaving one unset leaves that traffic unsent. No shared control plane sits behind the copy either, so the platform has no vendor-side service to report to. Egress beyond those integrations is a matter for your own network controls rather than something the platform asserts about itself.
Does the environment label change how a copy behaves?
No. environment feeds one telemetry attribute, deployment.environment.name, and nothing else. Declaring a copy's environment tells your fleet view which one it is; the platform's behavior comes from the release image and the rest of its configuration, not from this field.
Where do the signing keys live?
Where your policy puts them. The platform signs through a path you configure: your own hardware security module, an external custodian, or an encrypted store the copy hosts. Review who can access each signing service and its administration. In an operated deployment, infrastructure access can include access to a platform-hosted encrypted key store.
Overview
Platform Architecture is how DALP divides one platform into named systems: what each owns, what crosses its boundary, and where reversibility ends.
EVM Contract Set
The EVM Contract Set is the identity, compliance, custody, and settlement contracts DALP deploys around one composable security token, checked in one call.