The App Shows Zero—What Does the Blockchain Prove About the Transfer?
A wallet balance is a display generated from blockchain and account data. Zero can mean that the sender never broadcast the transaction, the transfer is still pending, the destination belongs to another account, the wallet is reading the wrong network or the received token is not visible. Start with public transaction evidence before changing the application.
Most faucet rewards are tiny. FaucetPay can help you collect small payouts from supported faucets, PTC sites and reward platforms in one microwallet before withdrawing later.
Set up FaucetPay to collect small rewards →Use the Proof-Before-Display Protocol
Answer the questions in this order.
- Is there a real transaction hash?
- Which blockchain contains it?
- Is it pending, failed or confirmed?
- Does the destination equal an address you control?
- Is the received asset native coin or token?
- Does the wallet show that account and network?
No hash means the sender has not proven broadcast
A custodial app can say sent or processing before it creates a blockchain transaction. Ask for the network and transaction ID. Do not troubleshoot token display while the sender cannot demonstrate an on-chain event.
Pending is not a zero-balance display error
MetaMask recommends checking confirmation first. A transfer waiting in the network queue can appear in an explorer while the spendable balance remains unchanged or provisional.
Failed transactions do not deliver the asset
A failed contract interaction can still charge gas because network computation occurred. Check the explorer status and token-transfer logs rather than relying on the sender’s completed label.
Compare the full destination address
Open the receiving account and compare every character with the explorer destination. A wallet can contain several accounts, and a restored app can open a different account from the one used for the transfer.
The transfer exists only on its actual network
MetaMask states that a token appears on the network where it was sent. An EVM address can look identical across chains, but the balances belong to separate ledgers.
Native coin and token evidence differ
A native transfer changes the address’s chain balance. A token transfer appears through a contract event and may need manual display. Confirm the contract address and amount in the explorer.
Wrong account is more common after restoration
Accounts derived from one recovery phrase can require manual recreation in their original sequence. Addresses imported through separate keys or connected hardware devices belong to different recovery paths and will not appear merely by restoring another phrase.
A confirmed hidden token is not lost
If the explorer shows the token at the correct address, the ownership record already exists. Adding a verified token contract changes the wallet interface; it does not move or recover the asset.
RPC and connection problems affect display
When the explorer and address are correct but the wallet remains stale, restart the official app, switch networks and back, check connectivity and use a trusted alternative RPC if the wallet supports it.
Do not import a seed phrase into a random repair site
Public transaction data is enough for diagnosis. A support agent or recovery page that asks for a recovery phrase, private key or remote access is attempting to gain control rather than fix the display.
Do not send a second transfer yet
Repeating the payment can create a duplicate or reproduce the same network mistake. Finish the evidence trace for the first transaction before moving more value.
Use a Zero-Balance Incident Card
Record the transaction hash, network, status, destination, token contract, wallet account, app version and explorer balance. This gives legitimate support enough information without revealing secrets.
Worked proof sequence
A USDT transfer is confirmed to the correct address on BSC. The wallet is open on Ethereum and therefore shows zero USDT. Switching to BSC and displaying the verified contract resolves the interface without another transaction.
Current conclusion
A zero wallet display should be treated as an evidence problem first. Prove broadcast, confirmation, destination and network, then adjust the wallet account or token display only when the chain record supports it.
Evidence boundaries
MetaMask documentation supports checking confirmation, network, token visibility and restored accounts. Custodial senders and non-EVM wallets can use different processing and account models.
Transfer-display documentation — July 29, 2026
Transaction, network and account-restoration guidance supports the protocol.
- MetaMask missing balance guide: https://support.metamask.io/manage-crypto/tokens/what-to-do-when-your-balance-of-tokens-is-incorrect/
- MetaMask restoring accounts: https://support.metamask.io/configure/accounts/how-to-add-missing-accounts-after-restoring-with-secret-recovery-phrase/
- MetaMask wrong-network guidance: https://support.metamask.io/manage-crypto/move-crypto/send/funds-sent-on-wrong-network/
Be careful with websites that promise unrealistic rewards, ask for deposits before withdrawal, or require suspicious wallet connections. Small reward sites should never need your seed phrase.
FAQ
What should I request from the sender first?
Request the transaction hash and the exact network used.
Can a confirmed transfer still show zero?
Yes. The wallet may show another account, another network or omit the token contract.
Does importing a token move it?
No. It only changes how the existing on-chain balance is displayed.
Should I send the asset again?
No. Finish tracing the original transaction before creating another transfer.
Does support need my seed phrase?
No. Public transaction and address information is sufficient for legitimate diagnosis.