Transaction Lifecycle

Every accepted instruction gets a durable record with exactly one outcome: completed, failed, dead letter, or cancelled. A dead letter outcome holds the request for operator intervention. At the queue boundary, 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 mattersCopy Anchor Link

The Transaction Lifecycle gives every write the platform accepts one auditable path to its outcome. A retry, a restart, or a different way of submitting the same instruction can never leave a write unrecorded, and can never run it twice.

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 to a ledger network, from every other part of the platform, instead funnels through this same queue, so no write can skip a control by taking another path.

The platform records an instruction before execution runs. A matching submission at the queue boundary attaches to that record instead of starting a second queued transaction; this does not make every API route safe to repeat.

A restart or a release part-way through resumes the record it already has, rather than starting over.

The recorded outcome is what lets a caller distinguish acceptance from completion. 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 reorganization.

For an auditor, a control cannot be avoided by choosing a different route in. Who authorized a write, and when, is a property of the platform itself, never of the screen or integration that happened to be used.

Running the queue day to dayCopy Anchor Link

The transaction queue is where an operator meets the Transaction Lifecycle. Every write the platform accepts becomes one tracked request with a named state, and that state answers the question that matters in the moment: where is this now, and does anyone need to act on it?

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.

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

A wait that runs out is not a failure. When a screen or an integration stops waiting, the request carries on as before, and the operator follows it in the work queue. One rule keeps the ledger clean: never resubmit because a wait ended. A write that later completes would be duplicated by a blind resubmission.

A cancelled outcome, by contrast, is requested rather than reached. 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 actually earned.

Both held outcomes recover the same way: an administrator with the right permission requeues the request, which reuses the existing request rather than starting a second one. The API reference has the exact endpoint, its parameters, and its error responses.

Where responsibility changes handsCopy Anchor Link

Four boundaries make up the Transaction Lifecycle's architecture, and each one changes who owns the instruction. Where an instruction sits tells you which part of the system is responsible for it and what a failure at that point means.

The first boundary is the console, the platform's own operator interface. An ordered set of checks there decides which keys will sign and confirms the requester's credential before a request is sent. The ordering is the interface's own; 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, and it is the pivot of the whole design. The platform settles who may make the request and which account will execute it, then writes the instruction down once. The transaction queue deduplicates a matching submission carrying the same idempotency key, sender, ledger network, and wallet selection. A route may perform other work before acceptance, so check its replay contract before repeating the API request.

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 has exactly one outcome, however many attempts it took.

The fourth boundary is read visibility. After the network confirms a write, the platform waits for its own indexed record to catch up to that transaction before it reports the request completed. A status read uses a bounded synchronous wait window for that, and a write you are waiting on synchronously waits inside the window you asked for. Most of the time, if the index has not caught up when that window closes, the platform does not fail the read and does not hold it open. It answers with the request's current state instead, which for a short moment can trail the outcome the network has already confirmed. When the index itself is far enough behind, that wait fails instead with a retryable error naming the chain and the block it is still waiting on; retry the read once the index has moved past that block.

The integration contractCopy Anchor Link

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.

Treating an accepted response as success is the integration bug this contract exists to prevent. 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 is a substitute for the terminal check, and a stream that closes early is not a stopped request, only a closed connection; poll the status address instead. 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 queue boundary, 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. This queue rule does not prove the whole API route is safe to replay. A key reused past the 24-hour window no longer matches, so reconcile the earlier request before sending a replacement.

Controls and evidenceCopy Anchor Link

Compliance reads the Transaction Lifecycle as the evidence chain behind a write. One instruction produces one record. The controls that govern it fire at fixed points on the path, each one before the step it guards, so whether a check ran before or after execution is never in question.

Signing follows the selected wallet's policy. When that policy requires custody approval, its named approvers must authorize the payload before signing. The asset's own transfer rules run on the network at execution, and a movement that fails one of them reverts, so a non-compliant transfer never settles. Neither control cares how 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 before it ever reaches the platform, so a logged-in session alone cannot move assets. A request authenticated by an API credential does not carry that step; the credential itself is what authorizes 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 and the requester, plus a readable description of the call, decoded at acceptance rather than left as a raw payload. 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 crosses the same acceptance boundary, 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 organization's activity.

Frequently asked questionsCopy Anchor Link