Cabal Hunter

Solana Safe Sniper — MCP Template

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

📡 New: Dev Launch Radar. When a pump.fun dev from our library launches a new token, Pro gets an alert in about a second (median 0.8 s): the dev's record read from the chain, the dev's own buy and every wallet that bought in the first seconds. In Telegram (/radar on in @TheCabalHunter_Bot), the Chrome extension's Radar tab, the radar page and email. Every alert and its result, wins and losses: cabal-hunter.com/dev-radar

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 →](https://api.cabal-hunter.com/demo) — 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](https://api.cabal-hunter.com) 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

↓

1. 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. ↓
2. 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. ↓
3. 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. ↓
4. 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. ↓
5. 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. ↓
6. 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. ↓
7. 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.

Response in <100ms for a mint traced in the last 8 hours — computed_at (unix seconds) says exactly when that trace ran. Any other mint runs a live on-chain trace and takes 15-20s, so allow a 30s timeout.

Free tier: 5 scans/month with no account, or 250/month with a free key (one email). Then $0.01 per scan. Pay by card, in USDC on Solana, or via x402 — same price through every door. $9/month buys 2,500 scans a month and $99/month buys unlimited fair-use scans (50,000 a month); by card a plan renews automatically and can be cancelled anytime at cabal-hunter.com/billing.

---

Quick Start

1. Claude Code / Claude Desktop

Add to your MCP config (~/.claude/mcp.json or project .mcp.json):

{

"mcpServers": { "cabal-hunter": { "url": "https://api.cabal-hunter.com/mcp" } } }

That's it. Claude will now call check_cabal_risk automatically when you ask it to analyse a Solana token.

Example prompt:

"Before we buy into this token, check if there are any coordinated wallets: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"

Claude calls the tool, pays $0.01 USDC from your connected wallet, and returns the full analysis.

---

2. Cursor

Add to .cursor/mcp.json in your project root:

{

"mcpServers": { "cabal-hunter": { "url": "https://api.cabal-hunter.com/mcp" } } }

---

3. ElizaOS (with automatic x402 payment)

If you're using ElizaOS with @hugen/plugin-x402-solana, payment is handled automatically. Add to your agent config:

{