🔎 SnipeScout

Rug checks for every new Pons launch on Robinhood Chain, and non-custodial sniping from your own wallet, in Telegram.

OpenServ Hackathon, Track 1: Mainnet & MCP · Built on SERV Reasoning, the Robinhood Chain MCP, the Pons MCP, an OpenServ agent, and x402.

🤖 Telegram bot	@SnipescoutBot
👛 Wallet Mini App	snipescout.vercel.app (open it from the bot)
🧠 OpenServ agent	#4518, with a paid deep-scan workflow
💳 x402 deep scan	0.05 USDG on Robinhood Chain, or $0.05 USDC on Base via OpenServ

---

The problem

I got rugged twice in two days on Robinhood Chain. New tokens launch every few minutes, and by the time you've checked the dev, the holders and the contract by hand, it's either pumped or it's gone. On live data, most launches are traps: in one sample of 30 recent Pons launches, 16 had rug signals. The dev had already sold 99–100% of their bag, or a single wallet had launched 8–14 tokens in 14 hours.

What SnipeScout does

1. Free rug scan in seconds. Paste any token address into the bot for a verdict (🟢 PASSED · 🟡 RISKY · 🔴 RUG), the checks behind it, and why.
2. Deep scan, explained by SERV Reasoning: the creator's track record across their previous launches, the trade flow, and anything the free scan couldn't see. You get 5 free once you create a wallet, then 0.05 USDG via x402 on Robinhood Chain.
3. Snipe from your own wallet. /snipe <token> 0.003 re-scans the token, checks the launch tax, simulates the buy, and executes it from your wallet, within limits you control.
4. Launch alerts. Every new Pons launch is scanned automatically and posted to a channel.

The use case, in one story

A trader sees a new Pons launch. SnipeScout's free scan says 🟢, so they run a deep scan, paying 0.05 USDG on Robinhood Chain from their own wallet (no card, no account, no bridge). The Robinhood Chain MCP finds the dev quietly moved 8% of supply to a side wallet, and the verdict drops to 🔴. They skip it and keep their money. Or the token stays clean, and they /snipe it: the buy is simulated through the MCP, their wallet signs within their limits, and it's done in seconds.

---

How it works

                 Telegram user
      ┌──────────────┴──────────────┐
      ▼                             ▼
 @SnipescoutBot              Wallet Mini App (Vercel)
 (OpenServ Cloud)            Privy wallet · enable sniping · export key
      │                      · sign x402 USDG payments
      │                             │  onboarding + payment API (Vercel functions)
      ▼                             ▼
 ┌─────────────────── always-on (OpenServ Cloud) ─────────────────────┐
 │ commands · launch monitor · x402 settlement worker · OpenServ agent │
 │                                                                     │
 │  Pons MCP ──────────── launches, curve state, quotes, snipe tax,    │
 │                        trades, creator history                      │
 │  Robinhood Chain MCP ─ hidden-wallet transfers, stock-token checks, │
 │                        balances, trade simulation, x402 USDG        │
 │                        verification + settlement                    │
 │  SERV Reasoning ────── plain-English explanations, deep reports     │
 └─────────────────────────────────────────────────────────────────────┘
      │                                          │
      ▼                                          ▼
 Neon Postgres (scans, users, positions,    Robinhood Chain (4663)
 deep scans, x402 payments)                 Privy signs · we broadcast

Verdicts: code decides, AI explains

The verdict comes from deterministic rules (agents/research.ts), never from an LLM. SERV Reasoning writes the explanation and may downgrade a verdict when it cites a concrete number, but it can never upgrade one. Any check that couldn't run counts as a risk, and a token is only snipe-eligible if every key check returned real data.

