More launchpads in the channel, same standard

Two days ago the channel was narrowed to tokens born on Pons — the measured answer to too many scams getting through. That was the right call, and it is also a door that can be widened carefully once you know how to read a token's origin.

The channel now also accepts launches from Long.xyz, o1.exchange, Commodites, Letscash and Bankr. What made this possible is the launchpad map rebuilt yesterday: a token's origin is now read from the launch itself and from the pool's hook, which survives graduation — so a launchpad can be recognised reliably rather than guessed from a label.

None of the gates moved. Every token still has to clear the same checks: a real crowd of holders rather than a handful of fresh wallets, liquidity that cannot be pulled from somebody's wallet, no selective blacklist, and the sell test simulated on-chain before anything is posted. Widening the door is not the same as lowering the bar.

Expect the mix to stay mostly Pons for a while — on the last 400 published signals it is still 97.5%. That is simply where most launches happen; the rest of the door is now open for when they do.

Every analysis names the launchpad — or tells you there isn't one

Knowing where a token was born is one of the strongest things you can know about it, and we were getting it wrong in two directions. A token's origin used to be read from what it looks like now — but that label describes the pool, not the birth, so a token that graduated to a DEX stopped saying where it came from. And when we couldn't name the launchpad, the line simply vanished.

Both are fixed by the same finding: on this chain, a v4 pool's hook is the launchpad. Every pool carries its hook address, each launchpad has its own, and — unlike the label — the hook survives graduation. Reading it re-identified a lot of tokens that were filed under a generic "Uniswap V4": 2,944 of them are Long.xyz launches. The map is now rebuilt from this every night, and several launchpads that used to print as a raw contract address finally have their name.

And when the hook is empty, there is no launchpad at all — somebody opened that pool by hand. That is not a gap in our knowledge, it is a fact about the token, and it is the category that dies most often. Those analyses now read 🏭 Launchpad: none — this pool was opened by hand instead of showing nothing. We checked it against 300 graduated tokens: of the 32 whose origin we could not name, all 32 had no hook. "We don't know" was really "there isn't one".

Calls: a token that grows into the gate now gets a second look

The channel requires a real crowd — at least 40 holders — before a token is published. Holders are the one thing in that gate that grows: a token checked ninety seconds after launch can have five, and two hundred by minute four. It was being written off at the first look and never reconsidered.

Measured on 400 rejected tokens: 12% reach the threshold while still inside the window the channel watches — roughly 176 candidates a day thrown away for a bookkeeping reason rather than anything about the token. They now stay in the queue and are re-checked until that window closes.

Two related fixes came with it. The holder count is now read as the highest actually seen, not the last reading received — on 25 queued tokens, 15 were being judged on a number lower than what they had already reached. And a token has to still have that crowd, not merely have had it once: of the tokens that touch 40 holders, 40% later fall below half their peak, and arriving after the crowd has left is the opposite of the point.

You should see somewhat more calls, from the same gate and the same standard — the ones we were losing to a stale look.

Brand-new tokens now get a real score instead of a blank

A Pons token spends its first stretch of life on the launchpad's own curve, before it ever reaches an ordinary market. That is the window where a fresh address lands in front of you and you most want a read — and it was exactly the window where the scanner came back with no score at all, because it was looking for a market that doesn't exist yet.

Those tokens now get a full analysis and a real score. It carries the (PARTIAL) label, and that is honest rather than cautious: two of our checks genuinely need an open market to exist — how much you could sell before you move the price yourself, and the sell test run on real holders' wallets. Everything else — the contract, who launched it, the holders, the launch guest list, who is trading it right now — is measured in full.

A wrong answer went with it. On some of these tokens the safety test was reporting «you cannot even buy this» and handing out an AVOID. That was our test being wrong, not the token: on the launchpad curve, buying and selling happen inside the launchpad's own contract, and the token itself has no way to block them. We checked it against tokens that were being actively traded at that moment — 2 out of 5 were getting that false verdict. It is gone, and with it two heavy on-chain simulations per scan that were never telling us anything.

Calls are now Pons-only, and three gates got tighter

