# Transactions

Source: https://docs.settlemint.com/docs/console/organisation-settings/platform-status-transactions
Find a transaction on Platform status, read its queue and on-chain detail, and recover a stuck one with force fail, force retry or set next nonce.

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](https://docs.settlemint.com/docs/console/organisation-settings/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.

![Platform status Transactions view with the Search transactions box, the Status filter and a table with Operation, Time, Status and Chain columns](https://docs.settlemint.com/docs/screenshots/console-organisation-platform-status-transactions.light.en.webp)

[Screenshot] 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.

## Before you start [#before-you-start]

- The platform accepts an action only for a transaction sent from, or recorded for, your organisation's wallets.
- A platform administrator can run these actions on the transactions of any organisation they are a member of.
- None of the three actions asks for wallet verification.
- Decide the reason you will record before you open the action.

## Steps [#steps]

### Open the Transactions view [#open-the-transactions-view]

On [Platform status](https://docs.settlemint.com/docs/console/organisation-settings/platform-status), select **Details** on the "Transactions" panel. Select "Platform status" in the breadcrumb to return.

### Find the transaction [#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 [#export-the-transactions]

Use this to compare what transactions cost and how fast they settle across networks, for example a test network against production.

1. Narrow the list with **Search transactions…** and the filters, if you want only some transactions.
2. 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 [#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 [#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.

Note (Check the evidence before you force a transaction): A force action overrides the platform's own settling. Confirm on the chain, with the bundler or with the custody provider that the call cannot still land, and record that in the reason.

## You should see [#you-should-see]

- Reopen the transaction. After "Force fail", its **Status** reads "Failed".
- After "Force retry", it returns to the queue and moves on to "Completed", or fails again with a new "Failure reason".
- After "Set next nonce", the sender's following transactions leave the nonce gap.

## Troubleshooting [#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/v2/transaction-requests/{transactionId}` 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 `custodianStopped: true` 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 [#api-routes]

The Console lists transactions with `GET /api/v2/platform-status/transactions-list` and runs each operator action with `POST /api/v2/transaction-requests/{transactionId}/transitions`. An API key of an organisation owner or a platform administrator can call both. `GET /api/v2/transaction-requests/{transactionId}` 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](https://docs.settlemint.com/docs/api-reference/v2).