Can you systematically identify genuine opportunities in environments with active manipulation?
Real-time fraud detection and opportunity scanner for Solana meme token markets. Monitors every new token launch, rejects 97%+ of noise, and surfaces the rare candidates worth investigating — before social media catches on.
Status: Active | Version: v2.6 | Validation: Phase 1 (in progress)
Crypto meme token markets are engineered to exploit information asymmetry. By the time a token appears on social media or trending lists, three things have usually already happened:
- Insiders have accumulated large positions
- Retail traders are being used as exit liquidity
- The manipulation is already visible on the chart — if you know what to look for
The system runs in two stages:
Scans every new Solana token launch in real time. Applies four sequential filters to reject obvious garbage before deep analysis, preventing investment waste.
Established scanning tools exist for this market. The problem is not access to data; it is access to unfiltered data. Mainstream outlets designed for retail audiences may surface tokens after social momentum has already built. By the time a token trends on any aggregator, the information advantage has already shifted to whoever was watching on-chain data before the narrative formed.
This system is built on the assumption that mainstream visibility can be a lagging indicator rather than a signal. The edge, if it exists, I think may sit in the window before retail attention arrives, not after.
INSIDER PROTOCOL
Scanning new Solana tokens for candidates
================================================================================
[1/3] Fetching token profiles... ✓ 30 retrieved
[2/3] 27 Solana tokens selected
Applying NVF filters...
🔍 CHECK 1: BASIC VIABILITY CHECKS ✓ 2/60 passed (3.3%)
🔍 CHECK 2: BUY/SELL MECHANICS ✓ 2/2 passed (100.0%)
🔍 CHECK 3: HOLDER DISTRIBUTION ✓ 2/2 passed (100.0%)
🔍 CHECK 4: METADATA QUALITY ✓ 2/2 passed (100.0%)
================================================================================
60 tokens scanned → 2 candidates (96.7% rejected)
================================================================================
# Symbol Mkt Cap Liquidity Age Virality Δ24h
──────────────────────────────────────────────────────────────
1 COO $52K $18K 15 min 0.88 +54.0%
2 hopecore $31K $13K 6 min 0.85 -8.4%
Why 5–40 minutes? The first 5 minutes are bot warfare (pure noise). But after legitimate tokens have usually gained social media attention, the incubation window has closed. Testing whether you could co-exist as an "Insider" from the outside.
Takes each candidate from Stage 1 and runs a full six-metric risk analysis, producing an Insider Confidence Index (ICI) score out of 100.
🎯 79.7/100 - 🟡 WATCH
Metric Weight Score Description
──────────────────────────────────────────────────
AC ×20 12.2 Buying vs selling pressure
LMI ×15 12.9 Liquidity depth
HVR ×15 7.8 Holder retention
IVSD ×20 20.0 Pump/dump detection
Sybil ×22 22.0 Assumes no clustering
S_ri ×8 4.8 Sell pattern
Tokens scoring 80+ with no safety overrides are flagged as candidates for manual review and potential entry.
Metrics are weighted inversely to how easily they can be manipulated.
| Metric | Weight | Why |
|---|---|---|
| Sybil detection | 22% | Root cause of most fraud — one entity faking many wallets |
| IVSD (volatility) | 20% | Hard to hide pump cycles across timeframes |
| AC (buy pressure) | 20% | Wash trading can fake this, but less easily than volume |
| LMI (liquidity) | 15% | Can be temporarily inflated then drained |
| HVR (holder retention) | 15% | Bot networks fake this by creating new wallets |
| S_ri (sell pattern) | 8% | Easiest to fake via coordinated timing |
The Sybil paradox: Sybil detection holds the highest weight (22%) despite being partially unimplemented. This is intentional. Distributing that weight across other metrics would make the model appear more complete, but it would be less accurate once Sybil detection is added. The gap is acknowledged, not hidden.
| Version | Problem | Solution |
|---|---|---|
| v1.0 | 60% false positive rate from equal weighting | Introduced weighted system prioritising hard-to-fake signals |
| v2.0 – 2.3 | Tokens with "perfect fundamentals" still rugging | Identified bot networks can fake multiple metrics simultaneously |
| v2.5 | Static snapshots missing accumulation in progress | Added concentration velocity monitoring |
| v2.6 | Current | Added AVOID override regardless of ICI score |
Still not publicly executable, needs more stress-testing and refinement
Would love recommendations and advice
Step Finance (v2.6 validation):
First Audit (T+18min): Top 10 holders = 39.3% | ICI: 79.9 WATCH
Re-Audit (T+24min): Top 10 holders = 42.1% | Trend: RISING
Final Audit (T+31min): Top 10 holders = 55.4% | +16.1% in 13 minutes
→ CONCENTRATION OVERRIDE TRIGGERED: AVOID
→ Outcome: Token dumped -64% within minutes of override
Penguin Token (v2.5 failure that led to v2.6):
Audit 1 (T+0): Top 10 = 32.9% | ICI: 80.2 HOT/BUY
Audit 2 (T+15h): Top 10 = 86.8% | ICI: 79.2 AVOID
→ Outcome: -95% price crash ($70k → $3.5k)
→ Learning: Rate of change is the signal, not the absolute level
insider-protocol/
├── scanner.py # Discovery scanner with NVF filters
├── audit_v2.py # Full audit with ICI scoring
├── nvf_filters.py # NVF filter logic
├── ici_scoring.py # ICI metric calculations
├── concentration_monitor.py # Velocity-based concentration tracking
├── audit_history.py # Audit log tracker
├── trades_log.py # Trade entry/exit performance log
├── .env.example # Environment variable template
├── .gitignore # Keeps API keys out of version control
└── data/
└── snapshots/ # CSV audit logs per scan session
The system uses the following commands:
| Command | Description |
|---|---|
discover |
Run the discovery scanner across all new token launches |
audit <TOKEN_ADDRESS> |
Full ICI audit on a specific token |
audit-history |
View all previously audited tokens |
audit-stats |
Aggregate statistics across all audits |
audit-all |
View all logged tokens |
trade-entry <TOKEN> <POSITION> <ENTRY_MC> |
Log a new trade entry |
trade-exit <TOKEN> <POSITION> <EXIT_MC> |
Log a trade exit and calculate return |
trade-active |
View all open positions |
trade-stats |
Full Phase 1 validation statistics |
Requirements: Python 3.8+, Helius RPC API key, RugCheck API token
| Gap | Impact | Roadmap |
|---|---|---|
| Sybil detection partially unimplemented | 22% weight is a placeholder | Priority 5: Helius RPC graph analysis |
| Honeypot detection has RPC timeout issues | ~ 30% of tokens may be honeypots | Priority 1: Retry logic + error handling |
| 30–60s API lag from DexScreener | Incubation window shrinks | Priority 3: On-chain bonding curve reads |
| No macro market filter | Bear market affects all tokens | Future: SOL price trend layer |
| Optimal timing window unvalidated | The 5–40 minute incubation hypothesis may be incorrect — post-hype tokens with cooling momentum could offer better risk/reward than fresh launches | Requires comparative data across both windows to determine which produces a higher hit rate |
| NVF filters may be over-restrictive | Rejecting 97%+ of tokens keeps noise low, but could be eliminating genuine candidates before they reach the audit stage | Phase 1 validation data will reveal if strong tokens are being filtered out prematurely |
| Requires manual intervention at entry decision. | ICI score is one input, not a final answer — community backing, developer history, and personal risk tolerance still require human judgment before any position is taken | Automation of entry decisions is a future consideration only after Phase 1 validates the core model |
Hypothesis: ICI ≥ 80 tokens have >50% probability of hitting 2x within the incubation window.
Phase 1 target: 15 live trades with defined entry/exit criteria
Success definition: ≥7 of 15 hit 2x OR identify specific failure mode for pivot
Live audit data (as of Feb 2026):
| Metric | Value |
|---|---|
| Total audits run | 39 |
| Unique tokens assessed | 28 |
| Average ICI score | 73.6/100 |
| Tokens in BUY zone (80+) | 6 (15.4%) |
| Tokens in WATCH zone (70–79) | 20 (51.3%) |
| Tokens in NEUTRAL zone (60–69) | 13 (33.3%) |
Live trade data (as of Feb 2026):
| Metric | Value |
|---|---|
| Total trades | 2 (both closed) |
| Phase 1 validation progress | 2/15 trades |
| WOOF | Entry $60K → Exit $8K = -87% |
| CPS | Entry $30K → Exit $7K = -77% |
| Phase 1 hit rate | 0/2 hit 2x target |
WOMP :C
Losses will be documented.
WOOF (ICI 84.0) showed a -12.1% ICI decline across three audits before crashing, and was analysed to determine whether concentration-velocity monitoring would have triggered an early-exit override.
CPS (ICI 82.3) entered above the 80 threshold with no overrides triggered.
Both cases represent the core validation question: does ICI 80+ actually predict 2x probability, or does the threshold need recalibrating?
13 trades remain in Phase 1 to answer that.
Development sequencing:
| Priority | Item | Rationale |
|---|---|---|
| Current | Manual validation using personal investments to stress test filters, scoring thresholds, and timing window | Automating before validating manually is how capital gets lost — the system needs to prove itself first |
| Near-term | Webhook integration for automated alerts when ICI threshold is met | Reduces reaction time without removing human judgement from entry decisions |
| Future | Perplexity integration for real-time data enrichment and AI-agentic execution layer | Only viable once manual validation confirms the core model is sound |
Why CSV instead of a database? During the validation phase (15–50 audits), CSV provides human-readable transparency and version controllability. Migration to a database becomes worthwhile when there are 1,000+ audits per day.
Why 2x target instead of 5x or 10x? Higher targets require longer holding periods, which increases the window for insider accumulation and makes exits harder. 2x is achievable within the incubation window and provides a clean binary success metric.
Documented failures Every version iteration came from observed failure, not theoretical optimisation.
This system is still in trial and DOES NOT predict winners. It is aimed at identifying tokens with measurably higher probability of short-term success based on quantitative metrics, behavioural patterns, and safety signals and documents what happens when those predictions are tested against reality.