Acceptance returns a request identifier, and only a recorded outcome of completed reports success, while failed, dead letter and cancelled do not.
A Settlement Verdict is the platform's recorded outcome of any write it accepts, such as an issuance, a transfer or an XvP approval. Report success only when it reads completed. Every accepted instruction becomes a tracked transaction request that ends in one of four recorded states: completed, failed, dead letter, where the platform stopped before a final result, or cancelled.
An acceptance response proves only that the instruction was durably recorded, not that it worked. Success is read from the verdict alone, and a screen or integration that stops waiting shows the operation as processing and keeps its status link.
The verdict is an application outcome. It does not replace the network's finality rules or the transaction receipt.
Why a recorded verdict matters
A Settlement Verdict separates two events that transaction systems often blur: the platform acknowledging an instruction and the platform confirming its outcome. Acceptance means the instruction is safely recorded. The verdict states what became of it. Key client reporting, statements and downstream money movement off the verdict, and apply the network's finality rules before treating a completed write as settled.
The risk this removes is the false positive: telling a client an asset was issued or a payment settled when the operation later failed. Payment systems keep an acknowledgement distinct from a settlement confirmation, and the platform applies the same distinction to on-chain writes. Integrations should wait for the recorded outcome before reporting that an operation succeeded.
This signal is not particular to one kind of operation. A custody approval clearing its wallet, an XvP settlement moving every leg together, a smart wallet deployment, and a corporate action all resolve through the same four states, because each is an accepted write against the platform's transaction state machine. Asset Lifecycle's own integration contract tells the reader to read the verdict the same way, instead of treating acceptance as completion. The verdict is not one of that page's named stages. It applies across every stage that writes to chain.
Use the verdict to track the platform operation and the network's finality rules to assess chain settlement risk. A recorded application outcome does not guarantee same-day settlement or make a transaction immune to reorganisation.
Following a request to its outcome
An operator watches each transaction request toward its verdict. Every accepted write appears as a tracked request with a live status, and the request has finished when the status reaches a terminal value.
While a request is in progress it moves through named working states: RECEIVED, QUEUED, AWAITING_WORKFLOW, PREPARING, PENDING_APPROVAL, SIGNING, BROADCASTING and CONFIRMING. Platform status shows them as Received, Queued, Waiting for its workflow, Preparing, Waiting for approval, Signing, Sending to the network and Confirming, and shows a dead letter as Stopped after retries. Pending approval is a custody approval step where a designated approver authorises the operation. If that approval is declined or expires, the request ends as failed with a matching reason and does not reopen on its own, so submit a fresh instruction with a new idempotency key if the transfer is still needed. When the approval window closes while the custody provider still holds the request, the request ends as dead letter instead, with mayStillLand reading true, which means the call or the provider's filing can still reach the chain. Wait for it to settle before you submit again. A screen that cannot wait for the verdict shows the operation as still processing, and the request's status keeps following it in the transaction queue. It never shows success early.
A failed verdict states its reason: a sub-status, an error message, and, when the platform recognises the failure, a decoded explanation with a suggested next step. A failed token create fails its request with the create write's sub-status when the create write itself failed with one. Every other failure that fails the request reads WORKFLOW_FAILED: a duplicate create, a later step of a token create, and a price update. A failure whose write may still land does not fail the request, which stays open until its write settles. The recovery sweep then closes the request of an ended token create by the same rule. In every case that fails the request, it keeps the revert bytes of the write that failed. Dead letter means the platform has stopped retrying. While mayStillLand reads true, a recovery sweep keeps checking the request and settles it once its outcome shows. Otherwise it waits for an operator. Cancelled records a deliberate stop by the requester. Before broadcast it takes effect immediately, unless a custody provider holds the request for approval and has not confirmed its withdrawal. After broadcast it succeeds only if a replacement transaction outruns the original on chain, using the network's replacement-transaction rules. If the original lands first, the request keeps the verdict its execution earned, so a cancel that lost the race is never recorded as cancelled.
Never resubmit an instruction because a wait timed out. Read the verdict first, because a write that later completes would run twice.
In progress leads to one of four verdicts, and only an operator requeue or a late settlement of a dead-letter request moves a terminal state forward.
How the outcome becomes durable
A Settlement Verdict is a terminal state in the platform's own transaction state machine. That state machine is the source of truth for what became of the requested operation. The chain and its finality rules stay the source of truth for whether a transaction is final. Every accepted write is recorded as a request that moves through eight working states and settles into one of four terminal outcomes.
The status read reports the stored request record. It does not query the chain. The receipt for a mined transaction is a separate lookup, used for chain inspection and reconciliation. The two answer different questions: the verdict says what became of the requested operation, the receipt says what one chain transaction did.
Completion is gated on read visibility. After a write confirms on chain, the request stays confirming, with its receipt, until the platform's own index has processed that block, so a caller that sees completed can read the result it produced. A caller waiting synchronously waits at most 99 seconds for the index. Past that bound the write answers with a retryable error that says the transaction settled but its indexed data is not readable yet.
The verdict and the receipt answer different questions. The verdict is the operation's outcome, and the chain keeps its own finality rules.
Completed and cancelled never change. A failed request can still be recorded as dead letter. An organisation owner or a platform administrator can requeue a failed or dead-letter request straight back into execution. The wallet that sent a failed request can cancel it while nothing was signed. Do not requeue a dead-letter request while mayStillLand reads true: the call can still land, and a requeue can run it twice. A dead-letter request can also still settle. A recovery sweep settles one whose call may still land to completed, failed, or cancelled once a receipt or the custody provider shows how it ended. The same roles can cancel or force-fail a dead-letter request. Force-fail refuses while the chain or the custody provider shows that the call can still land. Nothing else moves a terminal state. Retries and crash recovery attach to the existing request. The one exception is a write the platform rejected before signing: a retry under the same key starts a new request, and the failed one stays on record.
The integration contract
A Settlement Verdict appears on the API as the terminal status of a transaction request. A write returns either a synchronous success carrying the result, or an accepted response carrying the request identifier and a status address. The integration is complete only when the observed status reaches one of the four terminal values.
By default a write returns HTTP 202 with a handle: the request id, its current state, and a status URL. The 202 proves the platform durably accepted the instruction. It says nothing about the outcome, so do not treat it as success. Send Prefer: wait=N to wait inline for 5 to 99 seconds. The wait also ends a few seconds before the request's own deadline. Completion within that window returns HTTP 200 with the resource and transaction hashes. Otherwise, the response returns the same HTTP 202 tracking handle. See Idempotency and async settlement for the full header contract, including the hybrid Prefer: respond- form.
Poll the status URL until the request is terminal, or open its status event stream. Keep following a dead-letter request while its mayStillLand reads true, because its call can still land. The stream sends the current state and later changes. It closes at a terminal state, except a dead letter that may still land, or after 180 seconds without a change. Fall back to polling when it closes without a verdict. Webhooks report the platform events your endpoint subscribes to. They do not replace the transaction request's status. A filterable list endpoint in the API reference supports ad hoc monitoring.
A failed verdict states an error message, a sub-status, and, when the failure maps to a known error, a structured code with decoded arguments and a suggested fix. Per the platform's error contract, branch on the code, not the message text.
A not-found from the status route means the id is unknown or outside your credential's scope. Never conclude from it that the write did not happen. Verify the key, wallet and organisation instead.
The queue attaches a matching submission to the existing transaction request when the idempotency key, sender, chain, and wallet selection match inside a 24-hour window. A route may perform other work before queue admission, so repeat an API request only when that route documents replay safety. A fresh key identifies a new instruction.
A write either settles inside the wait window or returns a status URL to poll, and the verdict supplies the outcome in both cases.
Controls and evidence
A Settlement Verdict serves compliance as the evidential record of what a submitted operation became. Each request keeps its acceptance time, terminal outcome, time of the last state change, failure detail and linked on-chain transaction hashes, so an auditor can answer what happened, when and why for any write after the fact. An operation that settles inside the synchronous wait leaves the same request record as one that reports back later.
The verdict records what happened. Enforcement lives in the asset's own on-chain rules, which bind a direct call to the contract as much as a platform write. A forced transfer by the asset's custodian skips them, and an address on the compliance bypass list skips the recipient-side checks. When those rules reject a write, the write reverts without moving any balance. The verdict then records a failed state with a structured reason: the party's identity is not registered for the asset, required identity claims are missing or revoked, or a specific rule module blocked the operation. The failing party and wallet are named when the platform can identify them, so the auditor sees which control fired. Transfer-Path Compliance explains how to resolve each.
An indexed resource read can lag the operation's status. A chain reorganisation can also change indexed activity after completion was recorded. Reconcile a mismatch using the request record and its transaction references.
The status surface also controls what it discloses: a lookup for a request owned by another organisation answers exactly like a lookup for a missing one, so the surface cannot be probed to reveal another organisation's activity.
Frequently asked questions
What happens when a broadcast transaction never gets a receipt?
After about two minutes without a receipt, the platform marks the request with the TIMEOUT sub-status, which is not a fifth end state: the request stays confirming and the platform keeps watching, so a later receipt still settles it. An automated reconciliation pass, distinct from your own books reconciliation, sweeps up requests that have not moved for five minutes and checks the chain again. A receipt found there completes or fails the request. Finding none, the platform spends the request's retry budget only when the chain shows nothing pending at the request's nonce: it requeues while attempts remain, and ends the request in dead letter once they run out. A dead letter keeps its hash and any custody provider filing. While either can still reach the chain, mayStillLand reads true, and the recovery sweep settles the request when its outcome shows.
A completed operation does not appear in reads yet. Did it fail?
No. A completed verdict means the platform's own index has processed the block, but a resource read can still lag the status, or a chain reorganisation can change indexed activity. Poll the read side again, and never treat a stale read as evidence the write failed.
How is an operation reported when nothing needed to change on chain?
As a completed verdict with no transaction hash. When the requested work was already done, for example when every item in a batch was already registered, the platform records completion without broadcasting anything. A retry of the same instruction then replays that recorded completion instead of executing again.