Too many scams were getting through, so we stopped guessing and measured. Across 1,929 matured signals, tokens launched outside a real launchpad — raw pools opened by hand — died 4 times out of 10. Launchpad tokens died 3 to 5% of the time. Same channel, same filters, sixty times the difference in how often it ends badly.

The channel now publishes only tokens launched on Pons. (Updated 12 Sep: also Long.xyz, o1.exchange, Commodites, Letscash and Bankr — same gates.) The origin is read from the launch itself, not from a label: a token that already graduated to a DEX pool still counts as what it was born as. That distinction matters more than it sounds — the graduated ones are the good ones, and a naive reading would have thrown away exactly those.

LP must be locked or burned. Until now «we could not read the LP» was treated as a neutral unknown and let through. It is not neutral: those tokens died 1 in 3, and hit 2x more often than anything else — pump hard, disappear. Not knowing, here, is information.

Selective blacklists are blocked. On some tokens the team can sell and you cannot. The scanner had always labelled these correctly; the channel was not checking for it. On the last batch we re-tested, 3 in 25 published signals were affected.

Holders instead of buy count. Measured on 26,301 Pons tokens: the buy count adds nothing once you know the holders, while requiring real holders moves the odds of a 2x from 11.2% to 81.3%. There is also a ceiling — above 300 holders quality falls again. Whoever already has a crowd has already run.

You will see fewer calls. That is the intent. Five you can act on beats twenty where four are traps.

Is anyone actually trading it? The card now says how many

Every other line in an analysis describes the token: its liquidity, its holders, its contract, whether you can sell it. None of them answered the question you ask first when a fresh address lands in front of you — is anyone on this, right now?

Market section, new line: 👥 On it now: 616 bot traders · 3 KOL · 112 accounts. Automated trading accounts working the token, followed profiles holding it, and how many accounts have touched it in total. Some tokens carry thousands; most carry a handful, and that gap is the point.

It shows on 73% of the tokens we see, and — this matters — it shows on tokens still on the bonding curve too, which is exactly where the question is hardest to answer any other way.

When we don't have the number, the line is not there. It never prints a zero. «Nobody is trading it» and «we didn't look» are different statements, and only one of them is ours to make.

The launch guest list: who was allowed in before you

Pons launches carry an anti-sniper tax — 99% at the very start, decaying to nothing by the third second. But whoever launches can register addresses inside the launch transaction itself, and those addresses are exempt: they buy at the open paying the ordinary fee, while a stranger one second later pays 6.18%.

That list is written in the launch calldata, so it can be read the moment a token exists — before any flow analysis, and before the first candle. Every analysis now shows it: 🎫 4 wallets pre-registered in the launch tx took 30% of supply at the open.

Measured on 70 recent launches: 64% register at least one address (typically 2 to 6, up to 25). But registering is not the same as buying — on 21 of the 45 launches with a list, the registered wallets never bought at all, and those read but none of them bought. When they do buy, we have seen anything from 9% to 38% of supply taken at the open.

The project's X, Telegram and website, on far more tokens

A token's links used to come only from the pair data and from the contract's own on-chain getter. When both were empty the line simply vanished — and on the channels that was nearly always. The scanner now falls back to the live market feed we already query for holders and bot activity, which carries those links too.

Measured: on the last 80 published signals the socials line went from 0 to 43. On full analyses the gain is smaller, about 8%, because the on-chain getter already covers most Pons launches. When nothing is found, no line is printed — never a placeholder.

One guard came with it. In that feed, 26.5% of X links point at somebody else's post, not at the project's account — there are tokens whose link is a tweet by @elonmusk or @WSJ, and the follower count attached belongs to them. Those are labelled «post by @handle» in the full analysis and left out of channel signals entirely, and no follower count is ever shown as if it were the project's audience.

«TRADING FROZEN» on healthy tokens: pools quoted in WETH were never actually simulated

A Uniswap v4 pool on Robinhood Chain can be quoted in native ETH or in WETH. Our buy+sell simulation only ever worked for the native ones: on a WETH-quoted pool the trade reverted every single time, and the card announced TRADING FROZEN — on tokens that were trading normally, hundreds of swaps an hour, with no owner, no tax and no blacklist in the contract.

