Check a crypto claim without connecting a wallet

Rewrite the claim as something testable

“This token is official” is too vague to verify. Official according to which issuer, on which network and at which contract? “My transaction is complete” also needs a definition: accepted by the sender, included onchain or credited by the receiver? Begin by rewriting the statement so that you could describe the evidence needed to accept or reject it. This improves research before you open any tool.

Use this fictional example throughout the guide: a message says that an asset called ABC can be deposited to an exchange over BSC today. The message contains no reliable contract address and links to a reward page. Our task is to investigate the deposit claim, not to claim the reward, connect a wallet or send funds. Separating the question from the action prevents the message from defining the research process for us.

Choose the source responsible for the fact

For an exchange deposit route, the receiving exchange's current asset and network instructions are the relevant operational source. For a chain ID, use the network documentation. For a token's claimed identity, consult the issuer's documented contract information. For a transaction's execution, inspect the record on the correct network. A news summary may lead you to evidence, but it cannot replace the source responsible for that specific fact.

Primary does not mean infallible or independent. A provider describes its own product and may use promotional language. Separate its operational specification from claims about quality or future performance. If two official pages conflict, check product, version and date; do not silently choose the answer you prefer. Record the conflict and pause if it affects an irreversible action. The absence of clear evidence is a research result, not permission to guess.

Evidence: Binance deposits · BSC network data · BEP20 token-contract interface specification

Scope: general receiving-network checks, not a current list of supported routes. This FAQ still includes legacy Beacon Chain/BEP-2 examples. Those examples are not current onboarding; the Phase 3 notice describes a separate recovery process. Check the authenticated receiving screen for actual support. Phase 3 status notice for the discontinued hosted tool and BEP-2/BEP-8 self-service scope

Used only for the BEP20 token-contract interface and the methods/events named in the specification. It does not prove that a particular deployed contract conforms, is authentic, safe, issued by a named party, backed by reserves or equivalent to an asset on another network. The file contains historical Beacon Chain wording that is not treated as current migration guidance.

Verify the exact object before comparing information

For the fictional ABC claim, write the network and contract as separate fields. A symbol or logo can be copied. Check that the issuer's documented contract and the receiving service's supported representation refer to the same thing. Do not assume that an asset issued on one network is identical to every bridged or wrapped version using its name elsewhere.

For a transaction claim, record the network and hash. An explorer result for an address is not the same thing as a receipt for one transaction. An exchange support ticket number is not a blockchain hash. If a screenshot omits those identifiers, you may be unable to reproduce its conclusion. Ask what specific record would resolve the uncertainty, while keeping personal account information and secrets out of public research notes.

Evidence: Explorer interpretation · Bridge risks

This Binance Academy article is an orientation to BscScan; it does not verify any live token, holder, price, liquidity-lock or contract claim.

General bridge concepts from ethereum.org. Designs differ; this source does not verify any named bridge, BTC representation, issuer backing or redemption promise.

Read what a status label can and cannot prove

A source-code verification label means something narrower than a security audit or a guarantee about contract behavior. The source may be visible while administrative powers, upgrade paths or logic still require analysis. Likewise, a transaction marked successful can demonstrate an execution outcome without proving that an exchange credited an account. Avoid expanding a technical label into a conclusion about safety, ownership or financial strength.

For our fictional deposit claim, a token page in an explorer would establish that a contract record exists, not that the exchange currently accepts it. A successful historical transfer would show a past event, not necessarily today's route availability. The correct evidence must answer the actual question. This is why researching the supported route starts at the receiver rather than at a screenshot of a familiar token logo.

Evidence: Explorer interpretation · Deposit troubleshooting

This Binance Academy article is an orientation to BscScan; it does not verify any live token, holder, price, liquidity-lock or contract claim.

Attach the date and version to operational claims

Instructions can become outdated after a network retirement, service suspension or application change. Check whether the page describes the current product, an old interface or a historical event. The Beacon Chain recovery notices illustrate why a dated migration flow should not be copied into routine onboarding. A procedure can be accurate about its historical context and still be the wrong procedure for today's task.

