Update on DeFade (the memecoin analyzer I posted here a few months ago): 4 chains, 29 modules, and the signal engine I'm testing that lost 96% on its
I posted here a few months back about DeFade, the memecoin analyzer I've been building. Plenty has changed, so this is an update - but the part worth your time isn't the feature list. It's that I tried to turn the scanner into something that calls entries, the first attempt lost almost everything, and the post-mortem taught me more about this market than any of the wins did.
Part 1 - the scan
The core product is still the same one-line pitch: paste a contract address, get the truth about it.
A scan returns a rug pull probability from 0 to 100 - a weighted composite with kill-switch floors, so a single fatal condition can't be averaged away by a dozen healthy-looking ones - plus every piece of evidence that produced it. Roughly 29 modules, 13 of them free:
Distribution - holder concentration with the pool, burn address, lockers, CEX wallets and contracts classified out. This matters more than it sounds: read a raw top-10 list and you'll count the liquidity pool as a whale and panic over a perfectly normal token. There's also an exit liquidity calculator (what actually comes out if you try to sell your bag into the current book) and a bubble map.
Coordination - bundle detection with a launch window pass plus a delayed sweep hours later, accounted on peak net exposure rather than naive buy totals. Sniper bots, Sybil band clustering, an insider network graph, a cross-funding graph, and multi-hop funding-origin tracing that walks back toward a KYC'd source.
Actors - creator intelligence and serial-deployer detection, dev wallet tracking, fresh wallet detection, smart money and copy-trade tracking, plus a reputation ledger for deployers and wallets that fills in as scans land.
Market - LP burn and lock verification (including v3/v4 position-based liquidity), lifecycle stage, social sentiment timeline.
Two examples of why this is harder than it looks, both real bugs I shipped and then had to fix:
- Bundlers stopped holding. The obvious way to measure a bundle is "how much supply did these coordinated wallets buy, and are they still holding it". Then I hit a token where the bundle wallets sold and forwarded the proceeds to a collector in the same transaction, so extraction measured as zero. Then the exact inverse: tokens hop to fresh wallets first, and those fresh wallets do the dumping, so the original bundle looks like it's still holding while the supply is already gone. Both needed one-hop follow accounting, credited to a separate bucket so the numbers stay honest.
- A bot made an innocent token look like a serial rugger. One token came back flagged with "25 prior rugs" from its deployer family. It was a false positive: a permissionless MEV bot that cranks bonding-curve -> AMM migrations buys atomically inside the pool-creation transaction, so it appears as an early insider on hundreds of unrelated launches. Fixing it meant detecting the migration instruction deterministically rather than inferring intent from timing.
It runs on Solana, Ethereum, Base and Robinhood Chain, in the browser, as a Chrome extension that scans whatever token page you're already on, as iOS and Android apps, as a Telegram bot, or as an API if you are building something. Free tier is 3 full scans a day with all the core modules, no card, no account needed for the basic path.
Around the scanner there's a public rug database of everything flagged, a survival tracker (how long scanned tokens actually lived, using drawdown-based death detection rather than waiting for a zero), deployer and wallet lookup, and shareable receipts for calls that aged well or badly.
Part 2 - Signals, which is in testing and not live yet
A scanner answers "is this dangerous". I wanted to know whether the same data could answer "is this attracting real capital". So I built a signal pipeline - market polling for momentum, liquidity behaviour and volume quality, combined with the scan snapshot for holder and dev quality - with a forced outcome ledger. Every fire is dated, and its forward return is tracked at 1h/6h/24h/48h whether I like the result or not.
First cohort: 17 fires, median return -96% at 24h.
The post-mortem is the useful part, because the losses were not what I assumed:
- They weren't rugs. Only 1 of the signalled tokens ever entered my own rug database, and several are still alive today. I had built a rug detector and pointed it at a problem that wasn't rugs.
- They were tops. Every bad fire happened mid-vertical - the 1h change at the moment of firing ranged from +137% to +578%. The three fires that actually ran afterwards had 1h changes between +3% and +28%. My momentum scoring treated "already went up a lot" as its strongest positive signal, which is a top-buying machine with extra steps. Momentum now inverts past the extremes: beyond +120% on the hour it's capped and labelled "PARABOLIC - LATE".
- Thin-book markups look identical to real moves. A 50%+ hourly move with under 15% liquidity growth is someone marking up an empty order book. That was the signature of the worst fires: price up several hundred percent on a stable $19–33k pool.
- High turnover is not wash trading. I nearly shipped a rule rejecting anything trading over 5x its market cap in a day. It would have rejected 30% of the candidate pool and every signal that ever worked - one genuine runner did 18.5x turnover and ran 3.3x. The real wash signature is turnover with no consequence: high volume plus a price that went nowhere over six hours. Over one hour, even a real runner looks flat between legs.
- The deployer check was silently missing. Two components disagreed about a response shape - one returned the reputation nested, the reader expected it flat - so serial ruggers scored as CLEAN with no error logged anywhere. Every fire in that cohort was made without a signal it claimed to be using.
Replaying the corrected rules against all 17 historical fires blocked 12 of them, including every bad one, while preserving the three that ran.
Where it stands after the fixes: 9 signals, 9 distinct tokens.
Peak multiple from the moment each signal fired: 56.8x, 37.9x, 16.2x, 15.9x, 6.6x, 4.6x, 3.5x, 1.5x, 1.0x. That's 78% reaching 2x and 56% reaching 5x, with a median move of +31% at 1h and +208% at 6h. The two that didn't work: one is flat, one drew down 73% and is the clear loser of the set. A third of the set drew down 30%+ at some point even while working, which is the number I'd actually pay attention to if I were trading these - peak multiple is not what you realise, it's what was theoretically on the table.
Nine calls is not evidence. It's an early read that the entry-quality rules are doing something, on a sample small enough that two bad weeks would erase it. That's exactly why the ledger is built into the product instead of screenshotted when convenient, and why Signals is still in testing behind a gate rather than launched: I'd rather be publicly wrong on a timestamp than sell a backtest. It opens when the record earns it.
Free either way
The scanner is free at 3 scans a day with the core modules unlocked, which is enough to check a coin before you ape it. Paid tiers exist for people working the feed all day, but the free path is the one I'd want a first-time visitor to use.
defade.org - happy to answer anything technical about the detection, and genuinely curious what people think the momentum inversion gets wrong, because that's the rule I'm least sure about. A few things in this post came from comments on the last one.
Still slightly stunned by this part: 350+ people now pay for it, over 1,000 use it free, and 22 are on API keys - which for something I built to check my own bags is not where I expected to end up.
