Skip to main content

Transaction Lifecycle

The Transaction Lifecycle gives every platform write one auditable path to its outcome, and a same-key retry at the queue attaches to the same record.
One governed path, so no write is lost or run twiceAn instruction arrives from a person, an integration, or an agent. Before it is submitted, the console runs ordered checks that decide which keys sign and confirm the requester's credential. The platform then writes the instruction down once. That durable record carries it through five steps: accepted and written down, checked and prepared to send, held for approval when policy asks, signed, then sent to the network, and confirmed by the network. Alongside the record sits the requester's wait, which is a separate thing. If the requester is still waiting when the work finishes, the result comes back in the response. If the wait window ends first, a tracking identifier comes back instead and the record continues without them. Either way the path ends at one recorded outcome: completed, failed, dead letter, or cancelled.An instruction from a person, an integration, or an agentBefore it is submittedConfirm which keys signVerify your credentialThe console runs these in order. The platform validates what they produced.One durable recordWritten before anything moves.Accepted and written downChecked and prepared to sendHeld for approval, when policy asksSigned and sent to the networkConfirmed by the networkYour waitStill waiting whenthe work finishesThe result comesback to you.Your wait windowends firstA tracking IDcomes back.Record continues.Either way, the path ends in the same place.One recorded outcomecompleted, failed, dead letter, or cancelledOne governed path, so no write is lost or run twiceThe same figure as the desktop variant, drawn portrait for phone widths. An instruction arrives from a person, an integration, or an agent. Before it is submitted, the console runs ordered checks that decide which keys sign and confirm the requester's credential. The platform then writes the instruction down once. That durable record carries it through five steps: accepted and written down, checked and prepared to send, held for approval when policy asks, signed, then sent to the network, and confirmed by the network. Alongside the record sits the requester's wait, which is a separate thing. If the requester is still waiting when the work finishes, the result comes back in the response. If the wait window ends first, a tracking identifier comes back instead and the record continues without them. Either way the path ends at one recorded outcome: completed, failed, dead letter, or cancelled.

One record carries an instruction the whole way, whether you wait for the answer or leave early.

  • An instruction is any change the platform makes for you, such as an issuance or a transfer. Every accepted instruction gets one durable record that ends completed, failed, dead letter or cancelled. Completed and cancelled never change, and an administrator can requeue a failed or dead-letter request. A dead letter outcome means the platform stopped sending the call. While its hash or custody provider filing can still reach the chain, mayStillLand reads true and a recovery sweep keeps checking the request and settles it once its outcome shows. Otherwise it waits for an administrator. At the transaction queue, a matching submission attaches to that record when it repeats the same key, sender, network, and wallet selection within the idempotency window. An API route can do other work before reaching the queue.

  • You choose how long to wait for the answer. The work is identical either way. Ending your wait early returns a tracking identifier, not a failure.

  • Signing follows the wallet's own policy, so custody approval is required only when that policy calls for it. The token's own transfer rules run separately, during execution on the network.

Why one governed path matters

The Transaction Lifecycle gives every write the platform accepts one auditable path to its outcome. A restart, or a retry that reaches the queue under the same idempotency key, resumes the record the platform already holds, and a resent call reuses the same signed bytes and nonce, so the chain accepts it once. A second submission under a new key is a new instruction.

The alternative is letting each part of the platform send its own writes to the network. That multiplies the paths an instruction could take to reach the same effect. A path that bypasses this queue is a path where a required check, a custody approval, or a compliance rule never had the chance to run. Every write the platform signs or submits, from every part of the platform, funnels through this same queue, so no platform route skips a platform control. A key holder who calls a contract directly bypasses the platform, and only the contract's own on-chain rules bind that call.

The platform records an instruction before execution runs. A restart or a release part-way through resumes the record it already has, and recovery is bounded, so a persistent infrastructure failure can still end the run as failed.

Report success only after the operation completes, and apply the network's own finality rules separately: application status does not guarantee same-day settlement, and it does not rule out a chain reorganisation.

For an auditor, the record names the requester and the acceptance time whichever platform route was used.

Running the queue day to day

The transaction queue is where an operator meets the Transaction Lifecycle. Every write the platform accepts becomes one tracked request whose named state shows where it is and whether anyone needs to act.

The order is fixed. A request is accepted and queued, then prepared, which is where the platform checks the call and reserves its place in the sending order. If the wallet's policy requires an approval, it waits there until a named approver decides.

A signer then produces the signature, the platform sends the transaction to the network, and a watcher follows it until the network confirms. Only then does the platform record the outcome.

A write the account holder signs outside the platform through external signing gets a request of its own and joins this order part way. A transaction the holder's wallet already sent starts at BROADCASTING, and a user operation its owner signed for the platform to submit starts in the queue.

