The Transactions view of Platform status lists the transactions the platform submitted, with their state in the queue and on the chain, and is where an operator recovers a stuck one. Open it when the Transactions panel on Platform status is degraded, or when one transaction does not go through.
Selecting a row opens the Transaction detail sheet with the queue state, the on-chain detail, the error and the receipt. Its “Operator actions” change the transaction, so each one needs a reason, which the platform stores with the action.
The “Transactions” view under “Platform status”, with the “Search transactions…” box and the “Status” filter above a table with the columns “Operation”, “Time”, “Status” and “Chain”.
Each row shows the operation name with the sending address under it. The “From” and “Tx hash” columns are hidden, and “View” adds them back along with the gas and timing columns.
Steps
Open the Transactions view
On Platform status, select Details on the “Transactions” panel. Select “Platform status” in the breadcrumb to return.
Find the transaction
The table lists each transaction with “Operation”, “Time”, “Status” and “Chain”. “From”, “Tx hash” and more columns are hidden until you add them with View: “Transaction ID”, “Nonce”, “Gas price (wei)”, “Gas used”, “Effective gas price (wei)”, “Block”, “Processing time (s)”, “Last updated” and “Trace ID”.
Use Search transactions… to narrow the list, then select the row.
“Status” reads the transaction's state in the queue, such as “Queued”, “Confirming”, “Completed”, “Failed” or “Stopped after retries”.
Export the transactions
Use this to compare what transactions cost and how fast they settle across networks, for example a test network against production.
- Narrow the list with Search transactions… and the filters, if you want only some transactions.
- Select “Export”, then Export as CSV.
The file holds every transaction that matches the search and filters, not only the page on screen, and every column, including the ones “View” hides. The Console reads the list page by page, so a long list takes a moment and Export shows how far it has got. If transactions arrive while it reads, the export stops with a message that the rows changed. Run it again.
The file only holds transactions your organisation can see here. Its gas and timing columns read as follows:
- Gas price (wei) is the price the platform set when it signed the transaction.
- Gas used, “Effective gas price (wei)” and “Block” come from the receipt, so they stay empty until the transaction is mined.
- Processing time (s) is the time from the request arriving to its last update, and stays empty while the transaction is still moving.
Read the transaction detail
The Transaction detail sheet has these sections:
- Queue shows the “Status”, “Sub-status”, “Kind”, “Operation”, “Transaction ID”, “From”, “Chain”, “Created” and “Updated”.
- On-chain shows the “Transaction hash”, “Nonce”, “Gas price”, “Confirmation checks” and “Trace ID”. For a transaction its own wallet signed, “Nonce” is the nonce the transaction was sent with, shown once it is broadcast. For a smart-wallet transaction, it is the sequence of the wallet's user operation on its nonce lane. A transaction a relayer or the custody provider sent for the sender shows a dash, because the sender's nonce is not the one that transaction used.
- Receipt shows the “Outcome”, “Block”, “To”, “Gas used” and “Effective gas price” once the transaction is mined. Before that it reads “No receipt yet. It appears once the transaction is mined.” or, with no hash, “No transaction hash yet, so there is no receipt.” A failed read shows “The receipt could not be read.”
- Error appears when the platform recorded an error for the transaction, below “Operator actions”. It shows “Failure reason”, “Error”, “Revert reason”, “Contract error code” and “Revert data” where each is set. “Failure reason” names the contract error and its arguments when the platform recognises it, or gives the stored message when it does not. “Revert data” holds the raw value, with a copy button, for support or a block explorer.
Recover a stuck transaction
The Operator actions card reads “Recover a stuck request. Each action is recorded with your reason.” For a completed or cancelled request it reads “This request has finished, so no action applies.” An open request offers “Force fail” and “Set next nonce”, a failed one offers “Force retry”, and a dead-lettered one, “Stopped after retries”, offers “Force fail” and “Force retry”. Each action needs a “Reason”:
- Force fail ends a transaction that has not finished, or a dead-lettered one, and marks it failed. It releases the request's nonce. On a dead-lettered transaction it refuses while the chain, the bundler or the custody provider shows that the call can still land, and the sheet shows the reason. It also refuses a paymaster-sponsored transaction whose operation is still with the bundler, because that operation can still run on chain. Such a transaction ends on its own when the bundler settles the operation. A toast confirms “Request marked failed.”
- Force retry puts a failed or dead-lettered transaction back on the queue. Enter “Gas price in wei (optional)” to replace a stuck transaction, or leave it empty. A toast confirms “Request queued again.”
- Set next nonce moves the sender's next nonce to the number you enter in “Next nonce”. Use it to clear a nonce gap. Submit with “Set nonce”. A toast confirms “Next nonce updated.”
When the platform refuses an action, the sheet shows the platform's reason and stays open. A request that has left the queue reads “This request is no longer in the queue, so nothing changed. Reload the list to see its current state.” When it accepts, the sheet closes and the list refreshes.
Troubleshooting
“Force fail” is refused
The sheet shows the reason. A dead-lettered transaction is refused while the chain, the bundler or the custody
provider shows that the call can still land. When the reason asks you to check the transaction that took the nonce,
repeat the force-fail through the API. Set takerHash to the hash of that transaction. Set takerChecked to
other-call to fail the request, or to same-call to keep it dead-lettered until the sweep settles it from that
receipt.
“Force retry” is refused with DALP-200383
Platform status does not show mayStillLand. The Submissions tray shows such a request as “May still go through” to
the person who submitted it. Read it with GET /api/ first. For an unreserved
dead letter that may still land, the server refuses the retry with DALP-200383. The Console cannot send an
attestation that the original call was stopped. After independently confirming the stop, with the provider for custody
calls, an operator can use the API with custodian when the chain does not show the call and no nonce
reservation or recorded submitted nonce remains. DALP records this operator attestation. It does not verify the stop.
This never overrides a visible call, an unresolved nonce slot or the checks on a signed nonce reservation. Force retry
also refuses a step of a role set. Send a new role set to repeat the change.
API routes
The Console lists transactions with GET /api/ and runs each operator action with POST /api/. An API key of an organisation owner or a platform administrator can call both. GET /api/ returns a request's state, including mayStillLand. Through the transitions route, force fail also takes takerHash and takerChecked, and force retry takes custodianStopped. The Console sends none of them. See the Platform API reference.