Cashtag monitoring on X: track $SOL, $BTC and any ticker

Quick answer: A cashtag is the $TICKER form, and on X it is a distinct token from the bare word — searching $SOL finds posts that deliberately tagged the ticker, while searching SOL finds every post containing those three letters in any context, including Spanish, names and unrelated abbreviations. That single difference is most of what makes cashtag monitoring workable at all. The two problems that remain are collisions — the same ticker exists on several chains, and often several times on one chain — and thresholds, because the mention volume that means "something is happening" for a fresh ticker is noise for $BTC.

$SOL and SOL are not the same query

X indexes the cashtag form as its own entity. This has consequences worth planning around:

• $SOL is intentional. Typing the dollar sign is a choice — people do it when they are talking about the asset. It is close to a self-declared topic label, which is why the precision is so much better than a keyword.
• SOL is a substring problem. It matches the Spanish word for sun, the abbreviation for "solution", parts of names, and every ticker discussion that happens to omit the sign. For a three-letter ticker this is unusable.
• Neither catches the other reliably. A post that writes "solana" without a cashtag will not appear in a $SOL search, and a post that writes $SOL may not appear in a solana search. If you want both behaviours you need both queries, which is a real cost when query slots are limited.

The practical rule: use the cashtag for tickers, use plain keywords for names and narratives. $BONK and bonk are different questions — the first asks who is trading it, the second asks who is talking about it, and the answers overlap far less than you would expect.

X-Relay's search queries accept up to 480 characters each and you get 20 of them on every paid plan, which is enough to combine forms and exclusions in one slot rather than burning three.

The collision problem

Cashtags have no registry. Nobody owns $MOON, and nothing stops five tokens on four chains from using it simultaneously. This bites in two distinct ways.

Ticker-to-ticker collisions. A popular symbol is frequently reused by unrelated projects, and it is reused deliberately — a new token borrowing a known ticker inherits some of its search traffic. When your alert fires on $MOON, the post may be about a token that has nothing to do with the one you were watching.

Cross-chain collisions. The same name and symbol commonly exist on Solana and on several EVM chains at once, sometimes as legitimate bridged versions, sometimes as copies riding the name. Buying the wrong one is a well-worn way to lose money on a call that was actually correct.

Two things help. First, when X-Relay resolves a ticker and it exists on more than one chain, the alert says so — the other chains are listed with their market caps, so a mismatch between the chain you expected and the chain with the liquidity is visible in the message rather than discovered afterwards. Second, and more reliably: where possible, watch the contract address rather than the ticker. An address is unique; a ticker is a nickname. Contract detection covers how addresses are read out of posts, including from pump.fun and explorer links where the address is not in the visible text.

One more collision worth knowing: negation. A post reading "no $BTC or $SOL for me, all in on $HYPE" mentions three tickers and endorses one. A naive matcher fires on the first. X-Relay recognises negation phrasing — no, not, never, avoid, sold, dumped, skip — and excludes the tickers it governs, including through and/or chains.

Thresholds: what counts as a spike

The point of monitoring a cashtag is usually not to read every mention. It is to notice when mentions change. That requires a baseline, and the right baseline is completely different for a busy ticker and a fresh one.

X-Relay computes surge from a rolling 24-hour, hour-by-hour count per query. The current hour is compared against the median of previous completed hours, and a surge is flagged when the current hour reaches at least three times that median, and at least five posts. The median rather than the mean matters: one freak hour would drag an average upward for a day and suppress every genuine spike after it.

The two-part condition exists because each part alone fails on a different kind of ticker.

A high-volume ticker

For something like $BTC, the hourly baseline is enormous. Three times that essentially never happens outside a genuine market-wide event, so the multiplier is doing all the work and the floor of five is irrelevant. That is the correct behaviour — a surge badge on $BTC should be rare, and if you are seeing it often, your query is too broad rather than the market being unusually exciting.

For these, the surge signal is the only part worth alerting on. Raw mentions of a major ticker arrive faster than anyone can read them. Use Top mode, require a minimum follower count, and treat the badge rather than the message as the signal.

A fresh ticker

For a token launched this morning, the baseline is zero or close to it. Three times zero is zero, so without a floor every single post would be a "surge" and the badge would mean nothing. The minimum of five posts in an hour is what makes the signal survive on a new ticker: five people independently posting a ticker that did not exist yesterday is a real event.

There is a second guard here. Surge is suppressed entirely until a query has enough completed hours to compute a median from, because a brand-new query has no history and would otherwise flag its own first hour of existence as a spike. New queries are therefore quiet for a while by design, and that quiet is not a fault.

For fresh tickers the more useful badge is first wave: X-Relay tags the first five posts in a window that opens after at least thirty minutes of silence on that query. On a dormant ticker that suddenly gets discussed, those five posts are the beginning of whatever is about to happen, and they are far more informative than the two hundred that follow.

Worked examples

Watching a major asset for genuine events. Query $SOL in Top mode with a meaningful minimum follower count, replies excluded. You are not trying to read Solana discussion — you are trying to be told when its volume triples. Expect long silences. Silence is the product working.

Watching a ticker you already hold. Query the cashtag in Latest mode, but set a follower minimum high enough to cut out the reply-guy layer. Here you do want the individual posts, because you are watching for the specific post that changes your thesis, not for aggregate volume.

Catching a launch on a chain. Do not query the ticker at all — you do not know it yet. Query the chain or protocol name and let contract detection do the work, since posts announcing a launch carry the address or a pump.fun link even when the ticker means nothing to you yet. The first-wave badge is the one to watch.

Watching what specific people say about a ticker. This is the case where a search query is the wrong tool. Track the accounts instead and turn on replies — you get everything those people say about anything, which is usually what you actually wanted, and it arrives faster because you are reading a timeline rather than waiting on a search index.

An honest note on search speed

Search is structurally slower than tracking a named account, and this is not a vendor difference. Watching an account means reading that account's timeline directly. Watching a cashtag means waiting for X's own search index to include the post, and nothing downstream can beat the index. If a fast reaction to one specific person is what matters, track the person; use cashtags for the questions that have no fixed set of authors.

The speed numbers we publish — a tracked account re-checked as often as every 300 ms, and a fastest measured detection of 281 ms — describe account tracking. Search is slower than that by a margin set on X's side, and anyone quoting identical numbers for both is not measuring carefully.

FAQ

CA detection → · Fastest crypto alerts → · Guides and comparisons → · Pricing →