Most steps run automatically. Custody approval, a funding requirement, or an exhausted recovery budget can require a person to act.

Moves on its own
Waits for a person
Where
Accepted, prepared, signed, sent, or awaiting confirmation.
Held for a custody approval, or held on an exhausted retry budget.
Moved by
The platform's own execution, including its retries.
An approver's decision, or an administrator requeuing the request.
If nobody acts
The platform continues execution or recovery.
A missed deadline fails the request, or sends it to dead letter while a custody provider filing stays open. An exhausted retry budget sends it to dead letter. A dead letter whose call may still land settles from the chain or the custody provider. The rest wait for an administrator.

A wait that runs out is not a failure. When a screen or an integration stops waiting, the request carries on as before, and its status keeps reporting where it is. Never resubmit because a wait ended, because a write that later completes would run twice.

The Submissions tray in the Console and in the Investor portal keeps following the request after the screen stops waiting. Clear done removes the completed and cancelled rows from the tray, keeps the failed and in-progress ones, and leaves the requests themselves untouched. Each browser remembers the rows cleared for an organisation for 30 days, so a cleared row stays hidden when the tray reads its requests again.

A cancelled outcome exists only because someone asked for it. Stopping a request while it still waits on the queue, before signing, ends it as cancelled at once. Asking to stop one already broadcast succeeds only if a replacement transaction outruns the original on chain, so the request always keeps the outcome its execution earned. The managed key that signed the write signs that replacement: the sender's own custody wallet, or the organisation's relayer for a relayed write. When the platform holds no managed key for the write, such as a write signed in a browser wallet or sent by a smart account, the cancel is refused and nothing is signed. When a custody provider holds that replacement for approval, the platform withdraws it and refuses the cancel, as custody approval explains.

An organisation owner or a platform administrator recovers a failed or dead-letter request by force-retrying it, which requeues the existing request rather than starting a second one. A dead letter whose mayStillLand reads true can run twice if retried. With no nonce reservation, the platform refuses that retry with DALP-200383. The operator can retry through the API with custodianStopped: true only when three things hold: no nonce reservation or recorded submitted nonce remains, the chain does not show the call, and the operator has confirmed that the original call was stopped. For a custody call the operator confirms this with the provider. DALP records this operator attestation. It does not verify the stop. This confirmation never overrides a call the chain shows or an unresolved nonce slot. Signed nonce reservations keep their existing settlement checks. The API reference has the exact endpoint, its parameters, and its error responses.

Where responsibility changes hands

The path has four layers. Where an instruction sits tells you which layer owns it and what a failure there means.

The first layer is the console, the platform's own operator interface, for instructions that start there. An ordered set of checks there decides which keys sign and confirms the requester's credential before a request is sent. The Console applies that order itself. The platform validates every field it receives, from the console and from a direct integration alike, so neither route is the weaker one.

The second is acceptance. The platform settles who may make the request and which account executes it, then writes the instruction down once. The transaction queue deduplicates a matching submission, as The integration contract states.

The third is execution. Preparation, approval, signing, sending, and confirmation all run against that one record, and the run is journaled, so a crash or a deployment resumes the same request. Each accepted instruction ends in one recorded outcome, however many attempts it took.

The fourth layer is read visibility. After the network confirms a write, the platform keeps the request at CONFIRMING, with its receipt, until its own indexed record has processed that block, and only then records it as completed. A status read never waits for the index: it answers with the stored state, and while an index rebuild holds the request, the answer names the chain and the block the rebuild must pass. A write you are waiting on synchronously waits at most 99 seconds for the index. When the index has not caught up by then, the write answers with a retryable error that says the transaction settled on chain but its indexed data is not readable yet. Read the request status instead of sending the write again.

