See what your submission is doing

The Console activity tray now tracks an operation through preparation, signing, submission, confirmation, and indexing. Pending work survives a page refresh and appears across Console tabs.

Console

One tray, every operation, all the way through

Submit something and it appears in the activity tray, an overlay available from any page. It moves through preparing, awaiting approval or signing, submitting, confirming, and indexing, before it reports done. Two outcomes can end it early: still processing, or failed.

Follows you

Across every page

Survives

A hard refresh

Undo

Before it is submitted

Progress

Real counts, confirmation and indexing counts

Submission and completion are separate statesCopy Anchor Link

A message saying the operation was submitted answers the least interesting question. Submitted is the beginning. What follows is a signature, a broadcast, block confirmations, and then the platform's own indexing before the result is readable anywhere.

Collapsing all of that into one cheerful line left people refreshing tables to find out whether anything had happened. Worse, it made the last step invisible: a transaction can be confirmed on chain and still not appear in a list, because the indexed view has not caught up yet. That looks exactly like a failure to somebody watching a table.

Naming the phases fixes that. Indexing is a phase you can see, so waiting through it is informed rather than anxious.

Undo before submissionCopy Anchor Link

While an operation is preparing, awaiting approval, or being signed, nothing has been broadcast. The Console offers an undo for exactly that window: it reverses the change shown on screen and cancels the submission before it goes out.

The moment submitting starts, the option disappears and does not come back. That boundary is real rather than cosmetic, because after broadcast there is nothing to cancel. A platform that offered undo past that point would be describing something it cannot do.

Corrections after settlementCopy Anchor Link

The Console can show an optimistic result before chain confirmation. When the confirmed record differs, the interface marks the correction.

The settled row emphasizes fields whose confirmed values differ from the optimistic display. The emphasis remains visible with reduced motion enabled.

Correcting a failed operationCopy Anchor Link

For supported failures, such as rejected input or insufficient funding, the Console reopens the original form with the entered values. Correct the input or funding issue before resubmitting. Where a form cannot be reopened, use the available retry action after resolving the failure.

Tracking multiple operationsCopy Anchor Link

• A burst collapses. Mint ten tokens and you get one expandable row with a tally of how many are in each phase, not ten stacked entries.
• Just-submitted items pin. A new item holds a place above its table regardless of sort or page, and steps aside when the real row arrives.
• A refresh does not lose it. In-flight work is restored and reconciled against the platform's own status when the page loads again.
• Tabs agree. Two Console tabs show the same operation in the same phase.
• Screen readers hear it. One polite announcement per phase change and one for the outcome, said once rather than repeated as the timer ticks.

Availability and compatibilityCopy Anchor Link

This is Console behaviour and needs no configuration. It arrives with the upgrade, on every surface that submits an operation, in each of the interface languages the Console supports.

PIN management and recovery-code flows use separate handling to clear secrets after use. The activity tray tracks operations in progress. The Activity page shows indexed history; a completed operation appears there after indexing.

Nothing changes for an API integration. No route, request, or response shape is affected.

Follow work in the tray → · Approve what is waiting → · Understand the lifecycle →