# Platform capabilities

Source: https://docs.settlemint.com/docs/business/executive-overview/dalp-overview
DALP combines issuance, compliance, custody controls, settlement, servicing, exception handling, and operating evidence in one platform for regulated digital asset operations after launch.



## Key terms [#key-terms]

* **[DALP](/docs/business/executive-overview/glossary#dalp)** – Digital Asset Lifecycle Platform,
  SettleMint's production DALP implementation
* **[ERC-3643](/docs/business/executive-overview/glossary#erc-3643)** – Token standard
  for permissioned securities with embedded compliance
* **[SMART Protocol](/docs/business/executive-overview/glossary#smart-protocol)** –
  SettleMint Adaptable Regulated Token protocol providing unified compliance
* **[Multi-signature wallet](/docs/business/executive-overview/glossary#multi-signature-wallet)**
  – Wallet requiring multiple approvals for transactions

## What the digital asset lifecycle platform is [#what-the-digital-asset-lifecycle-platform-is]

The SettleMint Digital Asset Lifecycle Platform (DALP) is working software for
regulated digital asset operations after launch. Institutions use it to create
assets, enforce compliance, control approvals, coordinate settlement, service
assets, handle exceptions, and retain operating evidence through the asset
lifecycle.

Issuance is only the starting point. DALP provides the controls institutions need
once an asset is live: compliance checks before transfers execute, role-based
operations, custody-aware approval flows, settlement handling, servicing actions,
emergency controls, and audit-ready records in one integrated platform.

The full-stack includes smart contracts implementing compliance-aware tokens, a
modern web application for issuers, administrators, and investors, backend APIs
and services for integration, blockchain indexing for real-time ownership
registries, database schemas for off-chain data, deployment infrastructure for
production operations, and developer documentation and SDKs for customization.

The platform is opinionated about architecture, unified lifecycle management with
embedded compliance, but flexible about deployment. Run it on-premises, in your
cloud infrastructure, or as dedicated SaaS. Deploy to Ethereum, Polygon,
Hyperledger Besu, Quorum, or any EVM-compatible network. Customize the user
interface, integrate with your systems, and extend the smart contracts for
asset-specific requirements.

## Product and delivery responsibilities [#product-and-delivery-responsibilities]

DALP is the licensed product surface for the asset lifecycle: contracts, console,
APIs, workflow execution, indexing, reporting, and the documented integration
points around custody, compliance, network access, and monitoring. Implementation
and support services help deploy, configure, integrate, and operate that product
inside the client's chosen environment.

| Responsibility area    | DALP product provides                                                                                                     | Client, partner, or delivery team decides                                                           |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Asset lifecycle        | Asset factories, compliance-aware token contracts, servicing actions, settlement workflows, and indexed operating records | Asset terms, business approvals, role assignment, and operating procedures                          |
| Deployment model       | Supported platform components for on-premises, client-cloud, or dedicated SaaS deployment                                 | Hosting choice, environment controls, network access, backup policy, and internal change management |
| Integrations           | API and workflow surfaces for custody, compliance providers, EVM RPC access, observability, and downstream systems        | Provider selection, contract terms, operating runbooks, credential governance, and escalation model |
| Compliance controls    | Technical enforcement points, identity-bound checks, module configuration surfaces, and audit evidence                    | Legal interpretation, regulatory sign-off, policy ownership, and exception approval                 |
| Support and operations | Product documentation, platform health surfaces, failure-mode guidance, and supportable integration patterns              | Internal incident command, evidence-pack assembly, retention policy, and production support model   |

Use this split when evaluating DALP. A feature in the product can still require
implementation work to configure it for a specific institution, provider, network,
or operating policy. That implementation work does not turn the product capability
into a roadmap item, and the product docs should not imply that DALP replaces the
client's legal, custody, network, privacy, or support obligations.

### Out-of-box product scope versus implementation scope [#out-of-box-product-scope-versus-implementation-scope]

DALP provides the product primitives for regulated EVM asset operations. A buyer
should separate those product primitives from the configuration, integration, and
operating decisions required for a production deployment.

| Evaluation question                                  | Treat as DALP product scope                                                                                   | Treat as implementation or operating scope                                                                                         |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Can the platform issue and operate regulated assets? | Asset factories, compliance-aware token contracts, lifecycle actions, role-controlled operations, and records | Asset terms, programme approvals, legal documentation, and issuer operating procedures                                             |
| Can compliance rules be enforced technically?        | Identity claims, trusted issuers, compliance modules, transfer checks, and audit evidence                     | Legal interpretation, jurisdiction-specific policy, provider contracts, manual exception approval, and ongoing regulatory sign-off |
| Can external systems connect to DALP?                | APIs, SDKs, integration patterns, supported provider surfaces, event data, and deployment interfaces          | Provider selection, credential governance, network allowlists, downstream reconciliation, and customer-specific adapters           |
| Can DALP run in the target environment?              | Supported platform components for managed, dedicated, customer-cloud, or on-premises deployment patterns      | Cloud controls, data residency stance, backup policy, monitoring stack, support model, and incident command                        |
| Can the user interface match an institution's brand? | Asset Console branding controls and documented customisation points                                           | Institution-specific copy, approval of visual identity, customer portal decisions, and custom workflows outside the product        |

This distinction gives evaluators a practical rule: if DALP exposes the contract,
API, console workflow, configuration surface, or operating record, treat it as
product capability. If the requirement depends on a particular legal opinion,
provider contract, bank ledger, custody arrangement, customer portal, or support
process, treat it as implementation or operating scope around the product.

For the detailed responsibility map, read the [architecture overview](/docs/architects/architecture/overview). For runtime
placement and hosting responsibilities, read [deployment topology](/docs/architects/architecture/overview/deployment-topology)
and [self-hosting prerequisites](/docs/architects/architecture/self-hosting/prerequisites). For asset-specific operating
responsibilities, read the [use cases overview](/docs/business/executive-overview/use-cases).

![Cross-asset insights summarize platform value across all deployed asset classes.](/docs/screenshots/asset-designer/asset-insights.webp)

## Key features and capabilities [#key-features-and-capabilities]

### Regulated operations after launch [#regulated-operations-after-launch]

DALP is designed for the operational phase that begins after an asset is issued.
That phase includes transfer approvals, custody-policy boundaries, settlement
coordination, servicing events, exception handling, emergency controls,
production monitoring, and audit evidence. These controls sit in the same
platform as asset configuration and compliance, so operations teams do not have
to reconcile separate systems to understand what happened.

For regulated institutions, this matters because most operating risk appears
after the first asset goes live. The questions are practical: who can approve a
transfer, which compliance rule blocked it, whether every settlement leg was
approved, how an expired settlement is withdrawn, which emergency role paused an
asset, and what evidence remains for compliance and audit review. DALP treats
those as platform workflows, not manual back-office work.

### Complete lifecycle management [#complete-lifecycle-management]

DALP combines issuance, compliance checks, custody-aware approvals, settlement,
servicing, and evidence records in one lifecycle model. These capabilities share
one platform context instead of forcing operators to treat every phase as a
separate tool:

<Mermaid
  chart="`flowchart TB
  Issuance(Issuance<br/>Factory deployment<br/>Compliance setup)
  Compliance(Compliance<br/>KYC/AML verification<br/>Transfer rules)
  Custody(Custody<br/>Multi-sig vaults<br/>Role-based access)
  Settlement(Settlement<br/>DvP atomic swaps<br/>XvP multi-party)
  Servicing(Servicing<br/>Yield schedules<br/>Corporate actions)
  
  Issuance --> Compliance
  Compliance --> Custody
  Custody --> Settlement
  Settlement --> Servicing
  Servicing -.->|Ongoing| Compliance
  
  style Issuance fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style Compliance fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style Custody fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style Settlement fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style Servicing fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
`"
/>

**The asset lifecycle flows through five integrated phases**: Issuance creates
the token with embedded compliance from deployment. Compliance enforces rules at
every transfer, validating identity claims and regulatory requirements. Custody
secures assets in multi-signature vaults with maker-checker workflows.
Settlement executes local token transfers together or reverts them together.
Servicing automates yield calculations, dividend distributions, and redemptions.
Each phase references the same control plane, while external cash, custody,
market, and ledger systems still need their own reconciliation evidence.

**Delivery versus Payment (DvP)**: DALP's XvP settlement capability coordinates
multi-party token exchanges with all-or-nothing execution for local flows. Each
local sender approves the settlement and provides allowance before execution. If
a local token transfer fails, the settlement transaction reverts. External cash,
bridge, custody, or payment legs remain the responsibility of the connected
workflow, so operators still reconcile those legs against the DALP settlement
record.

**Custody-aware approvals**: DALP supports multi-signature custody patterns with
role-based access control. Configured quorum requirements prevent one operator
from moving assets alone. Maker-checker workflows separate proposal, approval,
and execution steps, while emergency pause controls give authorised roles a way
to stop activity during an incident. Operating records track proposals,
approvals, and executions.

**Scheduled servicing**: Fixed-yield and servicing features can calculate
dividend, interest, coupon, and redemption entitlements when the asset is
configured for those actions. The platform records the servicing workflow, while
external payment rails, accounting systems, and issuer procedures remain
responsible for cash movement and reconciliation evidence outside DALP.

These capabilities give operators one lifecycle view across settlement,
custody-aware approval, and servicing activity. DALP records the platform-side
state for each workflow without removing the need to reconcile connected cash,
custody, market, and ledger systems.

### Multi-asset support from day one [#multi-asset-support-from-day-one]

DALP ships a template library across six asset classes: fixed income, equity,
funds, cash, real assets, and structured instruments. Operators can start from a
system product template, duplicate it for an organisation-specific pattern, or
use the Configurable Asset starter when the product does not fit a library
template.

| Asset class            | Example library templates                                                                                            | What DALP standardises                                                                                                 |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Fixed income           | Corporate bonds, sovereign bonds, convertible notes, syndicated loans, treasury bills, green bonds, commercial paper | Maturity dates, yield or coupon configuration, denomination assets, redemption mechanics, and compliance controls      |
| Equity                 | Common equity, preferred equity, employee equity awards                                                              | Share class setup, holder controls, voting or historical-balance features when configured, and cap-table style records |
| Funds                  | Mutual funds, ETFs, money market funds, private equity funds                                                         | NAV-related fields, fund category metadata, subscription or redemption setup, and holder registry controls             |
| Cash                   | Fiat-backed stablecoins, tokenized bank deposits, certificates of deposit                                            | Controlled minting and burning, deposit or term metadata, and issuer-owned reserve or backing evidence outside DALP    |
| Real assets            | Gold-backed tokens, commercial real estate, carbon credits, tokenized art                                            | Asset-specific metadata, valuation fields, holder controls, and lifecycle evidence for externally managed assets       |
| Structured instruments | Principal-protected notes, autocallable notes, asset-backed tokens                                                   | Product terms, payoff or maturity metadata, required token features, and operator review before issuance               |

The template library is a starting point, not a legal wrapper. A template can
attach token features, metadata fields, defaults, and required inputs to the
Asset Designer. The issuer still owns the economic terms, legal classification,
external reserve evidence, investor disclosures, and operating procedure for the
asset programme.

Each issued asset uses DALP's shared lifecycle controls where those controls are
configured for that asset: compliance checks before transfer execution,
role-based administration, custody-aware signing or approval flows, settlement
coordination, metadata records, and indexed operating evidence. The common
platform model is what lets different asset products use the same control plane
without pretending they have the same economics.

![Bond issuance and lifecycle servicing on a unified asset management console.](/docs/screenshots/bonds/bonds-listing.webp)

### Regulatory compliance embedded in the architecture [#regulatory-compliance-embedded-in-the-architecture]

Compliance isn't a dashboard feature you turn on after deploying tokens. It's in
the token's DNA through the ERC-3643 standard implementation.

The Identity Registry maintains verified investor profiles with KYC/AML status,
accreditation levels, and jurisdictional eligibility. An investor completes
verification once, and their identity travels with them across all assets
they're eligible to hold.

The Compliance Engine evaluates every transfer before execution, checking
whether the sender is verified, whether the recipient meets eligibility
requirements, whether the transfer violates holding limits or lockup periods,
and whether jurisdictional rules permit the transaction. Non-compliant transfers
revert with clear reason codes explaining why.

The Rule Library provides a configurable framework for jurisdiction-specific
compliance. The platform supports templates for Regulation D and Regulation S
(US), MiFID II and MiCA (Europe), MAS frameworks (Singapore), and FCA
requirements (UK). Compliance officers configure rules through UI controls
rather than writing smart contract code.

The Audit Trail captures every decision: which rules were evaluated, which
identity claims were verified, which administrators approved exceptions, with
immutable timestamps and cryptographic proof. Regulators get machine-readable
evidence, not manually compiled spreadsheets.

### Multi-layer security and custody [#multi-layer-security-and-custody]

Multi-signature wallets require configurable quorum approval for treasury
operations. No single person can move assets unilaterally. The platform enforces
maker-checker workflows where one admin proposes a transaction and others
approve before execution.

Custody-aware signing routes let institutions delegate signing and transaction
broadcasting to configured providers instead of relying on a single application
hot wallet. Current DALP integrations cover Fireblocks and DFNS provider-native
broadcasting, approval polling, and signer operations.

Role-Based Access Control (RBAC) defines who can perform which operations: token
creation, compliance approval, treasury transactions, administrative settings.
Permissions map to organizational hierarchies with proper segregation of duties.

Institutions can use those provider-side policy controls while DALP coordinates
asset lifecycle workflows, transaction state, and confirmation tracking in the
platform.

The platform assumes keys will be stolen, employees will make mistakes, and
external attacks will occur. Security is defense in depth: multiple layers that
must all fail before assets are at risk.

![Equity issuance and lifecycle management using the same DALP control plane.](/docs/screenshots/equity/equity-listing.webp)

### Modern user experience across personas [#modern-user-experience-across-personas]

DALP exposes different working surfaces for different operators. The boundary is simple: the browser experience helps people configure, approve, and inspect asset operations, while the API and CLI help technical teams automate the same operating model.

| Surface                          | Primary user                                       | What they use it for                                                                                                        | Where to go next                                                                                       |
| -------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Asset Console                    | Issuers and operations teams                       | Create assets, configure templates, review asset state, run permitted lifecycle actions, and inspect holder or event views. | [Create asset](/docs/operators/user-guides/asset-creation/create-asset)                                |
| Compliance workspace             | Compliance officers and provider operators         | Manage verification data, trusted issuers, compliance templates, provider setup, and compliance-related operating evidence. | [Compliance overview](/docs/operators/user-guides/compliance/overview)                                 |
| Admin and organization settings  | Organization administrators                        | Manage organization setup, users, wallets, permissions, and operating checks before sensitive actions.                      | [Admin operating model](/docs/developers/developer-guides/platform-setup/admin-operating-model)        |
| Developer documentation and APIs | Integration engineers                              | Use REST APIs, generated clients, CLI commands, webhooks, and transaction tracking for system integrations.                 | [API integration guides](/docs/developers/developer-guides/api-integration)                            |
| Read and evidence surfaces       | Auditors, reviewers, and support teams with access | Review indexed events, transaction status, reports, exports, and asset records for each allowed program.                    | [Reporting and audit access](/docs/developers/developer-guides/api-integration/reporting-audit-access) |

Deploy to testnet first, validate behavior, then repeat the validated operating model on the production EVM network. Testnet transactions, balances, identity registry entries, compliance module state, transaction hashes, confirmations, and indexed history do not become production state. See [Promote from testnet to mainnet](/docs/developers/developer-guides/operations/testnet-mainnet-promotion) for the operational checklist.

The Asset Console theme system lets operators align the browser experience with their institutional brand while keeping product workflows unchanged. Detailed branding controls are covered in the [Asset Console customization guidance](/docs/architects/architecture/components/platform/asset-console#customization).

### Scalable architecture for production workloads [#scalable-architecture-for-production-workloads]

The platform uses modern microservices architecture with independent scaling for
each component. The web application, API server, blockchain indexer, and
database tier scale independently based on load.

TanStack-based frontend provides instant navigation and optimistic updates.
Users don't wait for blockchain confirmations to see UI updates; the interface
predicts outcomes and updates immediately while settlement completes in the
background.

Drizzle ORM with PostgreSQL manages off-chain data with strong consistency
guarantees. DALP's native indexer keeps blockchain events queryable within
seconds of on-chain finality.

Redis caching accelerates frequent queries. Expensive operations get cached
aggressively so dashboards load instantly even with thousands of assets and tens
of thousands of holders.

Kubernetes deployment via Helm charts enables cloud-native operations with
autoscaling, rolling updates, health monitoring, and self-healing. Deploy to any
Kubernetes environment: public cloud, private cloud, or on-premises.

### Deployable observability stack [#deployable-observability-stack]

DALP provides a Helm observability chart for deployments that enable and
configure the stack. The chart can deploy VictoriaMetrics for metrics, Loki for
logs, Tempo for traces, and Grafana dashboard configuration for common
self-hosted operations.

When the observability chart and relevant exporters are enabled, dashboards can
show what operations teams need:

* Transaction throughput and success rates
* Compliance check performance and failure reasons
* System availability and response times
* Asset-level activity and holder statistics

Alert notifications and routing depend on the deployment's notification
configuration. Operators can troubleshoot issues by viewing correlated system
behavior across enabled telemetry sources in one interface.

**Cost advantage**: Using deployable open-source telemetry components can reduce
the need for separate monitoring SaaS contracts for common operational views,
while enterprise integrations and retention policies remain deployment choices.

<Callout type="default" title="For technical readers">
  DALP's optional observability chart includes VictoriaMetrics, Loki, Tempo, and Grafana. See [Observability
  Architecture](/docs/architects/architecture/operability/observability) for the deployment boundary, retention configuration, and
  custom dashboard creation.
</Callout>

### Banking and payment integration [#banking-and-payment-integration]

The platform supports treasury workflows where operators verify fiat deposit
evidence, process tokenized-cash issuance, and coordinate redemptions with the
off-chain payment systems their institution uses. DALP records the on-chain
asset movement and settlement state; payment-file generation and banking-network
connectivity remain integration responsibilities unless a deployment connects
those systems explicitly.

Multi-currency support handles assets denominated in different fiat currencies
with proper tracking. The same platform manages USD bonds, EUR stablecoins, and
SGD deposit certificates without requiring separate deployments.

Payment versus Payment (PvP) settlement coordinates multi-leg transactions where
one token exchanges for another token, with atomicity guarantees ensuring both
legs complete or both revert.

## How DALP delivers value [#how-dalp-delivers-value]

DALP is organized around core business functions rather than technical
components:

**User-facing applications** provide role-specific interfaces:

* Issuer Portal for creating and managing tokenized assets
* Investor Portal for viewing holdings and claiming distributions
* Admin Console for compliance officers and operations teams
* Developer Portal for technical integrations

**Business logic layer** coordinates workflows:

* Asset lifecycle orchestration from issuance through redemption
* Compliance verification before every transaction
* Integration with banking systems, KYC providers, and custody services

**Record-keeping infrastructure** maintains authoritative data:

* Immutable ownership ledger (blockchain-based)
* Fast-access transaction history and reporting database
* Real-time indexing for instant portfolio views

**External system connections** enable end-to-end workflows:

* Banking rails for fiat on/off ramps
* KYC/AML providers for identity verification
* Custody services for HSM-backed key management with insurance and regulatory compliance
* Document storage for offering materials and legal files

The platform is architected so every component contributes to one or more
business outcomes: faster issuance, lower operational costs, regulatory
compliance confidence, or better investor experience.

<Callout type="default" title="For technical architects">
  See the [Platform Overview](/docs/architects/architecture/overview) documentation for detailed component diagrams, API
  specifications, smart contract interfaces, and deployment topology options.
</Callout>

## Benefits and tangible outcomes [#benefits-and-tangible-outcomes]

**Faster time to market**: Issuers go from term sheet to live token in days
instead of months. Templates handle compliance structure, factory contracts
deploy tokens automatically, and the platform eliminates most custom
development.

**Reduced operational overhead**: Corporate actions that took teams of people
and multiple days execute with minimal manual work. Dividend entitlements,
coupon calculations, NAV updates, and redemptions happen programmatically
without manual spreadsheet work or reconciliation. Token holders claim their
distributions on-demand.

**Compliance confidence**: Non-compliant transactions don't execute because
eligibility checks happen before execution. Regulators see a platform
architected for control. Risk committees approve deployments faster when the
architecture demonstrates proper controls.

**Better investor experience**: Real-time holdings visibility, instant
settlement, on-demand yield claiming, and transparent audit trails replace
quarterly statements and opaque processes. Investor support tickets drop because
the platform provides self-service transparency.

**Lower total cost of ownership**: One platform replacing multiple vendors means
one contract to negotiate, one security review, one integration project, one
support relationship. Procurement cycles shrink from months to weeks.

## Who's using DALP and for what [#whos-using-dalp-and-for-what]

Production deployments span multiple use cases. Asset managers tokenize private
fund units to automate administration and enable secondary trading. Banks issue
deposit certificates as programmable tokens with automated maturity processing.
Corporations explore tokenized bonds for direct-to-investor capital raising with
embedded compliance.

Geography matters less than regulatory clarity. European institutions leveraging
MiCA frameworks, Singapore financial institutions under MAS oversight, and Gulf
Cooperation Council markets with clear tokenization guidelines are moving
fastest. The US market is more cautious but accelerating as regulatory
frameworks solidify.

Scale varies from pilot programs managing tens of millions to institutional
deployments handling hundreds of millions in tokenized assets. The platform
architecture supports both with the same codebase and operational model.

## What this means for your organization [#what-this-means-for-your-organization]

If you're exploring tokenization, DALP provides a complete platform rather than
forcing you to become a systems integrator. If you're already running a pilot on
separate vendor systems, DALP offers a migration path to unified lifecycle
management with embedded compliance.

If you're a developer, DALP gives you modern APIs, comprehensive documentation,
and working reference implementations. If you're an operator, DALP provides
purpose-built tools for daily workflows rather than generic blockchain
explorers.

If you're a risk officer, DALP demonstrates defense-in-depth security with audit
trails that regulatory frameworks require. If you're a compliance officer, DALP
embeds policy into the enforcement path rather than relying on post-transaction
checks to catch violations.

The platform is specifically architected for regulated financial instruments
with institutional requirements. If you're tokenizing securities, funds, bonds,
or deposits with real compliance obligations, DALP implements what you need.

## Where to next [#where-to-next]

* **[Use cases](/docs/business/executive-overview/use-cases)** – Real-world scenarios
  across asset classes
* **[Compliance & security](/docs/business/executive-overview/compliance-security)** –
  Regulatory and security architecture details
* **[Glossary](/docs/business/executive-overview/glossary)** – Key terms and definitions
