In a regulated digital asset program, an instruction is not finished when it is submitted. It needs an auditable status after the fact: where it sits, what step last ran, and how the file closes.
DALP 3.0 keeps that status across preparation, approval, broadcast and confirmation. Custody approval can take time without the transaction dropping out of view. A network timeout should not force a cold restart. The platform resumes from the last known step. If recovery is not automatic, the case is raised for an operator instead of being buried in a log.
The same standard applies to the ledger record. The Ledger Index turns on-chain activity into queryable business data, including balances, transfers, fees, yield and redemptions, with history available at past blocks. Operations, audit and reporting can share one record instead of rebuilding the story later.
Settlement needs the same certainty. When value changes hands, the institution should know whether the transaction completed, failed or needs action. There should be no fog between the instruction and the record.
Why a transaction without state is not enough
From outside, a blockchain send looks simple: prepare it, sign it, broadcast it, wait for the receipt. In production each of those steps can fail on its own. A gas estimate can time out. A custody provider can hold the request pending approval for tens of minutes. Broadcast can succeed while the receipt never arrives.
If the platform has no explicit record of which step last ran, ops are left with a bad choice: retry and risk a duplicate send, or do nothing and leave a transfer in an unknown state. On a regulated book both outcomes are unacceptable. A duplicate issuance is a compliance event. An approval that expires without a clear trail becomes an investor transfer that never settled. A failed but unconfirmed send leaves a gap in the audit file.
Under real concurrency, with long custody windows and variable chain conditions, those cases are common, not rare edge cases.
Durable transactions: explicit state across the lifecycle
DALP 3.0 treats each send as a tracked process. The Transaction Lifecycle Engine moves work through named states: received, queued, preparing, signing, broadcasting, confirming and completed. Custody workflows that need external sign-off pass through pending approval. Every path ends in a terminal state: completed when the send lands, failed when retries are exhausted, canceled when ops or the system aborts, or dead letter when automatic recovery is spent and an operator has to intervene.
Each transition is persisted before the engine proceeds. If the process is interrupted between broadcasting and confirming, it resumes at broadcasting rather than starting over. Recovery begins where work stopped.
The product design is described in the DALP 3.0 durable transactions documentation.
Nonces held for the life of the send
On EVM networks, each account sends in strict order. The nonce increments by one on every successful allocation. A retry that claims a new nonce while an earlier send is still in flight can collide or open a gap that blocks later work from the same account.
DALP 3.0 allocates the nonce during preparation and holds it through broadcasting and confirming. Release happens only when the send reaches a terminal state. A retry of a live send reuses the same nonce. Two in-flight sends from the same signing account are queued so nonces stay ordered.
When a nonce error does surface, it is typed. Nonce conflict and nonce too low are distinct sub-statuses on a failed state, so ops can see whether sequencing failed in the platform path or an external condition was reported correctly.
Reverts with reasons ops can act on
When a transfer reverts on-chain, the reason is encoded in the receipt. Before 3.0, reading that reason meant matching a four-byte selector to a contract ABI and translating parameters by hand.
The lifecycle engine decodes that automatically against the fault types the platform tracks, including frozen addresses, expired identity claims, allowlist misses, supply caps and policy blocks. Integrations receive a fault name and the value that caused the rejection. The operator sees the rule that fired, not a hex string. That same structured rejection becomes part of the audit record: when the transfer was attempted, why it failed, and which rule applied.
Long writes and multi-step workflows that resume
Some writes take longer than an HTTP connection will stay open. Token deploys, multi-step transfers and compliance onboarding can wait across multiple blocks. v2 write endpoints return immediately with a correlation handle. Status comes from a dedicated endpoint that emits the settled outcome when confirmation lands: final state, on-chain address for deploys, transaction hash and inclusion block. A reconnect returns the current state for that handle without a separate reconciliation pass.
Multi-step operations that include on-chain sends are journaled. A pod eviction, rolling upgrade or crash mid-flight resumes from the last completed step. Finished steps are not re-executed. Incomplete steps are retried with the same inputs until they succeed or exhaust their budget. The platform applies a disruption budget at upgrade boundaries so in-progress work can drain before the running instance is replaced.
Stalls are not left silent. When thresholds are hit, alerts surface in the console. Runs that need a human decision, including dead-letter cases, appear through the Platform API and CLI: list what is stuck, dry-run a resume, resume one transaction or a set. The rescue is part of the lifecycle history for that send.
Ledger Index: on-chain history as business data
Status on the instruction is only half the requirement. Quarterly audits, tax filings and compliance checks need a complete, queryable record of what settled on-chain and when.
An EVM node answers what is true at the tip of the chain. It does not answer who held a security token on 31 March, or what fee total a period produced. Those questions need a layer that reads each finalized block, decodes the events, and stores the result in a form that can be queried.
In DALP 3.0 that layer is the Ledger Index. It discovers contracts on-chain, decodes events as blocks finalize, and keeps full history as typed business data. Live follow and historical backfill run in the same system, across each network the deployment operates on. The answer is served through the Platform API once the block is final.
Correctness is a first requirement. On a reorganization, the index walks back from the last processed block, finds the fork point, reverses mutations in order, then replays forward. The same query against the same block number returns the same answer. That is what turns a historical balance into something audit can treat as evidence rather than a dashboard reading.
What the index holds goes beyond current balances. Balances can be read at any past block. Fee collections, exemptions and accruals persist across fee-token changes. Yield figures (consumed interest, closed accruals, payout schedules, claims) are kept so treasury can reconcile without re-running calculations at read time. Maturity redemptions are tracked per holder so the servicing record for a bond or debt instrument is a direct lookup.
The Ledger Index is covered in the DALP 3.0 Ledger Index documentation.
What this gives the institution
Put the two features together and the operating picture is simple. Each instruction stays in a known state through preparation, approval, broadcast and confirmation. If custody takes time, the transaction waits in a tracked state. If the network times out, the platform resumes from the last known step. If recovery cannot complete on its own, the case is raised for an operator. After settlement, the ledger history is queryable as balances, transfers, fees, yield and redemptions, including at past blocks.
That is what DALP 3.0 is built for: transactions the firm can track, recover and explain, and a ledger history that holds up under operational and audit review.
For the wider release, visit the DALP platform overview. Architecture and operator detail reach deeper through the transaction tracking and historical balances pages.
Frequently asked questions
Every send moves through named, persisted states across preparation, approval, broadcast and confirmation. If a step stalls, the engine resumes from the last recorded state rather than restarting from the beginning or losing the work.
No. A retry of a live send reuses the nonce held for that transaction. The nonce is only released when the send reaches a terminal state (confirmed, failed or cancelled), which avoids the usual duplicate-or-gap failure modes.
When automatic retries are spent, the engine parks the send in dead letter and surfaces it through the Platform API and CLI. An operator resolves the underlying issue and can rescue the transaction back to queued. That rescue becomes part of the lifecycle history.
The Ledger Index is the platform's built-in, multi-chain index. It decodes on-chain events as blocks finalise, keeps history reorg-safe, and serves balances, transfers, fees, yield and redemptions as queryable business data, including at past blocks.
Yes. Balances can be read at any past block. Fee, yield and redemption records are kept so period reporting, servicing and audit can query the same structured history through the Platform API.
Yes. On a reorganisation the index finds the fork point, reverses mutations from that range, then replays forward. The same query against the same block returns the same answer, so historical figures can be treated as evidence rather than a one-off dashboard reading.
Want to discuss how durable transactions and ledger history fit your digital asset program?
Book a call with our team ↗
About SettleMint
SettleMint, headquartered in Leuven, Belgium, with offices in UAE, Singapore and Japan is the company behind DALP, the entirely composable Digital Asset Lifecycle Platform. DALP enables financial institutions, market infrastructure operators, and governments to build, deploy, and manage digital assets and blockchain applications at scale.
