> For the complete documentation index, see [llms.txt](https://crosschain-docs.gitbook.io/crosschain-docs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://crosschain-docs.gitbook.io/crosschain-docs-docs/contract-tokens-for-beginners-what-a-rejected-wallet-means.md).

# Contract Tokens for Beginners: What a Rejected Wallet Means

A destination wallet that rejects a token can stop a transfer only when the token or transfer method checks with the wallet; ordinary ERC-20 transfers usually do not. That difference matters when a bridge says “complete” but the token is missing from the wallet screen, or when a transfer transaction fails.

Imagine Maya bridges a small amount of bitcoin and expects renBTC in a smart-contract wallet. The bridge reports a destination transaction, but the wallet shows no balance. Before trying again, she needs to find out whether the tokens arrived but are hidden, or whether the destination transaction actually failed. [RenBridge](https://chainbrief.org/renbridges-ethereum-to-solana-stablecoin-route-explained/) used RenVM to mint wrapped assets on a destination chain, so its case is a useful example of how a bridge’s mint step and a wallet’s display are separate things.

### A wallet can hide tokens without rejecting them

A wallet app can choose which tokens to display, but the address on the blockchain holds the token balance. For a standard ERC-20 token, the token contract updates that balance when it transfers or mints tokens; it does not normally ask the receiving address for permission.

EIP-20, the ERC-20 standard, defines transfers and balance queries but no required recipient callback. Ethereum.org explains the practical consequence: an ordinary contract can receive ERC-20 tokens without knowing that they arrived. So a token missing from a wallet’s asset list may simply need to be added by its verified contract address.

There are exceptions. Some token standards and token-specific transfer functions call a recipient contract and can revert if it lacks the right receiver function. In that case, the transaction fails and the balance change is rolled back. A wallet’s “unsupported token” message alone does not tell you that this happened.

### The destination transaction decides what happened

Check the destination chain’s transaction record before resending. A successful transaction that minted or transferred tokens to the correct address means they arrived on-chain, even if the wallet app does not recognize or display them.

In Maya’s example, she should check the destination transaction hash in that chain’s block explorer, then inspect the token’s contract page and the recipient address balance. If the transaction succeeded and the balance is nonzero, she can add the token using its verified contract address and confirm the network matches. If the token contract shows no balance increase—or the transaction reverted—the explorer’s status and event details help distinguish a failed mint from a display problem.

A bridge may report a source deposit as complete before destination work finishes. RenBridge’s historical flow involved a source-chain deposit followed by RenVM authorizing a destination mint or release; those are separate steps. RenVM 1.0 shut down in 2022, so treat RenBridge as historical and do not assume its old interface can complete a new transfer today.

### Use these checks before taking another action

Work through the transaction in this order, keeping the destination address and network consistent throughout:

1. Open the destination transaction hash in the correct chain’s block explorer and check whether it succeeded, failed, or is still pending.
2. If it succeeded, verify the recipient address and token contract address in the transaction details or token transfer event.
3. Query the token’s balance for that exact recipient address using the explorer or a reputable wallet interface.
4. If the balance is present, add or enable the token in the wallet using the verified contract address; never select a lookalike token from a search result.
5. If the transaction reverted or no destination mint occurred, save both the source and destination transaction hashes and check the bridge’s own recovery instructions before retrying.

For example, if Maya sees a successful mint of 0.01 renBTC to her address but the wallet lists zero, she should verify the token contract and network, then import the token. If the destination call reverted, she should not send another source deposit until she knows whether the bridge can retry or recover the original request.

### Know what a failure costs and what can be recovered

A reverted on-chain transaction generally does not transfer the tokens, but the sender still pays gas for the computation used before the revert. The amount varies with the chain, congestion, and how much work the failed call performed; a displayed fee estimate is not a promise of the final cost.

Recovery depends on where execution stopped. A bridge may retry a destination action, offer a claim or refund process, or require support steps; these options are specific to that bridge and transaction. A successful ERC-20 transfer into an unprepared contract is different: the tokens may be stuck because the contract has no function to move them out. Do not pay a stranger who promises to “unlock” them or share a seed phrase to fix a display issue.

When comparing bridge designs, RenBridge is an example of a system that minted wrapped tokens on the destination chain, while a wallet’s ability to show or use those tokens depended on recognizing the token contract. The decisive check is the destination chain’s transaction and balance: import a verified token if it arrived, and follow bridge-specific recovery steps if the mint failed.