The Console and your own software send every on-chain write through the Transaction Lifecycle Engine to the EVM network, and Ledger Data indexes the result.
Eight named systems divide the work. Each system owns its own records, and all of them read the same indexed record in Ledger Data.
The compliance rules run inside the token's own transfer, so every path to an ordinary transfer meets the same check. A custodian's forced transfer and three other recorded paths skip some of these checks, and Transfer-path compliance lists all four.
A write succeeds when its settlement verdict, the outcome the platform records, is completed. Acceptance and broadcast are steps on the way.
DALP, the Digital Asset Lifecycle Platform, runs a regulated digital asset from its design to its final redemption on an EVM network, a public or permissioned blockchain that runs Ethereum-compatible contracts. It is built from eight named systems around one registry of assets, the Asset Registry.
The eight systems
Each capability in DALP has one owning system. People reach DALP through the Operations Console, and software reaches it through the Platform API, which belongs to Core Platform. Core Platform also runs sign-in, organisations and deployment under every other system. The other six systems do the work behind those surfaces.
Asset Registry
The Asset Registry holds every asset the organisation issues and the instrument templates it issues them from. Every asset, whether a bond, a fund, an equity or a stablecoin, is issued from a template as the same composable token with its own features and rules. The registry also services the asset over its life: fixed-yield and interest-yield payments, dividends, corporate actions, governance votes, maturity redemption and the holder register. Read Instrument templates and Asset lifecycle.
Compliance & Identity
Compliance & Identity decides who may hold and receive an asset. It keeps the on-chain identity behind each wallet and the transfer rules each token checks inside its own transfer. Trusted issuers are the parties your organisation accepts to vouch for an investor, and Compliance & Identity keeps the verifications they attach to each identity. It also holds the roles each participant has, the organisation-wide compliance controls, the audit trail and regulatory reporting. Read Transfer-path compliance and Compliance policy.
Transaction Lifecycle Engine
The Transaction Lifecycle Engine runs every on-chain write, which is any request that changes state on the network, such as a mint, a transfer or a role change. It queues the write, keeps a durable record of each step, resumes the write after a restart, broadcasts the signed transaction, and ends the write in one outcome. A retry with the same idempotency key within 24 hours attaches to the first write. The engine also pauses a write that is short of gas and decides who pays the gas. Read Transaction lifecycle and Settlement verdict.
Custody & Settlement
Custody & Settlement connects the signer behind each wallet: an external custody provider or HSM, the local key store, or a member's own wallet. It asks a managed signer to sign, and a member signs in their own wallet. It holds a write while a custody provider approves it or while a wallet checker approves it. A wallet checker is the second person a wallet owner names for maker-checker approval of every transaction from that wallet. Custody & Settlement also owns how value changes hands: escrow, primary offerings, fund subscriptions, trading venues, custodial deposits, the bank rail and XvP settlement. The bank rail is the bank connection that credits a client's wallet when a bank transfer arrives and pays redemptions back to the client's bank account. XvP settlement is an exchange in which neither side delivers first. Read Custody provider and XvP settlement.
Ledger Data
Ledger Data is the indexed record of each network the instance follows. The indexer turns chain events into holdings, history and portfolios, and repairs its records after a chain reorganisation. Console and API reads of business records come from this record. The platform reads the chain directly only for named checks: before it sends a write, to detect drift, to reconcile custody and to validate historical timestamps. Ledger Data also sends signed webhooks to your endpoints. Read Ledger data.
Market Data
Market Data supplies the prices the platform values assets with. It keeps a price feed per token, connects external price sources and refreshes exchange rates. A price that moved too far, or that corrects an earlier price, waits for maker-checker approval by a feeds manager or the token's governor. The on-chain price resolver and the current-price reads refuse a price older than its feed's staleness window, and indexed holdings mark a stale value as unreliable. Read Market data.
Operations Console
The Operations Console is the web application where operators do their work: the dashboard, the actions inbox, asset and participant screens, settings and platform status. Its sidebar lists only the areas the signed-in person can use. The investor portal is a separate application for investors. Read the Console guides.
Core Platform
Core Platform runs under every other system. It covers sign-in, organisations and their members, API keys, the Platform API, the SDK and the CLI, the network catalogue, observability, system updates and the self-hosted deployment. Read DALP Instance and System version.
How one write moves through the systems
A write passes the same systems whether it starts in the Console or in the API. Each step maps to the states the platform records on the write. Indexing happens while the write still reads as confirming.
A write passes from request through the engine, approval, signing and broadcast to indexing, and ends in one settlement verdict.
- Request. An operator acts in the Console, or your system calls the Platform API. Every caller acts through an on-chain wallet that holds roles, and the platform refuses a request when the wallet lacks the role the action needs. A write can carry an
Idempotency-Keyheader. A repeat with the same key within 24 hours attaches to the first write. - Queue and prepare. The Transaction Lifecycle Engine records the write and queues it, then prepares the transaction.
- Approve and sign. When a custody provider or a wallet checker holds the transaction for approval, the write waits in the pending approval state. The wallet's signer then signs it: the custody provider, the local key store or, for a self-custody wallet, the member.
- Broadcast and execute. The engine broadcasts the transaction and waits for confirmation. The token contract runs its compliance rules inside the transfer. A transfer that breaks a rule reverts, and no balance changes.
- Index. Ledger Data indexes the block. By default the platform answers a write at once with HTTP 202 and a status handle. A caller that sends
Prefer: wait=Nholds the response for up to N seconds, at most 99, until Ledger Data has indexed the effect, so the next read shows it. If the wait runs out first, the caller gets the 202 handle and the write continues. - Verdict. The write ends as completed, failed, dead letter or cancelled. Dead letter means the platform has stopped retrying and holds the write for an operator, who can requeue a failed or dead-lettered write.
Up to broadcast, the platform can still retry or stop the write. A write can also pause there while it waits for gas funding, as Transaction funding describes. After broadcast, the network decides which transaction confirms, and a cancel sends a replacement transaction that can lose the race.
A completed verdict means the transaction's block was mined and indexed. It does not mean the block is final. If a chain reorganisation removes the block, Ledger Data rolls back the indexed record for the replaced blocks, replays the new ones and withdraws the webhook events of replaced blocks that had not reached finality. Ledger data describes the repair.
The Console and the transfer pre-check can test a transfer against the rules before anyone signs, and they name what stands in the way. Those checks inform the operator. The token contract makes the decision, and its check applies to every ordinary transfer, including one sent straight to the contract. Transfer-path compliance explains both.
How DALP is deployed
DALP ships as container images and one umbrella Helm chart, dalp. Production instances install that chart, and an optional observability chart collects metrics, logs and traces. Two choices decide how an instance runs.
- Who operates the instance. Your platform team installs the chart in your own Kubernetes cluster, in your cloud or on premises, and runs every upgrade. Or SettleMint operates the instance for you with the same chart, on your infrastructure or on infrastructure it holds. On OpenShift, a values overlay sets the restricted security context.
- How much vendor access, when your team operates. The vendor can keep cluster administration, receive telemetry only, hand over the chart and keep no agent, or hold no cluster access while the instance pulls nothing from the vendor registry, because you mirror every image into a registry inside your network and install from that copy. Hosting and access sets out each option.
In both models the instance stores its state in PostgreSQL, Redis and object storage that the operator supplies. The operator also chooses a secret manager for the platform from AWS Secrets Manager, Azure Key Vault, Google Secret Manager or HashiCorp Vault. The chart defaults to the built-in store, local, which keeps secrets and local signing keys encrypted in the platform database. The platform does not refuse it in production, so choose an external secret manager before a production install.
The Console serves its own fonts and images. By default, the platform fetches exchange rates from a public currency service, first through the jsDelivr content network and, when that fails or still serves an earlier day, from currency-api.pages.dev. An operator can point it at its own source. When the operator turns analytics on, the Console sends each signed-in user's email address and user ID to SettleMint's HubSpot account, and the organisation's ID and name to SettleMint's Google Analytics property. Otherwise it calls no hosted analytics service. An instance still reaches the RPC nodes of its networks and any custody provider, identity provider, price source, mail server, telemetry endpoint and assistant model provider it uses. The Console assistant calls its model provider only when the platform or an organisation holds a model key. Prerequisites lists the endpoints and credentials an install needs ready.
Topologies sizes each role of the chart, Upgrades and migrations covers an upgrade, and Supply chain and support covers releases, image provenance and support. For the controls around an instance, read Security and compliance posture, Single sign-on, Backup and disaster recovery and Exit and data portability.
Supported networks
DALP runs on EVM networks, public or permissioned. An instance lists its networks in its configuration, as built-in chains or custom chains with their own chain id, and a platform administrator can add networks later in the network catalogue without a redeployment. Each network needs an HTTP RPC endpoint and a WebSocket endpoint for live indexing. One instance hosts many organisations, the tenants that each have their own members, assets and contracts. An organisation deploys its on-chain system, the set of contracts that holds its identities, rules and assets, on one default network. With multi-network support turned on, it deploys its contracts on more networks, and a request names its network in the X-Chain-Id header or acts on the default network. Networks covers the configuration.
Versions
Each organisation's contracts move between versions through the System updates page in the Console. System version explains what a version is and what a migration changes. The platform's own releases, the API versions and the deprecation policy are on the changelog.
Frequently asked questions
Can a transfer skip the platform and go straight to the token contract?
Yes, and the compliance rules still apply. The rules live in the token contract, so a transaction sent straight to the network meets the same check at the same point, and an ordinary transfer that breaks a rule reverts. A custodian's forced transfer and three other recorded paths skip some of these checks, and Transfer-path compliance lists all four. A direct call skips what the platform adds before broadcast: the role check, custody approval, the durable record and the settlement verdict. Ledger Data still records the result, because it indexes the events of each block it follows, not only the platform's own writes.
What happens to a write in progress when the platform restarts?
The Transaction Lifecycle Engine resumes the write from its recorded state. Keep the original idempotency key. A retry with that key within 24 hours attaches to the write that is still running and does not start a second one. Read the outcome from the write's settlement verdict.
Does DALP replace your core banking or custody systems?
No. Your core systems stay the book of record. They call the Platform API and receive signed webhooks. With an external custody provider or HSM, the provider keeps the keys and its own approval policies, and DALP asks it to sign. With the local key store, the platform holds the key material. A member with a self-custody wallet signs in that wallet.