NFT marketplace listing states, evidence and next actions

Listing states connect intent, authorization and availability

A usable listing depends on separate functions that can succeed or fail independently.

The chosen terms express an intent to sell: they identify the token, requested consideration and any expiration or quantity. Authorization gives a contract or operator the power needed for the settlement design. An order communicates the signed terms to the marketplace or its order system. Availability means that the order is accepted, current and capable of being presented for execution.

These functions may use different records. An approval or escrow deposit can require an on-chain transaction, while an order may use a wallet message signature. Some designs record the listing itself on-chain. Others relay signed orders away from the chain until a buyer attempts settlement. The displayed state therefore needs to be read in the context of the action that produced it.

The evidence layers behind a usable listing

Useful evidence comes from the wallet, the blockchain and the marketplace order system. Each layer answers a different question. The wallet shows what the account approved or signed. The chain records successful transactions and contract state. The order system reports whether the terms were received and remain available under its settlement rules.

Authorization evidence

Authorization evidence should identify the account, token contract, requested function and receiving contract or operator. A successful receipt proves that a particular transaction executed. It does not prove that a separate signed order was created or accepted.

Approval state

Token standards can support approval for one token or an operator approval with wider scope. For ERC-721 and ERC-1155 contracts, an operator approval can cover assets held by the account under that token contract. Such approval may remain valid after an order expires. A valid approval is therefore a settlement prerequisite in some designs, not evidence of an active listing.

Order signature

A message signature can authenticate listing terms without submitting a blockchain transaction. The order may still need to pass format, expiration and ownership checks before the marketplace accepts it. Declining the signature request creates no signed order. Signing it does not create an on-chain approval or guarantee that an interface has published the order.

Open full-size image

Availability evidence

Availability belongs to the order rather than the approval. A usable status should match the intended contract, token identifier, seller account and terms. If the design holds the token in escrow, the custody record also matters. An active label can become stale after a transfer, expiration, cancellation or balance change, so displayed availability and settlement eligibility may diverge.

Pending, indexed and active answer different questions

Pending means that a required request has not reached a settled outcome. For an on-chain action, the transaction may still await inclusion or a successful receipt. For an off-chain order, the marketplace may have received a signature without finishing validation or publication. Repeating either request at this point can create another fee-bearing transaction or another signed order.

Indexed means that a service has processed the relevant chain event or order record for display. Active means the marketplace currently treats the order as available under its rules. A transaction can be confirmed before indexing catches up. Conversely, a stale card can remain visible after ownership, approval or order validity has changed. The label alone does not resolve the conflict.

Why can a confirmed transaction leave a listing unavailable?

A confirmed transaction may have completed only one prerequisite, such as an approval, revocation, escrow deposit or cancellation. The listing order might still be unsigned, rejected, expired or linked to different terms. The receipt must therefore be matched to the function that actually executed instead of being treated as proof of every later state.

Availability can also disappear after the account transfers the token, reduces an ERC-1155 balance below the offered quantity or removes a required approval. A mismatch between the selected network and the token contract can make an otherwise valid transaction irrelevant to the intended listing. When the receipt and order describe different objects, reconciliation should replace another blind attempt.

Waiting while evidence is still converging

Waiting fits a request that remains pending and still matches the intended account, contract and terms. It also fits an accepted order that has not yet appeared because the service is processing it. Preserve the transaction hash or order identifier when one is available, then check the same request rather than starting over. A changed account, failed receipt, expired term or rejected order ends the case for waiting and points to a different response.

Retrying only the missing layer

A retry belongs after the earlier request has reached a known failure state. A rejected message signature can be requested again if its displayed terms remain correct. A reverted transaction may be resubmitted only after the cause has been addressed, and an included failure can still consume a network fee.

Open full-size image

The retry should target the missing layer. If approval succeeded but the order was never accepted, repeating the approval adds no listing. If the order exists but the interface is behind, creating another order can leave multiple signed terms to manage. Compare the account, contract, token identifier, quantity, consideration and expiration before authorizing a replacement.

An unresolved status is not a failure result. Where the wallet, chain record and marketplace disagree, another signature can complicate the evidence and may expand exposure. Reconcile those records first.

Revising terms without leaving stale orders behind

Terms should be revised when the intended amount, settlement asset, quantity or expiration differs from the signed order. Many order-based designs treat a revision as a new order rather than an edit to the old one. The earlier order may require its own cancellation, invalidation or expiration under the marketplace's rules.

Changing terms does not repair an ownership or compatibility problem. A new amount cannot make the wrong token contract correct, and a later expiration cannot restore an approval that settlement needs. Track the old order's status during the change so that two apparently active sets of terms are not mistaken for one updated listing.

Open full-size image

Reconciliation separates chain facts from marketplace records

Reconciliation is appropriate when the expected listing and the observed state no longer agree. Begin with identifiers that should remain stable: the network, token contract, token identifier and seller account. Names, thumbnails and collection labels can be copied or delayed, so they cannot settle an identity conflict.

Ownership and approval records

For an ERC-721 token, the ownerOf query returns the address recorded as that token identifier's owner. ERC-1155 ownership uses a balance for an account and token identifier, so the quantity matters. These records establish whether the seller still controls enough of the offered asset.

Approval state answers a narrower question: whether the required address can act under the token contract. Review the successful receipt and current contract state together. A past approval event alone does not establish current settlement authority. A later revocation or ownership change may have altered it.

Order and interface records

The order record should match the same asset and account, along with its consideration, quantity and expiration. Its status can distinguish accepted, active, filled, cancelled, expired or invalid states when the marketplace exposes those distinctions. A search card or cached profile view may omit that detail.

If chain ownership has changed, a stale active card cannot restore the seller's ability to settle. If ownership and approval still match but the order was rejected, chain evidence does not create the missing listing. This division identifies which record needs attention without treating every mismatch as a reason to repeat every step.

Stop conditions protect ownership and funds

Stop when a request names an unexpected token contract, operator, recipient, network or settlement asset. The same applies when the connected account does not control the listed token, the displayed quantity exceeds its balance or the signature no longer matches the intended terms. A status conflict should remain unresolved until the identifiers agree.

An unknown operator approval deserves particular attention because its scope may extend beyond one listing. Repeated fee-bearing transactions also deserve a pause when the earlier transaction lacks a known outcome. Refusing the mismatched request preserves the account's present state and avoids paying for an action that cannot produce the intended listing.