Solana Safe Sniper — MCP Template

🌐 Available in 9 languages: English · Español · Português · Français · Deutsch · Nederlands · 中文 · 日本語 · 한국어

Stop your AI trading agents getting rugged by coordinated wallet cabals.
Drop-in template for Claude Code, Cursor, and ElizaOS.
▶ Try it now: live 3D holder map of any Solana token → — no signup.
Cabal-Hunter is a free on-chain Solana token safety scanner and rug checker. It detects coordinated wallet cabals, same-block bundle buys, serial-launcher deployers and same-block coordinated selling on any Solana mint (pump.fun, PumpSwap, Raydium, Orca, Meteora) — and answers the one question that matters before you ape: are you the exit liquidity? Use it via MCP (Claude, Cursor, ElizaOS), a REST API, or a free interactive 3D holder map.
The Problem
Your autonomous trading agent is reading rug.check scores, liquidity locks, and contract audits.
None of that catches a cabal.
A handful of wallets take the bottom of a launch, the chart looks clean — contract fine, LP burned, everything green — and then they sell into whoever bought after them. You are the exit liquidity.
This template integrates Cabal-Hunter as a pre-trade safety check, so your agent can see who is holding and who has already positioned to sell before it signs a swap.
A note on what we do and don't claim. This README used to open with "15 fresh wallets funded from the same master wallet, accumulating 25-40% of supply." We went looking for that pattern and could not find it. Tracing 323 pump.fun launches at the bonding curve turned up zero coordinated funding clusters, and showed why: the median launch has about five successful buyers, because on one representative token 1,260 of the curve's 1,266 transactions failed. Launch capture is a sniper race between competing bots, not a quiet cabal. The detection layers below are the ones we can actually evidence — holder concentration, same-block bundles, coordinated selling and deployer history. The pre-launch funding tracer was withdrawn; the full write-up is here.
The one question it answers: are YOU the exit liquidity?
The classic pump.fun exit-liquidity setup: wallets positioned before the crowd take the bottom of a launch, then dump on the retail (and bots) that pile in after. Cabal-Hunter's headline output is a single Exit-Liquidity Risk verdict — risk_level, one of LOW_SIGNAL | ELEVATED | HIGH that synthesises every signal below into the only thing that matters before you sign a swap: are the insiders positioned to dump on you?
What Cabal-Hunter Does
Token mint address
↓
0. EXIT-LIQUIDITY RISK — the headline verdict. Synthesises the layers
below (bundle, concentration, shared funder, coordinated selling,
serial-launcher dev) into risk_level: LOW_SIGNAL | ELEVATED | HIGH.
Are insiders set up to dump on a buyer? The one field an agent needs.
↓
1. HOLDER FUNDING TRACE (ONE HOP) — the CURRENT top holders walked back
one funding hop: were they seeded by the same wallet? ONE hop, not a
lineage — we do not claim to follow money through a chain of
wallets. Only System-owned accounts count as
a funder, so pools, vaults and routers can never be mistaken for a
person (that mistake is exactly what got our pre-launch tracer
withdrawn). Every cluster carries evidence_txs[] — the actual
funding transactions on Solscan. This layer is genuinely rare to
fire; treat a hit as significant and its absence as no evidence
either way.
↓
2. SAME-BLOCK BUNDLE DETECTION — holders whose token accounts were
created in the EXACT same slot - a Jito bundle is one way to do that, not
the only one. Catches
stealth launches that route funding through intermediaries to
evade layer 1. Returned as `time_sync: true`.
↓
3. COORDINATED SELLING DETECTION — ≥2 holders that SOLD a meaningful
chunk (≥25% of their bag each) in the EXACT same block.
`coordinated_exit: true`, with sold_pct = % of supply sold and the
signatures in evidence_txs[]. Same-slot + meaningful-size + distinct
wallets = near-zero false positives. It reads the CURRENT holder set
at scan time, so a bundle that already sold and left the top holders
is not visible here — that is what the launch-block check is for.
For a token you already hold, POST /api/watch pushes you a webhook
the moment a dump or liquidity drain STARTS.
↓
4. DEV TRACK RECORD — the creator wallet is resolved on-chain (bonding
curve pre-graduation, pump-amm pool after — works on any age token),
and their launch history is pulled WITH THE PEAK MARKET CAP each
past token hit. `sampled` says how many of those launches we actually
walked — a very prolific wallet is sampled, not exhausted, so read
`tokens_launched` as a floor, never as a complete history.
Launch detection is venue-agnostic: pump.fun, Raydium,
Orca, Meteora and PumpSwap. A launch is only counted where the
transaction actually CREATED the mint, so minting more supply of a
token that already exists is never miscounted as a launch.
A dead-count alone hides a pump-and-dump: a dev whose
tokens all died at $4k is a nobody, but one who ran a token to $728k
then dumped it to dust has done it to holders before. Reputation:
FIRST_LAUNCH | PROVEN | MIXED | DEAD_ON_ARRIVAL | SERIAL_RUGGER |
UNKNOWN, with per-launch peak → now (paid tier returns the full
launches[] array). UNKNOWN means the history could not be
established — never read it as a clean record.
↓
5. CEX-NOISE FILTER — holders funded from a shared exchange or
high-volume infra wallet are NOT a cabal. They're excluded from the
score and surfaced transparently in filtered_clusters[], so you never
get a false positive from people who just withdrew from Binance.
↓
6. HONEYPOT CHECK (Solana-native) — one RPC read of the mint account:
is the FREEZE authority live (issuer can freeze your tokens — the
sell-block lever)? is the MINT authority live (supply can be
inflated)? any Token-2022 traps (transfer fees up to 100%, transfer
hooks that block sells, permanent-delegate clawback)? On Solana a
"honeypot" is built from these — tokens have no per-token contract
code to audit. Returns `honeypot_risk: LOW | HIGH` +
`freeze_authority_revoked` / `mint_authority_revoked` /
`token2022_risks[]`.
↓
Returns: Cabal Score (0-100) + cluster map + deployer verdict
+ honeypot verdict + on-chain receipts + hard verdict
The deployer layer is the one cabals can't dodge: wallets rotate, deployers leave a paper trail. A response of "deployer": {"reputation": "SERIAL_RUGGER", "tokens_launched": 22, "best_peak_usd": 728432, "pump_and_dumps": 2} shows the dev's full track record before the first candle — including whether this "dead" dev has quietly run tokens to six figures and dumped them on holders before. (Honest context: most prolific pump.fun creators have high dead-token rates, so this signal is capped — it flags a token for review but never drives a HIGH verdict on its own.)
FIRST_LAUNCH and UNKNOWN are not the same answer. deployer.verdict of
FIRST_LAUNCH means we walked this creator's history and found no earlier tokens.
UNKNOWN means the history could not be established at all — that is an absence of
evidence, not a clean record, and an agent must not treat it as one. Where a deployer
cannot be resolved the scan says so in words rather than returning a confident silence.
Receipts, not magic. Every wallet cluster carries evidence_txs[] — the raw signatures behind that cluster, checkable on Solscan, and holders carry funding_tx where we resolved one. Holder concentration, deployer history and the honeypot checks are read from chain state, so they carry no transaction of their own: a token can come back HIGH with no clusters at all. Verify what is there rather than trusting a score.