The four layers that own an instructionFour stacked layers, in order. In the console, ordered checks decide who signs and confirm the requester's credential. The platform receives the fields they produced and validates them. At acceptance, the platform settles authorisation and the executing account first, then writes the instruction down once. A repeat of the same instruction attaches to that record instead of starting a second one. In durable execution, the platform prepares, seeks approval, signs, sends, and confirms against that one record, and a restart resumes it rather than starting a new one. Before the platform reports the request completed, it waits for its own indexed record to reach the confirmed block. A synchronous write waits for that only within a bounded window, and answers with a retryable error if the index has not caught up by then.Ordered checks decide who signs and confirm your credential.In the consoleThe platform receives the fields they produced, and validates them.AcceptanceAuthorisation and the executing account are settled first.Then the instruction is written down, once.Durable executionPrepare, approve, sign, send to the network, confirm.A restart resumes this record, never a new one.Before completed is reportedThe platform waits for its own indexed record to reachthe confirmed block. A synchronous wait is bounded.If the index falls too far behind, that wait fails and asks you to retry.The four layers that own an instructionThe same figure as the desktop variant, drawn portrait for phone widths. Four stacked layers, in order. In the console, ordered checks decide who signs and confirm the requester's credential. The platform receives the fields they produced and validates them. At acceptance, the platform settles authorisation and the executing account first, then writes the instruction down once. A repeat of the same instruction attaches to that record instead of starting a second one. In durable execution, the platform prepares, seeks approval, signs, sends, and confirms against that one record, and a restart resumes it rather than starting a new one. Before the platform reports the request completed, it waits for its own indexed record to reach the confirmed block. A synchronous write waits for that only within a bounded window, and answers with a retryable error if the index has not caught up by then.

Acceptance is the pivot: the layers before it prepare the instruction, and the layers after it run against a record the platform already holds.

The integration contract

A write returns one of two things: the finished result, or a handle to work still in progress. Your integration is complete only when the request's status reaches a terminal value, never when the write call returns.

Asynchronous is the default. A write sent with no stated preference comes back as an accepted response carrying the request's identifier, its current state, and a status address to follow. Ask for a bounded wait instead when your caller can hold the connection open and would rather have one round trip than a poll loop, for example a checkout step waiting on a person. Default to async, and poll or stream the status, when the write can outlast a short wait or your caller cannot hold a connection open, for example a batch job. Either way, the response tells you which one it gave you, so your integration branches on that instead of guessing.

Follow the request's status until it reaches a terminal state: poll the status address on a plain interval, or open its status event stream when you would rather the platform push each change to you. Neither replaces the terminal check, and a stream that closes early is a closed connection, not a stopped request, so poll the status address. A dead letter whose mayStillLand reads true has not ended yet: keep following it, and do not send the write again. An endpoint subscribed to transaction.request.* receives the outcome without polling, as described in Transaction lifecycle events. The idempotency and async settlement contract has the exact wait windows, status codes, headers, and stream limits, and the API reference has every field and error this page does not repeat.

At the transaction queue, a matching submission with the same idempotency key, sender, ledger network, and wallet selection inside a 24-hour window attaches to the existing transaction request. Reusing the key with a different wallet selection is rejected outright. An API route can do other work before it reaches the queue, so this rule does not prove the whole route is safe to replay. A key first used more than 24 hours earlier is refused as an idempotency conflict, even for an identical write. Reconcile the earlier request, then send the replacement under a new key.

Controls and evidence

Each write leaves one record that shows who asked, which controls ran and what the network did. The controls fire at fixed points on the path: custody approval before signing, and the asset's transfer rules during execution on the network.

Signing follows the selected wallet's policy. When that policy requires custody approval, its named approvers must authorise the payload before signing. The asset's own transfer rules run on the network at execution, and an ordinary transfer that fails one of them reverts. A forced transfer by the asset's custodian skips those rules, and an address on the compliance bypass list skips the recipient-side checks. Both controls apply however the request was authenticated.

A console session carries a further check ahead of both: the requester confirms that specific request with a personal verification code, and the platform verifies it before accepting the write, so a logged-in session alone does not move assets. Repairs are the exception: an organisation owner or a platform administrator can force-retry a failed or dead-letter write without a verification code, and the platform signs and sends it again. A request authenticated by an API credential does not carry that step. The credential itself is what authorises it. That route's equivalent control is how tightly the credential is scoped and how often it is rotated, not a per-request code.

The record is what an auditor reads afterwards. It carries the acceptance time, the requester and the operation kind, such as token.mint, with the call it asked for. It also carries each move from one state to the next with its time, the failure reason and its detailed sub-status when a request ends badly, and the network transactions the request produced.

Because every surface passes through the same acceptance step, the evidence is the same whether the instruction came from the console, from an integration, or from an agent. The status surface also limits what it discloses: a request outside the caller's scope answers not-found, exactly as a request that never existed would, so it cannot be probed to map another organisation's activity.

Frequently asked questions

What happens if I don't send my own idempotency key?

The platform generates one for you. A later request that also omits the header gets a different generated key. Send your own idempotency key when a route documents replay safety and your integration may need to retry it. On other routes, inspect the original operation and its effects before sending another request.

What happens when the requested work was already done?

The request completes without sending anything to the network. When every item in an instruction was already in place, for example a batch whose members are all registered, the platform records the completion with no network transaction attached, and a matching retry reuses that same recorded completion.

The idempotency and async settlement contract covers the header names, formats, and edge cases these two questions do not.

Was this page helpful?