Reconciliation

Reconciliation lets your off-chain register stay the book of record for as long as you want it to, with the DALP ledger standing beside it as evidence you compare against on your own terms.

A difference is often just timing: the two records are produced by different processes on different schedules, not necessarily a mistake.

The platform's evidence supports either cadence, a daily batch pull or an event-driven comparison, from the same point-in-time, replayable record.

Why reconciliation mattersCopy Anchor Link

Reconciliation lets you keep your own register as the book of record. On a cadence you choose, you prove it agrees with the platform's 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, the queryable record of what happened on the chain you follow. It also draws the line for you. A gap that traces to timing or a chain event resolves on its own. A gap that does not stops for a person to decide, instead of leaving that call to whichever record you trust more that day. The platform never requires either side to hold your book of record. Your register can keep that role for as long as you want it to, with the ledger standing beside it as auxiliary evidence, or the ledger can take over once you decide to rely on it directly. Reconciliation is the discipline that keeps the two records honest against each other for as long as your register stays the book of record.

A difference between the two is not, by itself, a mistake. Your register and the DALP ledger are produced by different processes on different schedules. Your register reflects instructions your operations team entered and confirmed on its own timing; the DALP ledger reflects the terminal verdict the platform reached for the on-chain write it executed. A transfer can be true in one record before the other has caught up, and reconciliation often reads that lag as a discrepancy when the two records actually agree.

Why reconciliation compares against one ledger, not severalCopy Anchor Link

Asset Lifecycle names the cost this discipline answers. A programme that keeps issuance in one system, identity screening in a second, custody in a third, trading in a fourth, and settlement and reporting in a fifth needs a comparison at every boundary between them. That boundary is where an instrument's ledger state and its legal record can drift apart. The platform records issuance and servicing against one asset instead, so reconciliation here is a comparison between two parties, your register and one ledger, in place of the several comparisons a multi-system programme would run.

That is also why the platform never asks you to hand over book-of-record status to get the comparison. An institution that already runs its own operations of record, its own accounting treatment, and its own regulatory sign-off can prove the chain agrees with that record. It can do so on a cadence its own operations team sets, without retiring the system those functions are built around. The decision to let the ledger take over stays yours, made through your own legal, regulatory, accounting, and operational review, never a setting the platform switches for you.

Running reconciliation day to dayCopy Anchor Link

Day to day, reconciliation is a comparison you run on a schedule you set, not a service the platform runs for you. The DALP ledger answers a point-in-time query at any past block, so pulling the register as of a cutoff and comparing it to your own is a repeatable lookup rather than a live capture you have to time carefully. Either cadence works, and each costs something different. A batch pull, once a day or once a cycle, needs only that one point-in-time query and skips event handling entirely, but a difference can sit undetected for up to a full cycle. An event-driven comparison runs when a change event arrives. The consumer must handle provisional, final, and retracted events, and reconcile any gaps or duplicates. An operation running an end-of-day close is usually well served by the batch cadence; one carrying intraday exposure needs the event-driven path to catch a difference before the day closes.

Most differences your comparison finds trace to one of two ordinary causes and clear on their own once you know to expect them. The first is timing. Every DALP ledger read answers as of its progress point, the furthest block its record can be trusted through, and how far that point trails the chain's newest block depends on the network's own finality settings. The platform's Ledger Data index itself reports degradation once block lag reaches 10 blocks or its reported state goes 5 minutes stale. Your reconciliation policy sets its own acceptable discrepancy. Your register may post before or after the index's progress point. The second is a chain reorganization, which the platform corrects on its own by deleting and replaying the affected records; wait for that correction rather than reconciling against a figure captured mid-rollback.

A difference that survives both explanations does not get resolved automatically. Route it to a person who can pull the DALP ledger's own evidence, the transfer list and the progress point it covers, and compare it against your register's underlying instruction. That step stays manual on purpose: nothing in the platform decides which of two disagreeing records is correct.

How the two records relateCopy Anchor Link

Two platform records feed reconciliation: the DALP ledger, a decoded, queryable projection of the chain you follow, and the 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, the platform's own terminal outcome for a write you submitted. They answer different questions. The ledger reads each block once and commits its records and progress point together; when the chain replaces recent blocks, it deletes the affected records and replays the canonical chain rather than leaving a stale figure in place. The verdict is recorded once, for the write itself, and never revoked.

