// Research · 2026-09-12

Nobody knows which one you mean.

An agent asked to buy a token resolves it by name or symbol, because that is what a person types and what a market feed carries. On Robinhood Chain those identifiers are not unique. 35.3% of tokens share a symbol with another token, and the collisions are not accidents accumulated over months.

58% of duplicate families have two members launched under ten minutes apart. One symbol — RBNHD — was claimed by six near-identical tokens inside thirty-five seconds.

The measurement

1,600 tokens read directly from the chain, with no fetch failures.

The detail that makes this a security property rather than a spam problem: duplicates mostly come from different deployers. The EVERYTHING family is ten tokens from ten separate wallets. This is imitation by independent actors racing the same name, not one operator flooding the chain — which means there is no bad wallet to blocklist and no pattern in the deployer to learn.

When a user tells an agent to buy RBNHD, there is no correct answer. The agent must choose, it has no basis to choose well, and five of its six options are someone else’s.

The class exact matching cannot see

Nine tokens in the sample carry Cyrillic characters that render as Latin. A filter searching for the string “NYSE” does not match the first row below, because it is not that string — it only looks like it, perfectly, in every typeface.

The CHIР case is the sharpest: it collides with a genuine ASCII CHIP already trading on the same chain. Two tokens, visually identical tickers, different addresses, both live. Any system that deduplicates by string comparison treats them as unrelated, and any human reading a list sees one ticker twice.

This is the same mechanism as the invisible-Unicode findings our registry flags in launch metadata — 239 tokens to date under X402-205 — but it survives a different defence. Stripping zero-width characters does nothing here. The characters are visible; they are simply not the letters they appear to be.

What else is in the label

Identity is not the only thing an agent reads off a token. It also reads the description, the website and the social links — all attacker-controlled, all unverified.

Two rows deserve attention. Eleven tokens use the exact ticker of a real listed equity — NVDA three times, PLTR three times, HOOD twice — on a chain whose defining feature is tokenised stocks. One is named “Nvidia” outright, with a website at nvdacat.vip.

And 1.7% link a Twitter account that genuinely belongs to the brand being impersonated — twenty-six point at real @RobinhoodApp status URLs, one at Elon Musk’s account. The metadata is authentic. It is simply not theirs. An agent that verifies the link resolves, and that the account is real, confirms both and learns nothing.

Method

Reproducible against the public RPC with no key and no account.

# launches: the PONS factory's launch event
topic0   0x8d4aad4953d0ca700d468f3753aa14432d1b35b43ec6409f051fb6aa43a89607
address  0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e

# metadata: read straight off each token contract
name()          0x06fdde03
symbol()        0x95d89b41
description()   0x7284e416
getTokenInfo()  0xabb1dc44   # website, twitter, telegram, discord, farcaster

# collisions: normalise, then group
#   NFC-normalise, casefold, and map confusable codepoints to their
#   Latin skeleton before comparing — exact equality misses the nine
#   homoglyph cases entirely

Two RPC behaviours will produce a wrong answer silently if you do not know about them. The public gateway serves a Cloudflare challenge — HTML, not JSON — to a default client; a browser user-agent gets through. And eth_getLogs caps at 10,000 results without erroring, so a wide block range returns a truncated list that looks complete. Both cost us time before they were understood, and both yield a confident wrong number rather than an obvious failure.

Limits, and a correction

The duplicate families are undercounted. 1,600 tokens is a 23.3% sample of the window, so a family of ten observed here is roughly four times that on the full set. The share of colliding tokens is a reasonable estimate; the family sizes are floors.

The dead-link figure counts only 404s and timeouts. Sites returning 403 were excluded, because bot-blocking and absence are indistinguishable at this remove — so 18.5% is a floor, not an estimate.

An earlier pass of this work reported materially different metadata percentages, computed on a subset where transient RPC failures had been recorded as unreadable tokens. That was sampling bias, not a property of the chain: the “unreadable” tokens read perfectly on retry. Every figure here is re-derived at N=1,600 with zero failures and supersedes the earlier numbers.

We also expected most tokens to burn a large share of supply, on the strength of a handful that burn 96.8%. Measured, only 1.1% have sent anything to a burn address and none exceeded 3%. The prior belief was wrong, and the sample that produced it was not representative.

Why this matters more than it looks

Most token-security tooling asks whether a contract is malicious — honeypots, hidden mints, drain functions. That is a real question and it is well covered. This is a different failure, and it is the more common one.

An agent that resolves “RBNHD” to the wrong one of six candidates has not been attacked, and every contract involved may be perfectly ordinary. It has simply been asked to make an identity judgement using an identifier that does not identify. No scanner catches that, because there is nothing wrong with any individual token.

The answer is not another verdict on the contract. It is that an agent resolving a symbol should be handed every candidate, ranked by whether it is actually alive, with confusable characters normalised — and told plainly when the question it asked has more than one answer.

Sampled 2026-09-11 from rpc.mainnet.chain.robinhood.com (chainId 4663). Confidence intervals are Wilson score at 95%. Registry figures are re-fetchable at /api/v1/stats/launches. Negative findings mean “not found with substantial effort”, never “proven absent”.