We aim to make improvements around this information and make it more accessible to troubleshoot transactions generally, but wanted to post some initial info originally shared by @aaron early for anyone that is interested.
Transactions that are well formed are generally processed in the next block, roughly in a 10-20 min timeline. There are no known problems with well formed transactions. However there are various reasons why a transaction might take longer. Usually the reason that transactions don’t go through are because of the sequence of transactions matters (e.g. if that transaction depends on another being processed first), and or due to nonce issues.
Transactions are garbage collected after 256 blocks and anyone experiencing long-pending transactions can simply re-send their transactions after that point. Sharing some of the resources to determine what the correct nonce could be and for further troubleshooting if folks so desire.
Figuring Out What’s Wrong
There are a couple things to check:
- Is there a transaction with the correct nonce? If not, send a new one with the correct nonce.
- Is the transaction with the correct nonce overspending?
Collecting information about the sender account
Figure out what the current account status is
Current balance can be found in the explorer.
For example:
Shows a balance of 0.000514 STX (which is 514 microSTX).
Also important is the account nonce, but this isn’t displayed in the explorer, but it is available if you look at the API:
That shows a nonce of 8.
What that means is that the only transactions that will be considered by miners are those with nonce = 8.
If the user waits until any pending transactions are garbage collected by the network, the wallet should then be able to generate and broadcast correct transactions.
Finding pending transactions
You want to see all of the pending transactions from an address, because you’re looking for one where the nonce is the expected one.
You can look at an addresses pending transactions via the API (simply replace the STX address below with whatever STX address you’re looking into):
This account has no pending transactions at the moment. But you can see where you can replace any address in the URL, again by replacing the STX address with the one you’re looking into. The following address does have pending transactions. (This might not stay relevant as a data point for long, but including as an example for now.)
Under “results”, there’s a list of transaction objects. Look at the “nonce” field of the transactions, and find the transaction with the correct nonce. In this case, that’s nonce=1:
{
"tx_id": "0xfdc246a8acf5f12d2446fc1209013c72bc80c54c28e3b0fda70b1f2e3040fabc",
"tx_status": "pending",
"tx_type": "token_transfer",
"receipt_time": 1617718280,
"receipt_time_iso": "2021-04-06T14:11:20.000Z",
"nonce": 1,
"fee_rate": "180",
"sender_address": "SP1P5P0VF9DYDJSPY4HG2K69H5NAJEED4F7CGXEPH",
"sponsored": false,
"post_condition_mode": "deny",
"token_transfer": {
"recipient_address": "SP3C9AQCGPNJQA0S3M05676F0201X0V1P100V5C8C",
"amount": "99900000",
"memo": "0x00000000000000000000000000000000000000000000000000000000000000000000"
}
}
Once you know the correct nonce from the account info page, and you find the corresponding transaction with that nonce, check the total spend of the transaction: that’s the “token_transfer”: { “amount” } field (here, it is 99900000) plus the fee (here, it is 180). So the total spend of the transaction is 99900180 microSTX which is 99.900180 STX, and compare that to the account’s current balance to see if the balance could support the transaction. If not, then the transaction should be re-sent by the sender.
Again, there are no known issues for well formed transactions, and most transactions should process within a 10-20 minute timeline. Users can always wait 256 blocks until their transactions are no longer pending and try again with no impact on their funds. This post is simply sharing a link to the API with nonce info for folks that would like to dive a bit deeper and troubleshoot on their own.
Additional resources: Transactions in mempool: best-practices and known issues