If Sui says an object is locked, stop creating competing transactions and identify the affected object and its version. A reservation for an earlier transaction may clear when that transaction finishes; an equivocated object may remain unavailable until the next epoch. A stale reference or a delayed transaction lookup needs a different response.
Read the complete error before restarting the wallet
A wallet's total SUI balance does not identify the input that caused a failure. In object-based transactions, the wallet can need a particular version of a coin or another owned object. Two actions can conflict even when their combined amounts look affordable. The useful evidence is the transaction digest, affected object ID, version and full error, rather than a screenshot showing only the balance.
The official common-error reference distinguishes an object reserved for another transaction from one equivocated until the next epoch. Do not turn every failed approval or slow spinner into an equivocation diagnosis. An application can also fail before submission, lose an RPC connection or build a request with outdated inputs.
| Evidence in the message or history | What to investigate | Next action |
|---|---|---|
| Reserved for another transaction | Earlier operation using the same owned-object version | Resolve that operation before building a competing one |
| Equivocated until the next epoch | Conflicting reservations that prevented quorum | Wait for the indicated epoch transition, then refresh and rebuild |
| Outdated object reference | Another transaction already changed the object | Retrieve current state after checking what the earlier transaction did |
| Digest lookup finds no record | Submission or the queried node's state is uncertain | Check a trusted source and preserve the original attempt |
| Finalized transaction has failed status | Execution finished with an error | Read the failure; do not report the intended payment as successful |
Why two ordinary actions can need the same object
Sui's object-versioning documentation explains that an update retains an object's ID while writing a later version. A reference to the old version does not become current because the wallet retries it. Mutable inputs cannot be independently consumed twice at the same version. Shared objects use different scheduling rules, so a busy application's shared object is not automatically your wallet's equivocated coin.
Consider a fictional wallet with a coin object labelled Cedar. One tab builds a transfer using Cedar at version 12; another tab builds a different action with that same reference. Even if the displayed balance could cover both, the two drafts have not coordinated their input. If the first action succeeds, the second must use the resulting current state rather than insist that Cedar version 12 is still available.
The conflicting object may also be a gas coin. Sending more SUI to the address does not rewrite a previously signed transaction's inputs. Current address-balance documentation also describes gas payments that do not select coin objects, where enabled and supported. Therefore, neither 'all Sui payments lock a gas coin' nor 'a gas top-up always fixes this' is a reliable diagnosis.
Check whether the first transaction actually finished
- Pause extra wallet tabs and applications that can submit actions from this account. Keep the original error and any transaction digest.
- Confirm the network before comparing wallet history, an explorer and the receiving platform. A test-network record does not settle a mainnet payment.
- Look up each existing digest through a trusted Sui data source. Record whether it is missing, finalized successfully or finalized with an execution error.
- Inspect the effects and object changes where available. Check which earlier operation used or changed the object named in the error.
- If the payment succeeded, reconcile the recipient and amount before making another payment. If it did not, choose the response for the actual error category.
The transaction lifecycle guide separates finality from a node or indexer's ability to display the result. Finding a finalized record still requires reading its execution status: finalized does not always mean the intended transfer succeeded. Conversely, one node's missing result does not establish that the transaction never reached the network.
Resubmitting the same signed transaction is different from asking a wallet to construct a new payment. The lifecycle documentation describes the former as idempotent. A new transaction can have different inputs or a different digest and must be assessed separately. If the wallet exposes only a vague Retry button, ask its support what that button does before using it repeatedly while the first result is unresolved.
When waiting for the next epoch is justified
Wait for an epoch transition when the actual error identifies equivocation until the next epoch. The epochs reference describes how competing owned-object transactions can split reservations and leave an object unavailable. This is narrower than a generic connectivity problem or a reservation held by one transaction that can still finish.
Do not translate this into 'wait 24 hours from the error.' The relevant event is the network's epoch change, and the remaining interval depends on when the problem occurred. After that transition, refresh the account and build from current object references. Do not assume an old signed draft is now the correct payment or that the receiving service's order is still valid.
Prevent another conflict and prepare a useful support report
For a normal wallet workflow, finish one unresolved action before starting another that may reuse its inputs. Developers should coordinate execution across their own clients. Mysten's executor documentation warns that other wallets or multiple executors using the same source coins can interfere with a managed gas pool. Installing another wallet does not itself coordinate those clients.
- Send support the network, wallet/app version, complete error, digest if present and affected object ID; explain which action came first.
- Separate public transaction evidence from secrets. A seed phrase or private key is not needed to explain an object reservation.
- Ask whether the suggested retry resubmits the original signed transaction or constructs a new one.
- If an exchange order is involved, confirm its current receiving details before authorizing a replacement payment.
Use the SUI coin page to keep the asset context clear. If you later use a no-account swap, compare the network and current order instructions after resolving the wallet error. A wallet lock does not establish an exchange credit or refund entitlement; service-side checks are separate, including the circumstances described in the AML policy.
FAQ
What does Sui equivocation mean for a locked wallet object?
Competing transactions can reserve the same mutable owned-object version in a way that prevents either from obtaining quorum. The specific equivocation error calls for waiting until the next epoch and then using current references.
Why can my Sui wallet transaction history show no result?
The queried node or indexer might not yet know about the transaction, or submission may not have completed. Preserve the digest and check a trusted source before assuming the first payment is safe to replace.
Does Sui equivocation mean my whole wallet has been frozen?
The error concerns affected object versions, not proof that every asset or the account itself has been administratively frozen. Read the exact object and transaction evidence before attempting other actions.