NFT Bid Scams and Fake Token Offers Explained

2026-09-03

An offer lands on your item for 12.5 ETH while the collection has been changing hands near 0.5 ETH. The number is real in the sense that somebody signed it into an order. What the number does not tell you is which token it is counted in, and that one field is where the trade you think you are accepting becomes a different trade.

NFT Bid Scams and Fake Token Offers Explained: key points at a glance

What a bid actually is

A bid, also called an offer, is the buy side of the same signed-order design that carries a fake listing on the sell side. The bidder sends money nowhere. They sign a message naming an item, an amount, a currency contract and an expiry, and the marketplace stores that signature and renders it as a row on your page.

Nothing has moved on the chain at that point. The transfer happens when you accept, because your acceptance is the transaction that fills the order, sends the NFT out of your wallet and pulls the bidder's tokens in. You are the party who submits it, which makes reading the order your job rather than the bidder's.

EIP-712, the Ethereum standard for hashing and signing typed structured data, is what gives these messages a readable shape. It was written against the situation it describes, in which signed messages are an opaque hex string displayed to the user with little context about the items that make up the message. Structured signing made an offer legible. It did not make an offer honest.

The currency line decides what a bid is worth

An offer carries an amount and the address of the token that amount is counted in. The page puts the amount in large type and the address nowhere. That layout is the whole opening, because an amount is only ever a quantity of whatever the second field points at.

Token symbols do not identify anything. Under ERC-20 both name and symbol are optional, and the standard states that the method can be used to improve usability, but interfaces and other contracts must not expect these values to be present. A deployer picks those strings freely, so a contract whose symbol reads exactly like a wrapped ether contract costs one deployment to create and can be minted in whatever quantity its author wants.

An offer denominated in such a token is not a forgery, and it would settle exactly as written: you hand over the item and receive the stated number of units of a token that has no buyer behind it. The check is therefore an address comparison, and ERC-721 makes the same point on the item side when it calls the pair of contract address and token ID a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. Identity lives at the address. Symbols are labels drawn on top of it.

Why the size of a bid proves nothing

An offer 25 times above the level a collection has been trading at reads as a windfall and states something far weaker: what one address says it would pay. Saying it costs nothing. The offer can be cancelled before you reach it, and it stops on the expiry written into it.

Bids can also be produced deliberately to be looked at. Offers placed between addresses under one operator create an appearance of demand in the way that wash trading creates an appearance of volume, and neither the marketplace page nor the chain records who controls which address.

The practical form of this is a bid built to be seen rather than filled. It anchors a seller on a number, or it pulls attention onto a collection while other items in that collection are sold into the attention. Treat an offer as one address making a statement about itself, and keep the level the collection actually trades at as the separate question it is.

The offer that is really an approval request

Some offer notifications are not offers. The page exists to put a signing prompt in front of you, and what it asks for is standing permission over your collection rather than a sale. ERC-721 defines setApprovalForAll as enabling or disabling approval for a third party, called an operator, to manage all of the caller's assets, and an operator holding that permission can move every item in the collection without asking again, which is the mechanism behind a wallet drainer.

The currency side has its own version. ERC-2612 adds a permit function so an allowance can be set from a signed message instead of from a transaction the holder sends, with the signed data structured according to EIP-712. A token approval that arrives this way leaves no transaction to notice at the moment you sign, and ERC-20 already warns that calling approve again overwrites the current allowance with the new value.

EIP-712 also gives you the field that separates a real prompt from a copy of one. Its domain separator names the contract a signature is valid for, and the rationale explains that the separator prevents collision of otherwise identical structures, since two applications can arrive at an identical structure that should not be compatible. The specification anticipates that user agents may do contract specific phishing prevention on that basis. In practice that means reading the verifying contract inside the decoded prompt before reading anything the page wrote around it.

Bids that arrive from outside the marketplace

An offer that reaches you as a direct message, an email, or a link inside an item somebody airdropped into your wallet has skipped the only part of the process that was ever checkable: the marketplace interface you opened. A message can reproduce that layout precisely, because the layout is public.

The habit that closes this is to reach the marketplace through an address you saved yourself and look for the offer there. An offer that exists will be on your item page. One that exists only in the message is not an offer, and the thing waiting at the end of the link is the prompt.

What an offer row can and cannot promise

What the row shows	What it is	What it settles
The amount	A field in the signed order	Nothing on its own
The currency symbol	Free text chosen by the token deployer	Nothing
The currency contract address	The identity of the asset offered	What you would actually receive
The expiry	A field in the signed order	The latest it can be filled, not the earliest it can be withdrawn
The bidder's holdings	Not part of the order at all	Nothing, though a short balance makes the fill revert

Read down the middle column and the pattern is that every line except one is a claim, while the address line is an identity. That is the line worth your attention, and it is the line the interface renders smallest.

What to check before you accept

Check	Compare it against	What a mismatch tells you
Currency contract address	The address the issuer publishes itself	You are being paid in a different asset
Item contract and token ID	The item you believe you are selling	The order points at something else
What the prompt authorizes	The action you intended	You are granting access, not selling
The verifying contract in the prompt	The marketplace you opened yourself	The signature is for somebody else's contract
Standing approvals on the collection	The operators you meant to authorize	Permission granted earlier is still open

Order matters here. The currency address comes first because it decides whether there is a trade at all, and the signature check comes before the price check, because a prompt that grants access does not care what the price on the page said.

The bottom line

A bid is a signed message with several fields, and a marketplace renders one of them large. The amount is the field that persuades, the currency address is the field that decides, and the two are never shown at the same size. Reading the second one is the entire defence against an offer denominated in a token that copied a symbol.

The other half is the prompt. Accepting an offer is a sale that moves one item and pays you for it, while a request for operator permission over your collection is not a sale at all: it costs nothing at signing time and grants everything afterwards. Check the currency address, check what the signature authorizes, and reach the marketplace by an address you typed yourself. To keep learning the fundamentals, follow more from Bitbase Academy.