HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Products & integrations

How should our application handle pending, expired, or unconfirmed operations?

3 min read

Present the state of the exact operation separately from the freshness of the evidence. A pending operation, an ended authorization attempt, and an unavailable status read are not interchangeable outcomes.

Separate the operation from the status check

The operation can be pending while the latest status read succeeds. Conversely, the operation may have completed while the application cannot currently retrieve its result. These are different situations. Store the operation reference and show the time of the last successful check. A network error should be described as an inability to confirm the current state, not automatically as failure of the underlying financial or wallet action.

Use words that describe the actual stage

Pending means a process has not yet reached the relevant established outcome. Expired means the particular allowed window ended. Unconfirmed means the available evidence cannot establish the claimed condition. The exact definitions come from the operation contract and should be reflected in the interface. Avoid a single red “failed” badge for all three, or a green “complete” badge for any accepted request. Users need a truthful explanation before they can choose a next step.

Design a supported next action

A refresh, an evidence link, or a support route may be appropriate, depending on the state. A new write is not automatically the correct response to uncertainty. Reconcile the original request and follow documented retry behavior. Test slow responses, stale records, ended attempts, and unavailable dependencies in the pilot. Keep any historical attempt visible as history without making it appear current. This reduces the chance that a confusing screen causes a user to create duplicate or inappropriate actions.

Illustrative example

After a lost response, show that confirmation is outstanding and reconcile the authoritative record before deciding whether another request is appropriate.

In plain language

A public record is evidence with a specific scope

An Explorer record is closer to a receipt or an entry in a logbook than to a live control panel. It describes something published about a particular event, object, or process. Some entries include links that let you examine the earlier steps or the underlying transaction. A record can remain useful after it becomes old: it may establish what was recorded at that time. It does not necessarily describe what the system can do now. Look at the record type, network, time, source, and stated verification result together. Missing information means the public view cannot establish that fact; it is not a reason to invent a positive or negative result. Private account records may contain additional context that is deliberately absent from Explorer. This is why a screenshot is a starting point for investigation, while the exact record and its supporting references are much more useful for reaching a conclusion.

In plain language

What an API contract tells your team

An API is a way for one application to ask another system for information or an action. The operation contract is the detailed description of that particular request: what information to send, what access is required, what a response means, and which errors can occur. It is more precise than a product overview. A read normally retrieves information; a write can create or change something and therefore needs more careful handling. Developers should use the current contract for the deployed environment rather than guessing from a similar endpoint or an old example. Business users can help by stating the outcome in ordinary language and naming who may authorize it. Both sides should agree how to identify the request later, what happens if a response is delayed, and which record establishes completion. These details turn a demonstration into an integration that people can operate responsibly.

Conditions & limitations

Do not infer failure from a timeout or signing authority from a recorded stage. Retry and expiry semantics depend on the operation contract.

What to do next

Test delayed responses, missing evidence, and expired attempts, and define a safe user-facing message for each.

Wallet buyer’s checklist ↗V2 API reference ↗