Ordinarily those two agree: a verdict of completed means the platform's write reached the chain and the ledger has caught up to the block it landed in. One narrow case breaks that pairing. If a reorganization orphans the exact transaction a verdict already reported completed, the platform's ledger corrects itself, deletes the orphaned records, and replays, but nothing automatically revisits the verdict that already reported completed. That gap has no automated path today; treat a completed verdict as final on the platform's side, and let your reconciliation process flag the rare case where the ledger's own record of that transaction no longer matches it.

Neither record extends past the chain the platform follows. The ledger proves what happened on that chain; it proves nothing about a custody provider's own books, an external bridge, or a reserve held off-chain. Any of those needs its own evidence, sourced separately, before your reconciliation process can rely on it.

The integration contractCopy Anchor Link

Two API surfaces give a reconciliation job what it needs, and neither requires you to poll the raw chain. Query the DALP ledger for the register as of a past block, for one holder's transfers across a period, or for period aggregates such as fees, exemptions, yield, and redemptions. A point-in-time or per-transfer answer includes the progress point it covers, so a comparison against your register states exactly which blocks it accounts for. A period aggregate is stricter: the ledger folds a running total forward only to the newest settled block, so compare an aggregate against that block instead of the progress point.

For the event-driven path, subscribe to Platform EventA Platform Event tells an integration what happened, under a name and shape that cannot change, so it never has to poll the chain or re-derive finality itself.Read the concept notices, the signed record the platform emits as a write changes state, delivered through Webhook DeliveryWebhook Delivery retries a signed notification for three days and records whether a counterparty was told, so an integrator skips its own retry logic.Read the concept, the HTTPS push that carries each notice to your endpoint. Each step in a write arrives as its own event with its own identifier. For example, a transfer can post as provisional before it posts final. A reorganization that invalidates a delivered event produces a retraction naming the identifier it replaces. Your consumer reconciles by replacing the record for that identifier, not by guessing which of two events is current.

Read a write's own outcome from its Settlement Verdict, not from acceptance; acceptance only means the platform durably queued the instruction. Idempotency matters here too, and it has an edge your pipeline has to handle rather than assume away. The queue attaches a matching submission to an existing transaction request when the key, sender, network, and wallet selection match inside the 24-hour window. That does not cover work the API route may perform before queue admission. Outside the window, or with a different wallet-selection fingerprint, a matching queue submission does not attach; it fails outright. Inspect the original operation's status and on-chain result before creating a new attempt. A new key identifies new work and can duplicate an operation that already succeeded. Build your comparison job to key off the progress point and the verdict, not off request timing, and a chain reorganization becomes a correction your job absorbs rather than an alert it has to raise.

What the evidence proves, and what it does notCopy Anchor Link

Reconciliation evidence has two layers. One records what happened on the chain that the platform follows, with repeatable queries and traceable sources. The other records who in your organization acted on each exception. The DALP ledger supplies the first, deterministic under the same query and the same blocks. Every correction traces to the chain's own canonical history, never to an operator editing a figure, which is what makes it defensible evidence for what the chain did. It does not, on its own, establish who in your organization investigated or cleared a specific reconciliation exception; that trail lives in your own operations record, not the platform's.

Be precise about what the platform's own Audit TrailAn audit trail lets you show a regulator or an auditor who did what, under which role, without relying on the requester's own account of the request.Read the concept, the append-only log of which session performed each step, can and cannot show. It records the session that acted, which is normally the person who acted. When someone works under a Delegated AuthorityDelegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.Read the concept, the permission for one participant to act on another participant's behalf, the current log names the operator's own session rather than confirming which party they stood in for. Do not present the platform's log as independently proving who a delegated step was taken on behalf of.

State the evidence claim's limits to a reviewer: the ledger evidences the chain the platform follows, known contract types only, for the period processed under its current recording rules. It says nothing about a custody provider's own books, an external bridge, or an off-chain reserve; those need their own evidence trail: produced and defended separately from what the platform produces here.

Frequently asked questionsCopy Anchor Link