A Tezos “counter in the past” error means the submitted manager-operation counter is below the value expected in the node’s current context. Check the sender’s included operations, current counter and pending activity before building another payment. The error does not by itself say that your intended recipient was paid, and changing the counter blindly can create a second payment.
The counter belongs to the sending manager, not the payment screen
Tezos uses counters to order manager operations and prevent replay. The RPC error reference distinguishes a counter already used from one not yet reached, and its error data includes expected and found values. The full error identifier can include a protocol-specific prefix; preserve the complete message instead of matching only one old screenshot.
The same sending account can appear in more than one application. A delegation, contract interaction or other manager operation can matter even when you are currently looking at a transfer screen. OpenTezos’s operations overview explains why “operation” is broader than an ordinary transfer. Build the account timeline from its activity rather than from one app’s payment list.
Imagine a fictional account whose included counter is 43. A draft still carrying 42 is stale in that context. That observation tells you about ordering; it does not reveal whether operation 43 was the transfer you wanted. Open that operation’s contents and result. Do not label a payment “received” merely because the next counter has moved forward.
Separate a draft, the node’s mempool and an included result
An application can remember a draft or a submission attempt that is not an included operation. The Octez prevalidator documentation describes how a node classifies operations before inclusion and can reconsider those classifications after a new head. A pending label must therefore be interpreted with its source and observation time.
| Observation | What it can establish | What to inspect next |
|---|---|---|
| Wallet shows a local pending item | The application remembers an attempt | Find its hash and whether a node or block knows it |
| Node has an operation in its mempool | That node has observed it before inclusion | Its classification, counter and current chain context |
| Operation is included with a failed result | Inclusion occurred without the intended successful execution | The precise error, fees and current account state |
| Counter is higher than the draft expects | The draft is behind the observed state | Which included operations advanced the account |
| Transfer is applied to the intended recipient | There is evidence of the specific chain payment | Recipient amount, asset and any service-side credit |
The protocol mempool description explicitly separates validating operations from actually applying them. This is why a node accepting or classifying a candidate is different from a completed transfer. Keep the two observations separate in your notes, even when the wallet interface displays both under one transaction history.
Read the original payment before deciding to retry
- Save the original hash, source address, destination, asset, amount and full counter error.
- Confirm that the wallet and explorer refer to the same network and sending account.
- Search the original operation and the sender’s recent included history, not just the destination balance.
- Inspect each relevant content result and any pending attempts associated with the same sender.
- Refresh the account state in the wallet; do not manually guess a new counter while the earlier payment remains unresolved.
- Authorize a rebuilt payment only when you understand why the original did not produce the intended transfer and still want the new action.
The official Tezos explorer guide lists tools for looking up operations and account history. If one interface omits the detail you need, use another appropriate view. An absent search result from one service is a reason to investigate its coverage and network, not proof that the operation can never appear.
A failed batch can be included without delivering its payments
The active protocol’s validation and application reference distinguishes inclusion validity from successful execution. It also explains why failed manager execution can still involve fees and counter advancement. Counter progress is consequently a poor substitute for reading the actual transfer result.
Manager batches have multiple contents under a shared submission. The blocks and operations reference describes their sequential, atomic application. Results such as backtracked, failed and skipped need attention: a payment-looking content inside an included group is not enough to prove that the payment took effect.
For example, a fictional batch might contain a transfer followed by an unsuccessful contract action. The explorer’s top line can show the group in a block while the detailed results explain why the intended business actions did not survive. Do not send the same amount again until you have reconciled those contents. Read the current counter afresh instead of reconstructing it from the number of rows you can see.
A future counter is a different ordering problem
“Counter in the future” means the request is ahead of the expected value in the checked context. It can require resolving earlier operations rather than waiting an arbitrary number of minutes. Ask which earlier action the wallet assumes has happened. A missing predecessor does not become included merely because you increased the fee on a later request.
The useful distinction is between the application’s planned queue and the chain’s observed state. Stop creating extra drafts while comparing them. If several apps use the account, coordinate that activity first. A support request should identify each attempt separately so that “retry” does not conceal two different hashes with the same intended recipient and amount.
Restore a consistent workflow without treating a reset as cancellation
Use the wallet’s documented refresh or recovery process when its local state disagrees with the chain. Clearing an interface’s history does not establish that a previously signed operation is cancelled. Before reinstalling or resetting anything, preserve your normal backup and the public operation evidence; do not send recovery words to support or use a stranger’s counter-repair website.
A complete support note can say: “Mainnet, this sender, this original hash, expected counter X and found Y at this time; these later operations are included; these attempts remain unresolved.” It should also say whether the destination is a wallet or a service. That makes the unresolved question visible without turning an ordering error into an unsupported claim of lost funds.
For an exchange deposit, chain execution and service credit remain separate checks. The XTZ asset page provides coin context, while the transaction-hash guide covers finding the public identifier. Before starting another simple swap, reconcile the earlier payment and check the current order’s instructions. A new order will not resolve an old counter conflict by itself.
FAQ
Can Tezos transactions advance the counter without paying my recipient?
Yes, an included manager operation can fail in execution, so counter movement alone is insufficient evidence of a payment. Inspect the relevant contents, results and recipient changes.
Will a larger Tezos transaction fee fix counter in the past?
A larger fee does not make a stale counter equal the expected value. First reconcile earlier operations and refresh the account state before deciding whether a new transfer is needed.
Does a pending Tezos transaction mean its fee and transfer are final?
No, a local pending item or node mempool observation is distinct from an included result. Check the operation on the correct network and read its execution outcome before accounting for the payment.