Match the claim to its source and scope

A useful verification checks exactly what a statement says. “This network is live”, “this account can withdraw”, “this token is authentic” and “this investment is protected” are different claims. A source supporting one does not establish the others.

Use a primary source with the correct product, legal entity, region, action and date. Then write the narrower conclusion it supports. If the scope is missing, the answer is incomplete.

A seven-part source check

Verify the exact claim, source and evidence type

  1. Write one narrow claim: separate network identity, a displayed asset, a product feature, account eligibility and live operational status. They need different evidence.
  2. Check the publisher and exact domain independently: start from a trusted, known site or saved official help center, inspect the full hostname, and compare it with the source you intended to read. A logo, search snippet, padlock/HTTPS or link sent in a message does not prove affiliation; lookalike and spoofed sites exist.
  3. Match the product and legal entity: distinguish an app or brokerage, a custodial crypto service, a self-custody wallet and a public network. A source for one is not proof for another.
  4. Match country, account and action: eligibility and transfer rules may differ by provider, region, account migration, asset and direction. A buy/hold page does not establish send/receive support.
  5. Record the date and source limits: distinguish a current policy page from an announcement or general education article. State exactly what it supports and what it leaves unanswered.
  6. Separate evidence types: documentation establishes what its publisher says; a read-only public status page may describe a live service state at that time; a user’s account, pending request or eligibility is a private fact that public documentation cannot verify. Do not imply that this guide tested the live service or an account.
  7. For an onchain token claim, match network and identity: use the exact chain and contract identifier only if the relevant project’s official documentation publishes it. A ticker, token name or EVM-shaped address alone is not proof. A block-explorer display or verified source-code badge does not establish issuer rights, backing, contract safety or provider support.

Official documentation can be wrong, stale, incomplete or scoped to a different user; it is not a guarantee of safety, solvency, eligibility or future service. If no primary source resolves a material part of the claim, label it unverified and do not act on it.

The SEC’s investor education warns that fraudsters can impersonate firms, make spoofed websites and falsify documents. Use the SEC’s independent Investor.gov guidance on impersonation (accessed 26 October 2026) as scam-awareness context; it cannot identify every scam or validate a particular crypto token.

Worked example: one app brand, different product scopes

Official support pages reviewed on 26 October 2026 say different things for different contexts: Robinhood’s UK page describes crypto trading through Bitstamp UK Ltd and says external crypto deposits and withdrawals are not supported there; the EU crypto information page covers both Robinhood Europe UAB and Bitstamp Europe S.A. accounts and warns that some features differ for migrated Bitstamp customers; US Crypto documentation has its own service scope. These statements are examples of why “Robinhood supports crypto” is too broad. They are dated provider documentation, not a live check of a service, an account or current eligibility.

Read the relevant UK Buy or sell crypto, EU About Robinhood Crypto, and US Crypto transfers pages in their stated scopes. A source for one region or action does not override another region’s terms.

Fictional exercise: handle an impersonated network claim

Entirely fictional post and hostname; no wallet, account, website login, contract, API or transaction was opened or tested. A social account using a Robinhood logo says: “Robinhood support confirms ETH on Robinhood Chain is the same deposit asset as ETH on Ethereum. Transfers work in the US, EU and UK. Verify your eligibility at robinhood-chain-verification.example by connecting your wallet.”

Which parts need separate evidence? What is the safe response before checking anything?

Show the answer key
  1. Do not act on the post: do not open its link, connect a wallet, share credentials or secrets, or send funds. A logo or social profile does not establish that the sender is Robinhood.
  2. Split the claim: whether Robinhood Chain uses ETH for native gas is a network-documentation claim; whether ETH is accepted by a particular service is a product/region/action claim; whether this reader is eligible is an account-specific fact.
  3. Check the dated primary sources independently: Robinhood Chain’s official docs describe it as a separate Arbitrum L2 and identify ETH as its native gas token. Ethereum documentation describes ETH as Ethereum’s native asset. That shared ticker does not prove the two network contexts are interchangeable. The UK support page specifically says external crypto deposits and withdrawals are unsupported for the described Bitstamp UK service; the EU page covers two entities and notes some migrated-account features may differ; US transfer rules belong to the cited US Crypto service. None proves universal regional availability or this reader’s eligibility.
  4. Check identity without the post’s link: navigate independently to a known official support domain and compare the exact host and page path. If the claim requires a particular token contract, network and official source do not identify it, or the claim depends on an account status, mark that part unverified. A public page cannot answer a private account request.
  5. Stop at uncertainty: if the domain, network, product, entity, action or eligibility cannot be matched to an authoritative source, do not proceed. Contact support through the official app/site path reached independently. This method can reduce unsupported assumptions; it cannot detect every scam or guarantee a safe result.

When sources disagree

Record both documents, their dates and their scopes. Check whether they discuss different products or whether one is stale. Do not average contradictory parameters or choose the most convenient interpretation for a transfer. Preserve the uncertainty and seek the current product-specific authority.

A source review is itself limited: it does not test a private account, a deployed contract or a transaction. Keep that boundary visible when explaining your conclusion.