What Relay disclosed on 9 July 2026
On 9 July 2026, Relay — the interoperability infrastructure that operates the bridge and swap surface for Robinhood Chain — posted an incident disclosure: "We're aware of reports of tokens disappearing from wallets after purchase on Robinhood Chain. There's been an increase in scam tokens designed to remove themselves after purchase. If you bought one, the funds you spent are unfortunately gone." Relay said it is "blocking these tokens as they show up and verifying safe ones", and scoped the incident explicitly: "this is not a wallet compromise. Your private keys and other balances are untouched."
Two sentences in that disclosure carry the durable facts. "Anyone can list a token" — listing on the permissionless side of Robinhood Chain is open, and the chain's own execution partner says so. And "stick to tokens verified by us or another trusted source" — the venue's mitigation is a reactive blocklist plus an allowlist, applied after a token shows up. This page takes the disclosure as a dated, observed incident and explains the mechanics behind that token class — as facts about what a deployer can hold and a reader can observe, never as a ruling on any specific token or on anyone's intent.
- Disclosed 9 July 2026 by Relay — a bridge and swap surface for third-party token purchases on Robinhood Chain.
- Relay described tokens "designed to remove themselves after purchase"; this page treats that as a reported class, not a finding about any specific token.
- Relay's scoping: not a wallet compromise — private keys and other balances untouched; the loss is the purchase itself.
- Relay's mitigation: a venue-operated blocklist and allowlist, applied reactively as tokens appear.
The mechanisms covered here depend on privileges that exist before you buy
The mechanisms covered here generally depend on pre-existing contract, owner-role, or liquidity-state conditions that can be inspected before purchase. That is the useful fact in an otherwise ugly incident: each mechanism below involves a specific privilege the deployer holds — in the bytecode or in the deployment state — and a privilege is an observable fact, checkable before purchase, in a way that future behavior never is. For each one: what the deployer would need to hold, and what a reader can look at before buying.
- Mint authority — the contract keeps an owner-callable function that creates new tokens after launch. Look for: a mint function in the source or bytecode, and whether ownership is renounced or live. Exercised, new supply can be sold into the pool until the liquidity behind existing holders is gone.
- Blacklist, whitelist, or trading pause — the owner can block specific addresses from transferring, or halt transfers entirely. Look for: those functions plus a live owner. Exercised after your buy, the tokens stay in your wallet but a sell reverts.
- Transfer taxes — the contract takes a fee on each transfer, and the owner can adjust it. Look for: fee parameters, whether they are owner-settable, and to what maximum. A transfer tax raised to 100% is a sell that returns nothing.
- Upgradeable proxy — the token address points at logic the owner can replace. Look for: a proxy pattern in the bytecode and who holds the upgrade key. Whatever you read before buying can be swapped out after.
- Unlocked or concentrated LP — the deployer still controls the liquidity-pool tokens. Look for: whether LP tokens are locked or burned, for how long, and how concentrated they are. An unlocked pool can be withdrawn at any moment — the classic liquidity pull.
- Common-funding holder clusters — a large share of supply sits in wallets funded from a common source. The funding graph is observable; it is not a finding about holder intent or coordination.
- Token age and unverified source — a contract deployed hours ago with no published source has no history to check and no code to read. Young does not mean malicious and unverified does not mean malicious — both states mean "not checkable yet", which is itself worth knowing before buying.
Why a point-in-time check cannot rule out a rug
The tempting check is a sell simulation: simulate selling the token right now, and if the simulated sell clears, conclude the token is sellable. The problem is the timestamp. A simulation at time T shows, at most, that a sell would have cleared at T. The risk is T+1: a privileged role could exercise a mint, blacklist entry, tax change, proxy upgrade, or pool withdrawal after a purchase settles. Every sell simulation in the world can pass at T and the position can still be gone at T+1.
That limit is structural, and it applies to every tool — Routescore included. No point-in-time read — a registry match, a sell simulation, a bytecode scan, a holder snapshot — can observe a transaction that has not happened yet. What a pre-buy check can honestly do is enumerate the privileges that would make a later rug possible and state which were observed and which were not evaluated. That is the ceiling of pre-sign verification; a tool that implies more than that ceiling is claiming to see the future.
None of the observations above is a verdict, in either direction. A live owner key or an unlocked pool is a fact about what can happen, not a prediction that it will — contracts keep privileges for operational reasons too, and holding one is not evidence of intent. The honest reading runs one way: an absent privilege only removes that specific observed mechanism under the methodology that checked it — it does not clear the token; a present privilege leaves the mechanism open. And a scan that finds nothing is a statement about what was looked for, at a stated methodology version — never a promise about the token.
What Routescore checks today — and what it does not
Today, on Robinhood Chain, Routescore's token-level read is registry recognition in the check_swap API and MCP tool; /route-check currently models route quality and slippage. Recognized means the contract address matches Routescore's registry entry for the chain; unverified means it has not been confirmed. Recognition is a registry match and nothing more: it is not safety, sellability, liquidity, rights, redemption, custody, or dividend verification, and unverified means "not confirmed", not "malicious". Verdicts stay clear / caution / unsupported, with machine-readable reasons and the caveats attached.
What it does not do today is just as fixed: it does not scan bytecode for owner privileges, does not read LP lock state or holder concentration, does not run sell simulations, and does not label any token a rug or a scam — it reports observed states, never intent judgments. A privilege-surface field — owner-privilege indicators reported as observed / not_evaluated states from static analysis — is a roadmap item, unscheduled. If it ships, it will report privileges as observed facts carrying the same T-versus-T+1 caveat on every artifact, and "no findings" will stay scoped to the methodology version that looked.
The wider context: what regulators and law enforcement have published
Two public reference points put meme-coin risk in context, stated here as education rather than advice. In February 2025, staff of the US SEC's Division of Corporation Finance published a statement on meme coins describing them as assets whose value is driven primarily by market demand and speculation, noting that they "typically have limited or no use or functionality", and that purchasers of the meme coins the statement describes may not be covered by the investor protections of the federal securities laws. It is a staff statement about a category, US-scoped — not a rule, and not a statement about any specific token.
For scale: the FBI's Internet Crime Complaint Center reported approximately $9.3 billion in losses from cryptocurrency-related fraud complaints in 2024. That figure spans many fraud types, not only token rugs, and reported losses undercount what goes unreported. It is included only to scope public crypto-fraud reporting; it is not a Robinhood Chain rate, a product-performance claim, or an investment prompt.