Rug signal	Source
Sell quote fails (honeypot)	Pons MCP pons_quote_sell
Dev already sold ≥ 50% of their bag	Pons MCP pons_curve_trades
Dev moved supply to side wallets	Robinhood Chain MCP token_transfer_history
Serial launcher (≥ 5 tokens in ~14 h)	Pons MCP pons_creator_launches
Fake stock ticker ($TSLA, $NVDA… that isn't the real stock token)	Robinhood Chain MCP verify_stock_token
Top-10 buyers or dev hold too much; high creator tax	Pons MCP

How the Robinhood Chain MCP is used

Use case	Tools
Seeing what launchpad data hides	token_transfer_history (hidden side wallets), verify_stock_token (fake stock tickers), token_metadata
Getting paid natively on Robinhood Chain (x402)	verify_authorization_signature → check_authorization (replay) → get_token_balance → build_transfer_authorization_calldata → estimate_gas
Trading safely	get_balance (enough ETH?), estimate_gas (simulate the buy from the user's wallet before signing)

x402 on Robinhood Chain (USDG)

The public x402 facilitator doesn't serve Robinhood Chain, so SnipeScout settles payments itself, with the Robinhood Chain MCP doing the verification:

1. /deep <token> pay opens the Mini App, which shows an EIP-3009 TransferWithAuthorization for 0.05 USDG.
2. The user signs it in their own wallet. It's a signature, so they pay no gas.
3. The worker verifies the signature, checks for replay and balance, builds the settlement, and simulates it, all via the MCP. It then submits it on-chain.
4. The deep scan is delivered to the user's chat, with the payment's transaction link.

Tampered amounts, other people's wallets, replays and empty balances are all refused, and no USDG moves unless every check passes. OpenServ's own x402 paywall (USDC on Base) stays available as a second option.

Non-custodial by design (Privy)

• Each user gets a Privy embedded wallet created at Telegram login. Nobody but the user can export the key: not SnipeScout, not our servers.
• To enable sniping, the user grants the bot a signer tied to their own policy, which only allows the bot to:
  • call the curve's buy() on chain 4663,
  • spend at most 0.005 ETH per trade,
  • send the tokens only to the user's own wallet.
• The user owns that policy, so the operator can't quietly loosen it later. Users can revoke the bot anytime.
• Proven on a real wallet by npm run privy:policy-test (it signs only, and never sends):

Test	Result
Buy to own wallet, within cap	✅ allowed
Buy that sends tokens to another wallet	✅ refused
Buy above the cap	✅ refused
Wrong chain	✅ refused
Operator tries to export the user's key	✅ refused
Operator tries to edit the user's policy	✅ refused

Privy only signs. SnipeScout sends the signed transaction through the Robinhood Chain RPC, so nothing depends on Privy supporting chain 4663.

---

Commands

Command	What it does
paste an address / /scan <address>	Free rug scan
/deep <address>	Deep scan (free trial, then pay options)
/deep <address> pay	Pay 0.05 USDG via x402 on Robinhood Chain
/snipe <address> <eth>	Buy from your own wallet after a fresh re-scan
/wallet	Your address plus ETH and USDG on Robinhood Chain and USDC on Base
/earnings	Operator only: x402 revenue

Tech

TypeScript · OpenServ SDK + client · SERV Reasoning (claude-haiku-4.5 via inference-api.openserv.ai) · Robinhood Chain MCP · Pons MCP (bundled build, MIT) · Privy (server + React) · viem · Hono · Neon Postgres · Vite + React Mini App · Vercel · OpenServ Cloud

main.ts / src/agent.ts   entry: bot + agent + x402 worker + monitor (RUN_* switches)
index.ts                 OpenServ agent: capabilities + x402 deep-scan workflow
bot.ts                   Telegram bot (trusted sender IDs, zero LLM cost per command)
agents/research.ts       MCP research + deterministic rules (no DB/LLM: testable offline)
agents/security-scanner  scan = research + rules + optional SERV + Postgres audit trail
agents/deep-scan.ts      creator track record + SERV report + free-trial accounting
agents/x402-settler.ts   USDG x402 settlement via the Robinhood Chain MCP
agents/sniper.ts         snipe checks → privy-executor (user wallet) | operator-executor
server/onboarding.ts     Mini App API: onboarding, per-user policy, x402 quote/submit
api/index.ts             the same routes as a Vercel function
miniapp/                 Telegram Mini App (Privy wallet, enable sniping, pay, export)
db/schema.sql            tables + atomic free-deep-scan claim

Run it yourself

npm install
cp .env.example .env                 # fill in the values (see comments in the file)
npm run db:setup                     # create tables in Postgres
npm run privy:create-signer          # the bot's signer; its key is written to .env, never printed
npm run dev                          # bot + agent + x402 worker (+ monitor)

npm run fixtures:record -- 30        # research the 30 latest launches (no credits used)
npm run test:rules                   # verdict distribution on those fixtures
npm run privy:policy-test -- <tg id> # prove a user's policy (sign-only)

Deploy: the Mini App and its API with npx vercel deploy --prod; the bot, agent and worker with npm run deploy:openserv (OpenServ Cloud, always on; secrets are sent separately from the code).

Findings from live mainnet

• Blockscout's API blocks server clients (403), so holder data is rebuilt from Pons curve trades, and chain facts come from RPC-based MCP tools.
• token_transfer_history defaults to the latest block only, so SnipeScout scans from the token's launch block.
• The Pons snipe-tax window is about 3 seconds. Blocks are about 0.1 s.
• On one sample of 30 launches: 16 RUG, mostly devs who'd already sold, and serial launchers. Hidden side wallets showed up on 2 of 5 fresh launches.

Limits (beta)

• Keep small amounts in your wallet. Checks reduce risk; they don't eliminate it. Not financial advice.
• Only pre-graduation, ETH-paired Pons tokens can be sniped. Selling happens outside the bot for now (export your key, or use Pons).
• The public Robinhood Chain RPC rate-limits under load; production should use a dedicated RPC.

License

MIT. The bundled Pons MCP build is MIT-licensed by its authors (see mcp/pons-mcp/LICENSE).