Settling an ERC-20 on this router needs a different call shape than settling native ETH. We already had the right one — it was written for stock-paired pools — and it now runs on both sides, the buy and the sell. Checked against every live WETH pool on the chain (71 of them): before, 71 out of 71 were called frozen; now 69 simulate cleanly, with a median round-trip of 96.5%. Native pools are unchanged.

One more case came out of it: when a pool cannot absorb even a tiny test trade, that is not a honeypot either. Those now read TOO THIN TO TEST, and the verdict falls back to whether real holders are getting out — which is the only evidence that counts there.

Who collects the creator tax — and how much they've already taken

Every Pons launch sets a creator tax (usually 2%) that you pay on every buy and every sell, and a wallet that collects it. The scanner read that wallet all along and never showed it. Now every analysis says it: 💰 Creator tax 2% → 0xe54a…eb8d (the deployer's own wallet) · 25.763 ETH ($64.5K) in fees so far — 22.354 ETH already withdrawn.

The number is the total, not just what's sitting in escrow: a team that has already pulled the money out reads as zero on-chain, which would have hidden exactly the cases worth seeing. We count what's still waiting and what has already been claimed.

We measured it on 300 launches first: the collector is the deployer's own wallet 96% of the time, so this is not an accusation — it's context. What is flagged is narrower: when the token's own on-chain description promises a treasury, a reserve, buybacks, rewards or yield, and the tax still goes to a plain personal wallet. Then you get 🚨 The token's own description promises a treasury / yield, but the creator tax goes to a plain wallet — nothing on-chain forces it to be spent that way. That combination shows up on about 8% of launches.

Lifetime gets double the daily full scans — and the limit message says so

The fair-use ceiling is now 100 full scans per 24 hours on Lifetime, 50 on the other plans. It still exists to stop scripts pushing a feed through the scanner, and it still never touches your VIP signals or the light cards.

The message you get when you reach it used to say «your next free full scan», which read like a downgrade to anyone who had paid. It now names your active plan and makes clear the cap is per account, not per plan.

The bundle, wallet by wallet: how much they bought, how much is left, how much they sold

Every analysis now says all three numbers instead of one: 🟢 Bundle: 15 wallets took 13.2% of supply in the first minute · nothing left · sold 100% of it. Knowing they took 13% is only half the story — what matters is whether that share is still sitting over your head or already gone.

There's also a new 🧩 Bundle button on every full analysis. It opens the list wallet by wallet: what each one took in the first minute, what it still holds, and what left. And it checks where the tokens went: into the pool is a real sale, to another address is just a move — those tokens can still come back to the market. On-chain the two look identical unless you follow the destination, so we follow it.

«New VIP» announcements no longer stay pinned in the channel

The post that celebrates a new VIP is pinned for half a minute and then unpinned. The unpinning lived only in a timer inside the running bot, so a restart in that half-minute left the post pinned for good — and a network hiccup on the way out was swallowed silently. The unpin is now written down and carried out by a periodic check, so it survives a restart and retries until it goes through.

The ad slot is shared fairly, and we show you your real numbers

Our own house ad now takes a turn in the rotation like any other advertiser, instead of only filling the slot when nobody had booked. Every ad — yours and ours — goes out on the same rule: whoever has been shown least that day goes next. So a booking buys a fair share of the posts rather than all of them, and the exact count is in 📊 My ad, live.

Advertise on RobinHouse — one slot, $30, 24 hours

You can now book the ad slot straight from the bot: 📣 Advertise in the menu. Your line becomes a button under our content — on the RobinHouse channel posts and on every light scan, in DM and in the groups. It is never inside the analysis, so it is never read as our call.

A human reads every ad before it goes live, and you pay only after it's approved — nothing is charged if we say no, and you're told why. With more than one advertiser the slot rotates evenly: whoever has been shown least so far goes next. 1 post in 10 stays reserved for «Advertise here», and our own house ad takes a turn in the rotation like any other advertiser — so a booking buys you a fair share of the posts, not all of them. Your real view count is in 📊 My ad.

The VIP channel and the full analyses stay ad-free.

The LP holder now comes with a record — and so does the shape of the launch

When the liquidity sits in a wallet, the card names the wallet and tells you what it did with its other pools: 🚨 LP holder 0x0963c9… held 23 other pools: 13 drained, median 7 min. We classify every new v4 pool on the chain at birth and re-check it at 20 min, 1 h, 6 h and 24 h, so the record is ours, not a listing's.

Right under the score there is a base rate for launches that look like this one — same pool type, same liquidity band, same kind of LP: 📐 Launches shaped like this (v4, liq $15k-40k, LP in a wallet, last 21d, n=212): 85% drained within 20 min. It only prints from 15 comparable launches up; below that it stays quiet.

Clones, every pool, and whether you can actually cash out

Three new lines in the market block. 👯 3 other tokens named $POPCAT launched in 24h — this is #2 by liquidity catches the copies that ride a launch's name. 🏊 4 pools ($5.2K total) lists every pool the token trades in when there is more than one, so the one we analysed is not mistaken for the only one. And when the token is not paired against ETH or USDG, 🔁 Quote token cashes out via USDG ($7.2M depth) — or a warning that the quote token has no exit at all and you would be stuck holding it.

The project's own description, read from the contract

Tokens launched on Pons carry their description and socials inside the contract. The card now shows the description under the header, and when the X account written on-chain differs from the one DexScreener shows, it says so: ⚠️ X on-chain is @a but DexScreener shows @b — one of the two is not the project.

/hot: tried for an hour, pulled

We briefly shipped a /hot command listing the tokens with the most real dollars traded in the last hour. It was pulled the same evening: as a command it added little that the card itself doesn't already tell you when you scan a token. The chain reader behind it stays in the Market block (see below).

Market numbers now come from the chain, not the data feed

On this chain the public data feed is unreliable: on 91 of 413 pools we checked it reported liquidity equal to market cap (one showed $7.8 billion of liquidity with $10 of volume), prices occasionally come out corrupted, and after a liquidity pull it keeps showing pre-pull figures for hours. The 📊 Market block now reads liquidity as the pool's real quote-side depth (the number that decides your slippage) and adds ⛓ On-chain 1h: buys, sells, dollars and net flow taken from the pool's swap events. Where the feed figure equals the market cap, the card says so instead of printing it.

Official tokenized stock, or a lookalike? The card now says which

There are 203 official tokenized stocks on this chain — and over 10,000 tokens using one of their tickers and names (17 different “GameStop • Robinhood Token”, 16 “NVIDIA”), 528 of them with real liquidity. Names can be copied; the issuer cannot. The scanner now reads the official stock factory on-chain and tells you plainly: 🏛 ✅ Official Robinhood tokenized stock — NVIDIA, or 🚨 NOT the official $NVDA — different issuer with the address of the real one. Same check on the pair: if a token is quoted in a fake stock, you are told.

A fair use limit on full scans, and a way past it when you need one

Full scans run real on-chain simulations, so they are the expensive half of the product. Every account now gets 50 full scans per 24 hours in DM on a rolling window — scans fired in a group don't count against you. It sits far above normal use: half of all scanning days here are two full scans, nine in ten are under ten, and 50 touches under 1% of every day we measured. Past it you keep getting the light card and can unlock +50 full scans for 24 hours: $5 the first time in any 30-day stretch, then $10, $20 and $40, with the price falling back as older unlocks age out. There is also a short pause between full scans — about 5 seconds, stretching past 10 full scans in 10 minutes — aimed at scripts firing a feed through the scanner. Fair use limit.

FOMO flow — who on FOMO is buying this token right now

Update, same evening: this line has been removed. The data source behind it was not stable enough to keep in the card.

The market block carries a new line: 🔥 FOMO 1h: 18 buy / 15 sell · +$241.4k net. It counts the distinct users of the FOMO trading app who bought or sold this token in the last hour, and the dollars that came in and went out. If the deployer is among the buyers, it says so.

Why this line exists: FOMO users trade from custodial wallets routed through aggregators, so their buying never shows up on-chain as buyers — no explorer and no other scanner can show it. This is the one place that crowd is visible. Read it as context, not as a trigger: the feed runs a few minutes behind the chain, which is fine for judging whether a token has a crowd behind it and useless for front-running it. When nobody on FOMO touched the token, the line simply isn't there.

We now tell you who paid DexScreener — profile, ads, boosts

Every analysis carries a new line: 💳 DexScreener: ✅ profile paid · ⚡ boost x60. It reads the approved orders on the listing — the paid Enhanced Token Info, community takeovers, ads and boost packages — and says what was actually bought.

This is not a safety signal, and we do not treat it as one: a rug can buy a profile like anyone else. It is the one line in the report that measures how much whoever is behind the token was willing to spend to be seen, which is exactly the question you have when a token shows up in trending and you can't tell why. When nothing was bought we say that too — but only when the answer really came back. "Nobody paid" and "we couldn't check" are different things, and we never print the first when we mean the second.

The market block reads like a table now

It used to be one dense sentence — MC $30.8K · Liq $30.8K [100% of MC] · Vol24h $12.5K · Age 9m — where finding a single number meant reading the whole line. It is now laid out in branches, two columns to a row, so your eye goes down instead of across. The pool version moved up next to the pair, because "what does it trade against and where" is one question, not two.

Holder percentages no longer round themselves down to zero

A card reading 7 holders · top 10 = 0% of supply looked broken. It wasn't: the top ten really did hold 0.5% — the rest was still sitting in the pool — but we printed it with no decimals and never said where the missing 99.5% had gone. Small percentages now keep their digits, and a new line spells it out: 🏦 99.5% of the supply is still in the pool — only 0.5% is out in wallets so far. On Uniswap v4 that share lives in the pool manager rather than the pool, which we now read correctly.

Separately: when the explorer reports a holder count but returns a shorter list than it claims — 7 holders, 5 addresses — we fill the rest in from the chain. The fallback used to trigger only when the list came back completely empty, so this case slipped through every time.

A single, honest progress bar while you wait

The waiting message used to be two lines that disagreed with each other: a timer counting against a ~10s estimate that scans no longer met, and a separate percentage that sat at 20% for the twelve seconds the security suite takes — the exact stretch where you are watching hardest. It is now one bar, driven by elapsed time so it never stalls and never goes backwards, and it deliberately never fills all the way: claiming 100% while you are still waiting is a lie.

One report for everyone, regrouped so it reads top to bottom

There used to be two formats and a switch in Settings. The switch is gone: there is now a single card, and it has been rebuilt around how you actually read it.

The analysis used to come out as thirteen separate blocks in the order the engine produced them. It is now six named sections — The read, Market, Safety, Holders & bundle, Launch — each with at most one expandable drawer, and the plain-English read of the whole token sits at the top, where the question "what is this?" actually gets asked. Alarms (🚨) are never tucked away: a warning you have to open to see is not a warning. Repeated sentences are collapsed, so the same finding no longer appears three times in three different wordings.

Nothing was dropped — everything the long format showed is still there, one tap away.

Scans got a third faster — a fast call that was quietly the slowest thing we did

A full analysis took 21–25 seconds. It now takes 13–15, with nothing removed.

The culprit was the bonding-curve check — three tiny contract reads that cost 0.7s when timed on their own. In a real scan they took 4 to 18 seconds, because they ran on the main thread while eight other branches were already saturating the node, and nothing else could start until they finished. Moving them ahead of the rest, where the line is empty, gave the whole time back. The security suite — the part that actually buys and sells the token on a simulated node — now also starts first instead of last, so the longest job is never the one waiting for a free slot.

A call that is fast when you measure it alone is not necessarily fast when it runs.

Bundle-dump alerts: we tell you when the first-minute wallets leave completely

The wallets that grabbed the supply in the first minute of a token's life are the bundle — the group that, if it walks out together, takes the chart with it. The scanner already measured them; now it keeps watching them for you.

If a bundle still holds a position when you scan, we follow those wallets for 24 hours and ping you as a reply to your own analysis the moment they are out. The alert fires only on a complete exit — never on partial profit-taking. That is deliberate: a signal that goes off on every routine sale is a signal nobody reads.

On by default, switchable any time under ⚙️ Settings → Bundle-dump alerts.

Ten holders instead of five, and the bundle explained in plain words

The holders block now lists the top 10 wallets rather than the top 5, and says what each of them is holding elsewhere — including when the answer is nothing else, which is worth knowing on its own. The bundle line no longer assumes you already know the jargon: it spells out that these are the wallets that took a share of the supply in the first minute, how much of it they still hold, and how tokens in that band have historically performed.

listed.gg added to the trading buttons

Every signal in the channel and every light scan now carries listed.gg alongside the bots that were already there. It is a web trading app, so it opens in a browser instead of asking you to set up another Telegram bot — one tap from the alert and the token is loaded, ready to trade.

The scanner knows the stocks — and always tells you what a token is paired against

Robinhood Chain carries 223 tokenized stocks, and plenty of new tokens are paired against one of them instead of ETH. Until now the analysis just said "ETH" and the price you were reading was quietly denominated in something else. Every analysis — full, compact and light — now prints the pair as $TOKEN / $SPCX and, when the other side is a stock, spells out which company that ticker actually is: $SPCX is the tokenized stock of Space Exploration Technologies Corp. If a token trades against NVDA, you shouldn't have to already know that NVDA is Nvidia.

Liquidity status on every analysis — and burned is not the same as locked

The LP line is now on every analysis, the light one included, and it no longer lumps two very different things together. ✅ LP position burned means the liquidity can never be pulled by anyone. ✅ LP locked in V2LaunchLocker means it is held by a locker contract that confirms it on-chain, and where the contract exposes it we print when it unlocks. When the LP is simply sitting in a wallet, we say so and name the holder. Works on Uniswap v2, v3 and v4 — on v4 the liquidity is an NFT position, so the real owner is resolved through the position manager rather than guessed.

Pool version, and checks that cover v2, v3 and v4 alike

Analyses now state which pool the token actually trades on — 🧱 Pool: Uniswap v4 — because the version changes what can be checked and how. Alongside it, the security suite was brought to parity across all three versions: the pool the scanner analyses is now picked by real liquidity and verified to actually contain the token, instead of trusting a listing. On several tokens the scanner had been reading a $127 side pool while the real market sat in another one.

Tokens paired against a stock could not be simulated at all

On Uniswap v4 pools quoted in a tokenized stock, our simulated buy and sell reverted every time, so those tokens came back with no round-trip and no verdict — and, worse, the sell test on real holders failed for the same technical reason and read as "the token blocks you". Tokens with real sales on chain were being flagged. Both are fixed: the swap is now built the way trades on this chain are actually built, and the holder sell test follows the same route. Verified against our frozen ground-truth set: 113 of 113 healthy tokens cleared, no false positives.

A partial score instead of no score

When one input couldn't be measured, the whole score used to come back empty — which told you nothing at the exact moment you wanted a read. Now the scanner scores what it could measure, marks the band (PARTIAL), caps it so a partial read can never look like a strong one, and says in plain words which piece is missing.

Contract fingerprint, owner powers, and two new red verdicts

Three additions to the security read. Fingerprint: we hash the contract's bytecode and tell you how many other tokens share the exact same code — and how that family behaved, counting only tokens old enough to have an outcome. Owner powers: the functions the owner keeps are read straight off the bytecode and explained in one sentence, including the ones that let them redirect fees or drain the contract. New verdicts: selective blacklist, when the scanner's own test wallet can sell but real buyers can't, and extreme pool fee, for pools set to a fee so high it works as a trap — one of them was charging 81%.

Upside score, next to the safety score

Safety tells you whether a token can hurt you. It never told you whether it could run. The new upside score sits next to it and reads the things that historically preceded a move on this chain. It was fitted on past calls and then checked on calls it had never seen, so the number is a measurement, not a hope — and it is deliberately kept separate from safety, because a safe token and a promising token are two different questions.

Full analysis is a third faster

A full analysis went from 19.4s to 12.2s. The bottleneck wasn't the amount of work — it was three log queries running one after the other, and a chain node that answers the same question in anywhere from 0.3s to 10.8s. The queries now run together and a second copy of the slow call goes out if the first is late, so one unlucky answer no longer sets the pace.

Every signal now shows its sell test — and you can drop taxed tokens

Before a call is posted we run a real buy→sell round-trip, simulated on-chain: if the token can't be sold, the call never goes out. That check has been running for a while — now the result is printed on the signal: ✅ Sell test: passed at call time, or ⚠️ passed · tax 8% when the token charges a tax, which before went out unmentioned. If the simulation can't conclude, the line is left off rather than guessed. On top of that, VIP +DM subscribers get a new filter — Taxed tokens: never — so calls on taxed tokens simply don't reach your DMs. Reading an alert.

Every scan now carries the chart — with the call marked on it

Scans no longer send you off to another site to see the price. Every scan, light or full, in DM or in a group, now comes with the token's candlestick chart in the message itself. On it sits a marker at the exact point where the scanner first called that token, showing the market cap at the call and how far the token has run since. The window follows the token: minute candles on something that launched this morning, wider ones on something older. About the scanner.

X Tracking — watch an account, catch the call

Tell the scanner to watch an X account and it pings you the moment that account posts a contract. Two modes per account: Contracts only, which stays silent until a CA drops, or Every tweet. Each contract alert lands with the chain, the contract ready to copy, the chart, a one-tap buy and the full analysis. Set it up with /followx @name, or tap Track next to the X account on any scan. Free plan watches 1 account, any active plan watches 50. How it works.

Wallet Tracking — follow any wallet, on two chains

Pick a wallet on Robinhood Chain or Solana and get a DM when it moves. Paste any address to see its card first — activity, who funded it, win rate, and labels read off its on-chain behaviour — then tap to follow it. Six event types you switch on one by one, including Token created, plus filters for minimum size, new tokens only and first buy only. Free plan follows 1 wallet, any active plan follows 50. Open it with /tracking.

USDG accepted for payments

You can now pay in USDG (Global Dollar) alongside USDC and USDT. It is by far the most used stablecoin on Robinhood Chain, and until today it wasn't on our list — a payment sent in USDG went unseen. That one has been credited, and USDG is now watched like the others.

Signals were slow, and some never arrived

For three days the channels were running on a slower source of new pools than they should have been. Tokens were being found roughly eight minutes after launch instead of within seconds, and by the time we looked at them many no longer qualified — so they were never posted at all. The fast source is back on and the gap is closed.

New pools are seen within seconds, including Uniswap v4

Most of Robinhood Chain has moved to Uniswap v4, and we were still listening mainly for the older pool types — on a three-minute sample there were 39 v4 launches against 1 on v3. We now read v4 pools directly from the chain, which is also what made the speed-up possible: median time to spot a new pool went from over eight minutes to 5 seconds.

One consequence worth knowing: on v4 an old token can open a new pool, which would otherwise look like a fresh launch. Signals now cross-check the real pair age and correct it, so a token that has been trading for days is not presented as minutes old.

How old the token is, on every signal

Every signal now carries the age of the token — how long its pool has been live — right under the market cap. A call on something minted minutes ago and a call on something that has been trading for two days are very different situations, and until now you had to go and check that yourself.

Token images were missing on many signals

Roughly two thirds of signals were going out without the token image even when one existed. Two separate causes: image links that did not end in a file extension were being discarded, and once a token had any social link on record the image was never looked up again. Both are fixed, and images now appear on far more signals.

Token images are bigger and all the same size

Token logos used to come out at whatever size and shape the original happened to be — sometimes a postage stamp in the middle of the post. They are now rendered at a single fixed size, with small images scaled up instead of left tiny.

The report now tells you how the liquidity was seeded

Every scan of a v4 pool now reads the moment the pool was opened and says what it finds. Three things go in the Security section: whether the liquidity was placed across the entire price range or in a tight band; whether the contract that opened the pool has a track record here, and how many of its past launches pulled their liquidity; and whether the amount seeded matches a launch template we have seen before. On the archive of launches we keep, tokens opened with a full-range position had their liquidity pulled far more often than the rest — so when you see that line, take it seriously. It is a rug-risk signal, not a prediction that the price will go up.

A short read of the whole picture, in plain English

At the end of each report there is now a short paragraph that reads the findings together — what actually matters on this token, and the one or two things worth watching next. It never overrides the verdict or the score: those come from the on-chain checks, and the summary only explains what they mean. If the web has anything to say about the project, that goes in one line too.

Risk score recalibrated against what actually happened

We went back over every scan the bot has produced and checked each part of the score against how those tokens really ended up. A few signals turned out to point the wrong way — for example, tokens where people were actively selling were being penalised, when in fact a working exit is a good sign, while heavy buying just before you arrive turned out to be the opposite. Those weights are now fixed, and the score is noticeably better at telling you which tokens end badly. Ownership renounced also counts for more, since it's the one green flag that held up in the data.

Filters for DM signals: market cap, LP lock, launchpad

VIP members with signals in DM can now decide which calls reach them: a market-cap window, LP-locked only, and a per-launchpad picker (NOXA Fun, MIME, Flap, LaunchHood, Pons, Stonks.fun, direct deploys, everything else). x2/x3 updates follow the entry market cap of their call, so you only get follow-ups of the signals your own filter would have delivered. It's all in Settings inside the scanner bot.

Public Stats page

The Stats page is now open to everyone: live track record straight from the tracker, updated as calls resolve. Winners and losers, no cherry-picking.

Shorter, clearer payment window

Invoices now give you 10 minutes when you pay from your own wallet and 1 hour when you pay from an exchange, and the countdown starts when you pick the payment method — not before. Late transfers are still matched behind the scenes, so a slow exchange withdrawal doesn't cost you the payment.

Paste any link, get the scan

The scanner now pulls the contract address out of any link you paste — Dexscreener, chart links, even a URL hidden behind text. Tokens from other chains are simply ignored instead of answering with an error.

Taxes priced into the score

Buy/sell tax is now scored on the full round trip, not just flagged when extreme: a token you can enter and exit at a heavy haircut is rated for what it actually costs you.

Unverified contract = hard gate

If the contract source isn't verified, the scanner can't read what it does — so it's now treated as strictly as a failed honeypot test instead of a soft warning.

Tokenized-stock pairs & decoy-pool guard

Tokens paired against tokenized stocks are priced correctly instead of reading as broken, and the scanner no longer gets fooled by a decoy pool set up next to the real one.

Honeypot pre-check on every VIP call

Before a call is posted, we run a real buy+sell simulation through the router — and read the contract itself for static honeypot signatures, the kind of delayed trap a one-shot simulation can't see. Anything that fails never becomes a signal. Same week: one scan per token in partner groups (no duplicate cards), and support for the relaunched NOXA Fun launchpad.

Dev-dump & wash-farm detector

The report now calls out deployers dumping on their own launch and wash-traded volume farms, and caps the score when it sees them. Tokens you follow with /watch ping you if the dev starts dumping after your scan.

VIP plans in the bot, signals in DM, Tools

VIP became self-service: plans, payment in ETH or stables on Robinhood Chain, and instant access — all inside the scanner bot. The higher tiers mirror every VIP call straight into your DM. The due-diligence Tools from SolHouse (domain whois, Telegram account check) came along with it.

RobinHouse AI Scanner

The honeypot checker grew into a full scanner: 0–100 score across security, liquidity, holders, curve and momentum, with a plain-English report that tells you what's wrong instead of dumping raw numbers at you. Works in DM and in any group.

Launchpad label & LP-lock badge on every call

We mapped the launchpads on Robinhood Chain from their verified factories, so each VIP call now says where the token was born — and whether its liquidity is locked or still in the deployer's hands. See the LP-lock badge.

RobinHouse on X

@robhousesignal goes live — calls and milestones posted outside Telegram too.