The mint page said success. The explorer shows a green tick next to the fee you paid. The wallet gallery is empty. Three systems are answering three different questions here, and only one of them is the chain. Before deciding that something went wrong, separate the question of whether a token exists from the question of whether an application is willing to draw it.
What a successful mint transaction certifies
A confirmed transaction tells you that your call reached a block and that the outermost piece of execution did not revert. That is the whole of it. A receipt status of success is a statement about the call, not an inventory of what the call produced.
A mint is a contract function like any other. It can finish without reverting and still have created nothing for you: a batch loop that skipped your entry, an inner call the contract deliberately absorbed, a payable function that took the fee and credited a different address. The receipt does not separate those from an ordinary mint, because it was never asked to.
So the question is not whether the transaction worked. It is whether a token now exists with your address written against it. That fact is recorded elsewhere, and it is recorded twice over: once as an event at the moment of creation, and once as a value the contract will answer with on request.
The event that says a token was created
A mint is not a separate operation in the ERC-721 token standard. It is a transfer with no sender. The standard defines a single Transfer event that emits when ownership of any NFT changes by any mechanism, and states that the event emits when tokens are created and when they are destroyed, with the sender field set to zero in the first case and the recipient field set to zero in the second.
That gives you an exact thing to look for. A transfer event on the mint transaction, from the zero address, to your address, carrying a token id, is the chain saying a token was created and assigned to you. Its absence is equally informative.
ERC-1155 follows the same convention on its own events: when tokens are minted, the sender argument must be set to the zero address. So the shape of the evidence does not change between the two standards, even though the wallet support around them can.
The read that settles who owns it
The event is a record of a moment. Ownership now is a separate read, and ERC-721 answers it directly. Call ownerOf with a token id and the contract returns the address it records as the owner. The standard adds that tokens assigned to the zero address are considered invalid and that queries about them throw, so a call that fails instead of returning an address is itself an answer: no token with that id is currently assigned to anyone.
Alongside it, balanceOf counts the tokens an address holds in that one contract. In a collection of 10,000 ids, ownerOf answers for exactly the id you name, and balanceOf answers how many of that contract's tokens sit at your address without you having to guess ids. Neither read depends on a marketplace, a gallery, or an image being available.
| The question you are asking | Where the answer is recorded |
|---|---|
| Did the transaction reach a block | The block number on the receipt |
| Did the outermost call avoid reverting | The receipt status |
| Was a token created for me | A transfer event whose sender field is the zero address |
| Who owns that id now | The address ownerOf returns for it |
| How many of the collection do I hold | The number balanceOf returns for my address |
| Will my wallet draw it | Nothing on the chain records that |
The last row is the one that resolves this whole situation. There is no on-chain field for whether an application displays your token, which is why an empty gallery is never by itself evidence about ownership.
Why the token can be yours and the wallet show nothing
A wallet gallery is not a live read of the chain. Nothing in either standard lets you ask a chain for every token an address holds across every contract, so wallets and marketplaces run indexers that watch transfer events, write down what they see, and serve you that record. What you scroll through is their table, not the contract.
Four things about that table can leave it empty while the contract says otherwise. The indexer may not have processed your block yet, in which case the gallery fills in on its own. The collection may be filtered as spam or unverified, which is a display rule the wallet applies and can be turned off. The wallet may index one standard and not the other, so a token minted under ERC-1155 shows nothing in a view built only for ERC-721. And a wallet that requires a collection to be added by hand shows nothing for it until that is done.
None of those is repaired by resubmitting anything on chain. Sending a second transaction because a gallery looks empty risks minting again and paying again for a token you already own.
When the token went somewhere else
The other family of causes is that the mint worked exactly as written and the token is not at the address you are looking at.
The recipient of a mint is decided by the contract, not by the interface. A function that mints to the caller credits whatever address signed the transaction, which is the account that was connected at that moment rather than the one now selected in the wallet. A wallet derived from one seed phrase holds more than one address, and the one you are viewing may not be the one that minted.
Smart contract accounts add a second version of the same mismatch. ERC-721 requires that a safe transfer check whether the recipient is a smart contract and, if it is, call the receiver hook on it and throw when the expected return value does not come back. A contract account that implements that hook receives the token normally, and the token then lives at the contract address. Any view pointed at the signing key rather than at the account will show nothing while the token sits safely where it was sent.
Then there is the network. The same address exists on every chain that uses the same address format, so a wallet set to one network renders an empty gallery for a token that was minted on another. The token is not missing. The view is filtered to a chain the token was never on.
When the token is there and only the picture is missing
A distinct symptom is a tile that is present but blank, grey, or labelled with a placeholder name. Here ownership is not in question at all: the wallet drew the token, which means it indexed the transfer event and the id.
What is behind the tile is the metadata document rather than the token, and the instrument for that is a metadata refresh, which tells the platform to read the pointer and the document again. A refresh moves nothing on chain and creates no ownership, so it is the right tool for a stale picture and the wrong tool for a token that never appears at all. Sorting these two apart before acting saves the hours that go into refreshing a token the wallet was never going to draw.
| What you are seeing | What is true underneath | What changes it |
|---|---|---|
| Empty gallery, transfer event to your address exists | The indexer is behind or filtering the collection | Waiting, a wallet setting, or adding the contract by hand |
| Empty gallery, no transfer event on the transaction | Nothing was created for your address | Read the contract before doing anything on chain |
| Token visible with placeholder or missing art | The stored metadata copy is behind the current one | A metadata refresh |
| Token visible on an explorer, absent in the wallet | The wallet does not index that standard or collection | A wallet setting, or a different viewer |
| ownerOf returns an address that is not yours | The token was minted or sent to another account | Look at that address instead |
What to check, in order
Open the transaction on a block explorer and read its logs rather than its headline. A transfer event from the zero address, with a token id, tells you a token was created. The address in the recipient field tells you whose it is. If that section is empty, the rest of the search is about the contract, not about your wallet.
Then call ownerOf on the contract with that token id. Explorers expose contract reads without a signature or a fee, so this costs nothing and returns the chain's own answer rather than an indexer's copy of it. If the address that comes back is one of yours, the token is yours and everything remaining is a display question.
Then check what you are looking at: the address selected in the wallet, the network it is set to, and whether the collection is hidden. Those three settings account for the gap between a contract that names you as the owner and a gallery that shows nothing.
The bottom line
A mint that confirms proves that a call did not revert. It does not prove that a token exists, and it does not name an owner. Those two facts live in the transfer event on the transaction and in what ownerOf returns afterwards, and both can be read without an application cooperating.
An empty gallery is a statement about an indexer. Read the event, read ownerOf, then check the address, the network, and the collection filter. If the contract names you as the owner, nothing needs to be sent, signed, or paid for again. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- Fractional Ownership of a Non-Fungible Token and Where the Risk Sits
- The NFT Reveal Process Explained: What Changes and When
- Optional NFT Royalties Explained
- The DATA Foundation, Formerly Story Protocol: the IP to DATA Token Migration
- Omnibus vs Segregated Wallets and Rehypothecation Risk
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Ethereum Improvement Proposals, EIP-721: Non-Fungible Token Standard, specification section eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, specification section eips.ethereum.org