Write down when you consulted the source and any explicit effective date. If you did not open the app, do not claim that you tested its current screens. If you did not submit a transaction, describe a documentary review rather than an execution test. A source date tells readers when the statement was checked; it does not make all future versions equivalent. Recheck time-sensitive conditions before acting.

Evidence: Phase 3 status notice for the discontinued hosted tool and BEP-2/BEP-8 self-service scope

The dated notice says the hosted recovery tool was discontinued effective 2026-07-01 and describes a self-service tool for BEP-2 or BEP-8. This is a status description, not proof of individual asset eligibility or recovery success. The education page deliberately omits setup, signing and transaction instructions.

Keep a short evidence record and a narrow conclusion

A useful note has five parts: the precise question, the exact entity or contract, the primary source URL, the relevant date and a conclusion with limits. For the ABC example, an honest result might be: “The issuer contract was identified, but current receiving-service support was not established; no transfer attempted.” That is more useful than “probably supported” based on a symbol match.

Distinguish confirmed, contradicted and unresolved. Do not convert unresolved into false, and do not convert “no problem found in the checks performed” into “safe.” These categories describe evidence, not feelings. You can share a sanitized record with support or another reviewer without including recovery material, authentication codes or private account screenshots. State which checks were omitted so the next person knows what remains to investigate.

Do not bypass a warning to finish the research

A browser or wallet warning is a reason to stop the proposed interaction. You can consult official documentation and investigate the domain without authorizing its requests. A statement that a site is educational does not resolve an external reputation warning. Nor does a redesigned page demonstrate that a classification was erroneous or has been removed. Keep the warning's status separate from a content review.

Finish this exercise by explaining why the fictional message is insufficient evidence for the deposit claim. You should be able to identify the missing contract and receiving-service confirmation without visiting the reward flow. The skill being practiced is a reproducible investigation with an honest stopping point. There is no need to sign, pay a fee or reveal a secret to demonstrate that you understand the evidence.

Evidence: Security and scam prevention · Fake wallet prevention

Solved example: check a BNB claim without trusting the ticker

Fictional claim: “Any asset labelled BNB in an explorer is native BNB and can pay gas on BSC.” Turn it into separate questions: Does the BNB Chain documentation describe native BNB as BSC gas? Does this particular explorer record describe the network’s native balance or a token contract? Does an exchange currently accept that asset and network for deposits? Those questions need different evidence.

Check one: the BNB Chain introduction describes native BNB as gas for smart-contract execution on BSC. Check two: BEP-20 is a standard for contract tokens; the symbol alone does not identify a contract as native BNB. Record the chain/network, whether the record is a native balance or a contract token, and the exact contract only when one is relevant. An explorer page can show a record; it cannot establish that a recipient service supports the route today.

Solved conclusion: the universal claim is unsupported and conflates native asset, contract token and exchange deposit support. A defensible note is: “BNB Chain documentation describes native BNB as BSC gas; this fictional ticker-only example does not identify an asset or establish current deposit support. No wallet was connected and no transfer was attempted.” Before a real deposit, check the receiving service’s authenticated asset/network instructions for the exact region and product. If any field is missing, stop.

Evidence: BSC native BNB gas role · BEP20 token-contract interface specification · BSC network data · Explorer interpretation · Binance deposits

Used only for the documented role of native BNB as BSC gas. The same page contains dated validator details; those counts and performance claims are not reused as current facts.

Used only for the BEP20 token-contract interface and the methods/events named in the specification. It does not prove that a particular deployed contract conforms, is authentic, safe, issued by a named party, backed by reserves or equivalent to an asset on another network. The file contains historical Beacon Chain wording that is not treated as current migration guidance.

This Binance Academy article is an orientation to BscScan; it does not verify any live token, holder, price, liquidity-lock or contract claim.

Scope: general receiving-network checks, not a current list of supported routes. This FAQ still includes legacy Beacon Chain/BEP-2 examples. Those examples are not current onboarding; the Phase 3 notice describes a separate recovery process. Check the authenticated receiving screen for actual support. Phase 3 status notice for the discontinued hosted tool and BEP-2/BEP-8 self-service scope