Looks rare
Looks rare Preflight Checks for Trade Route Choices
- last updated
Looks rare route selection turns on whether the order can still execute from the wallet’s present state. Before approval, signature or transaction, match the asset, payment token, order source, expiry and total debit; after submission, accept completion only when the receipt and resulting on-chain asset state agree.
Shared settlement mechanics and route-specific terms
Each route either creates a maker order or attempts on-chain settlement against an existing order. The important differences sit inside the order and the contracts that will handle it.
A useful comparison keeps the dimensions identical: collection contract, token ID, payment asset, order validity, execution price, additional fees and required authorization. An aggregated listing may originate from another marketplace and execute through a source-specific proxy. A native order follows the Looks rare protocol’s own strategy. Either path can become stale if ownership, balance, approval, expiry or nonce state changes before execution.
The commitment boundary between intent and transfer
The commitment boundary changes with the wallet request. The protocol uses EIP-712 signatures for maker orders that remain off-chain until a matching taker transaction executes them. A signature and a settlement transaction therefore leave different evidence.
Off-chain order intent
A maker order records terms such as the signer, collection, currency, price, validity window and nonce values. Signing that order doesn’t transfer the NFT or payment asset immediately. It creates executable intent that another party may later match, provided the order and its supporting approvals remain valid.
On-chain settlement authority
A settlement transaction asks a contract to match the order and transfer the relevant assets. The wallet prompt should identify the active account, destination contract, network, value and requested method clearly enough to compare with the review screen. Rejecting the prompt leaves the proposed transaction unsubmitted.
An approval is separate from both signing and settlement. It grants a contract or operator authority within a defined token scope, but it doesn’t prove that a sale occurred. Check whether the request concerns an NFT operator approval, an ERC-20 allowance, an order signature or the final execution because each changes a different part of the wallet’s state.
Seven-stage evidence path from selection to confirmation
This sequence follows the smallest safe action at each stage. Each row names the evidence needed before proceeding and shows where control remains.
| Stage | Evidence to match | Custody or control |
|---|---|---|
| 1. Set wallet context | Intended account, required network and spendable assets for the order and gas | The wallet controls the account and its assets. |
| 2. Identify the NFT | Collection contract, token ID, token standard and quantity | The present holder retains the NFT before settlement. |
| 3. Select the order | Order source, payment asset, expiry, price and current executability | The maker retains custody of the offered asset after signing a passive order. |
| 4. Review the commitment | Destination contract, total wallet debit, recipient and route terms | Reviewing, approving or signing alone doesn’t settle the trade. |
| 5. Authorize the route | Exact approval, allowance or signature scope requested by the chosen path | The request’s approval, allowance or signature terms define its scope. |
| 6. Submit settlement | Wallet transaction details that still match the reviewed order | The user submits the transaction; contracts apply its encoded rules. |
| 7. Reconcile the result | Successful receipt plus matching NFT ownership or balance and payment movement | The final on-chain state shows what the settlement changed. |
| Acceptance boundary: the receipt and resulting asset state agree | A page message alone doesn’t establish custody. | |
On the normal path, the successful receipt and resulting token state match the reviewed trade. If the receipt is missing, pending or reverted, or the ownership record disagrees, stop before retrying. First determine whether no transaction ran, the transaction failed or another state change made the order unusable.
Which route fits the wallet’s current state?
The suitable route is the one whose required asset, authorization and timing match the wallet now. A displayed amount alone doesn’t establish that fit.
Fixed-price execution
A fixed-price purchase attempts to settle a specific ask. It suits a wallet that can satisfy the named payment and gas requirements immediately. Preflight should still confirm that the seller owns the token, the order hasn’t expired and the final wallet request targets the expected settlement path.
Token and collection offers
A token offer targets one NFT, while a collection offer may be accepted with an eligible item from the named collection. The documented offer flow uses WETH, so the relevant balance and allowance differ from native ETH held for gas. A signature can make the offer live without completing a purchase.
Aggregated orders
An aggregated order can expose inventory from another marketplace through the Looks rare interface. Its originating order still determines the asset, currency and executable terms, while a source-specific proxy handles that route. Compare the final contract call and total debit with a native order rather than assuming identical cards imply identical settlement.
Approval scope and wallet authority
Marketplace permissions deserve their own preflight check because prior activity can change the next prompt. An NFT operator approval may authorize transfers for tokens in a collection. An ERC-20 allowance authorizes a spender up to its permitted amount. Native ETH doesn’t use an ERC-20 allowance, although the execution transaction still needs wallet confirmation.
An existing permission can remove a preliminary transaction from the flow, but its absence doesn’t make the route suspicious by itself. Likewise, a new approval isn’t proof that the following order remains executable. Read the spender or operator, asset contract and scope before confirming. If those details don’t correspond to the selected route, don’t continue from that prompt.
Cost components at the final review
The executable total combines values that affect different parties. The order price sets the trade amount. Protocol or creator fees may affect settlement proceeds, while network gas pays for transaction execution. An aggregated source can also apply the terms encoded by its originating order and settlement contract.
Normalize competing routes at the wallet boundary. Compare the same NFT and quantity, the same payment asset, the transaction value and any displayed fee lines. Keep the gas estimate separate because it can change before inclusion. A lower card price may require a different payment state or authorization. Check the final wallet request before choosing the route.
Contract identity and token quantity
Asset identity comes from the collection contract and token ID, not only the collection name or image. A copied name can describe a different contract. Match those identifiers before reviewing price or rarity because a perfectly executed transaction for the wrong contract still delivers the wrong asset.
Token standard changes the quantity check. ERC-721 represents individually identified tokens, so the relevant quantity is one token ID. ERC-1155 can record multiple units of the same token ID. A route for an ERC-1155 asset therefore needs the intended quantity beside the contract and token ID before commitment.
Receipt evidence and ownership records
Confirmation evidence begins with the transaction receipt. A transaction hash can remain pending or lead to a reverted receipt, so its existence doesn’t prove settlement. A successful receipt shows that the included call completed, but the resulting token and payment state still need to match the intended order.
ERC-721 records one owner address for each token ID. ERC-1155 instead records a balance for an address and token ID. Check the applicable ownership or balance record against the recipient named by the route. Interface updates can lag behind the chain, making the token record and successful receipt stronger completion evidence than a transient success banner.
Recovery boundaries for stale or incomplete results
A failed or ambiguous trade should be classified by its observable symptom before another wallet action. Retrying without that distinction can duplicate a pending submission or repeat a route whose order is already invalid.
No transaction appeared
An absent transaction may mean the wallet request was rejected, never submitted or only requested an off-chain signature. Check the wallet activity and the action type. A signed offer or listing can exist without a transaction hash, while a purchase execution should produce one after submission.
The receipt shows a revert
A reverted receipt means settlement didn’t complete, although the network can still charge gas for processing the failed call. Recheck expiry, current ownership, payment balance, allowance, approval and cancellation state. If one of those inputs changed, refresh the order rather than resubmitting the same stale data.
Only part of a batch changed state
A mixed batch outcome depends on the route’s execution mode. Some multi-order executions are atomic, so one failed purchase reverts the entire transaction. A non-atomic multi-purchase can preserve successful matches when another order in the same transaction fails. The receipt events and final token records reveal which items settled; the cart summary can’t settle that question.
The next action after reconciliation
Continue when the order terms, wallet request, successful receipt and resulting token state agree. If they don’t, resolve the specific mismatch before creating another transaction. Choose the alternative with verifiable terms when another route shows an attractive amount but unclear authorization.
Looks rare: common questions
Can an ETH purchase and a WETH offer be compared by displayed amount alone?
No, an ETH fixed-price purchase and a WETH offer represent different actions. The purchase attempts immediate settlement against an ask, while the offer creates a passive bid that must later be accepted. Compare the payment asset, authorized amount, expiry, fee treatment and gas for each path; an equal displayed numeral doesn’t make the wallet states interchangeable.
What happens if an order expires while the wallet prompt is open?
The order becomes unexecutable if its validity window ends before the settlement transaction satisfies the contract’s checks. An already-open prompt doesn’t extend that window. Cancel the stale prompt, refresh the order state and review any replacement terms from the beginning. Submitting unchanged data may produce a revert and consume gas without transferring the NFT.
Does a pending purchase transaction reserve the NFT for me?
No, a pending transaction doesn’t guarantee that the NFT or order remains available. Another valid transaction may transfer the token, consume the order or change relevant state first. Monitor the pending submission instead of sending immediate duplicates. When it receives a receipt, use that status and the resulting ownership record to decide whether another action is appropriate.
When should an old marketplace approval be revoked?
Revoke an approval when you no longer want the named operator or spender to retain that authority. Revocation requires its own on-chain transaction and affects future execution; it doesn’t reverse a completed trade. It may also leave a signed order visible even though that order can no longer settle, so cancel the order separately when removing the intent matters.
How can I verify an ERC-1155 quantity after settlement?
Check the recipient’s balance for the exact ERC-1155 collection contract and token ID. ERC-1155 uses balances rather than the single-owner record used by ERC-721. Compare that balance change with the quantity in the reviewed order and the successful transaction receipt. For a batch, inspect each intended token ID because one matching balance doesn’t confirm every item.