In Aptos's sequence-based transaction flow, a later transaction cannot execute until the account reaches the number it needs. One unresolved earlier attempt can therefore hold up another, even when the wallet has enough balance. First check that attempt's actual hash and result; Aptos also supports orderless transactions, which use a different replay-protection model.
The number belongs to the sending account's ordered flow
The Aptos account reference describes the sequence number as tracking submitted transactions committed from that account, including committed transactions that abort. For ordinary sequenced execution, the transaction's number must match the account's next number. A queue position and a payment's success are therefore separate facts.
The transaction-management guide explains why a node can accept a future-number transaction without immediately forwarding it: the preceding sequence has to be accounted for. Accepted by a submission endpoint is not the same as committed onchain. Nor is the wallet's total APT or token balance an answer to the ordering question.
| Evidence you have | What it can mean | What to inspect next |
|---|---|---|
| Later sequenced request waits | An earlier number is unresolved | The earlier transaction and current account number |
| SEQUENCE_NUMBER_TOO_OLD | That sequence number has already been committed | Which transaction used it and what its result was |
| Too-new number during simulation | The tested number exceeds the next account number | Unresolved earlier attempts and the snapshot used |
| Committed transaction with an abort | The transaction exists but its intended action failed | Execution status, gas and current sequence state |
| Orderless nonce-based request | A different replay-protection flow applies | Its hash, nonce context and result, not the ordinary counter alone |
Read a two-payment example in the right order
Consider a fictional account whose next sequence number is 41. The wallet prepares payment Cedar with 41 and payment Maple with 42. If a node has not seen Cedar or learned that 41 committed elsewhere, Maple cannot simply execute as though the missing number did not matter. Clicking Send again does not establish which attempt occupies that position.
If Cedar commits successfully, inspect its recipient and amount before deciding it needs replacement. If Cedar commits with an execution abort, the account can still advance, but Cedar's intended payment has not thereby succeeded. Maple's later result must be checked independently. The sequence is evidence about ordering, not a combined receipt for both payments.
If Cedar instead expires without committing, do not assume that expiry itself advanced the account to 42. Reconcile the account's current state and the outstanding attempts. A displayed countdown reaching zero is not permission to recycle stale wallet state or authorize a fresh duplicate of every payment that looked pending.
Separate a committed abort from a rejected submission
The transactions-and-states documentation distinguishes submission and execution, and describes transaction output containing gas usage and execution status. Some failed actions leave a committed record; other requests fail validation before that stage. Treating every error as a free, never-executed request can lead to the wrong balance and sequence diagnosis.
The transaction-by-hash API reference documents fields including success and vm_status on the relevant committed transaction records. Read them, and compare the intended asset movement. The mere presence of a hash or ledger version does not prove that the recipient got the intended token amount.
For example, an application can show an execution failure after a committed transaction used its sequence position. A later fresh attempt must account for that new state. Conversely, a submission error does not by itself establish a gas charge. Use the recorded outcome rather than infer fees from a generic red banner or from a change in total balance that includes other activity.
Do not manually renumber around an unresolved payment
The official error-code guide describes too-old and too-new sequence conditions. These are reasons to synchronize the request with account state, not instructions to pick arbitrary bigger numbers. A larger number can leave another gap; a reused committed number is already occupied.
Multiple clients can also disagree about the next available position. The transaction-management documentation warns about separate managers maintaining stale in-memory state. For a normal wallet user, pause competing submissions from other tabs or applications while you establish the earlier result. Clearing a local history display does not change the account's onchain counter.
Fees and ordering are distinct. Raising a gas setting cannot make a missing predecessor count as committed. Do not make repeated fee changes while the first outcome is unknown. A rebuilt transaction also needs current expiry, destination and asset information; fixing a counter does not certify the rest of the payment.
Where orderless transactions change the explanation
AIP-123 and the orderless transaction guide describe nonce-based replay protection instead of the ordinary per-account sequence counter. Such operations can execute without the same ordered sequence dependency. The existence of that flow is why 'every Aptos payment waits for the previous sequence number' is too broad.
Do not try to repair an existing wallet request by manually turning it into another transaction type. Support depends on the wallet, builder and network context. For an orderless attempt, use its own hash and result. Progress inferred solely from an account's ordinary sequence number is not a complete tracker for that flow.
Orderless transactions still have validity and replay-protection rules. They are not a way to ignore expired requests or repeat a payment safely without checking the first outcome. The relevant distinction is how the operation is identified and ordered, not a promise that every alternative submission will complete.
Build one consistent support record
- Confirm the network, sending account and replay-protection type. Keep the exact wallet error and original transaction hash.
- Inspect the earlier attempt before the later queued one. Record whether each is pending, committed successfully, committed with an execution error or not found by the queried source.
- For a sequenced request, compare its number with current committed account state. Note other applications that may have submitted from the same account.
- Read success and execution details, then verify the recipient, asset and amount. Do not infer payment success just from counter advancement.
- If a request expired, refresh through the wallet's supported process after reconciling outstanding attempts. Do not blindly sign a copy of every pending item.
- Provide support the hashes, account, network and status evidence. Recovery phrases and private keys are not needed for this public-state investigation.
A missing result at one endpoint leaves a question to resolve, not proof that a replacement is harmless. An exchange's internal deposit status is another layer after the chain's execution. If the chain shows the intended transfer succeeded, send that evidence to the receiver rather than automatically making a second payment.
For general evidence gathering, use checking a transaction by hash. For a no-account swap, keep the service's order reference separate from the Aptos transaction hash. The how-it-works page describes the exchange flow; it does not turn a pending wallet request into a credited deposit or guarantee acceptance of every transaction format.
FAQ
How do I check an Aptos transaction that is stuck behind another?
Find the earlier hash and compare its actual result with the account's current sequence state. For sequence-based requests, the unresolved earlier position matters even when the later request was accepted by a node.
Does an Aptos transaction hash prove the payment succeeded?
No, inspect the committed record's success, execution status and asset movement. A committed abort can occupy a sequence position without completing the intended payment.
Can an Aptos transaction tracker use the account sequence number for everything?
No, orderless transactions use a different nonce-based flow. Track each operation by its hash and result rather than treating the ordinary counter as a universal payment receipt.