The Gap Between Meridian and magersih suggestion: What It Takes to Go Fully Autonomous

August 5, 2026

The magersih branch is now live. It automates the quantitative half of the lowcap former-runner-reclaim strategy: market-cap gating, liquidity floors, concentration limits, momentum proxies, and basic organic signals. What remains is the discretionary forensic half — the on-chain detective work that currently requires human judgment.

This post maps every gap, the data source needed to close it, and the realistic build effort.


1. ATH / Drawdown Detection

Current state: The Meteora Pool Discovery API only exposes price_change_pct over the configured window. It has no all-time high history.

What "former runner" actually requires:

  • ATH at least current market cap
  • Drawdown from ATH of at least 70%

How to close the gap:

  • Integrate Birdeye API (/history/price?time_from=<genesis>) or DexScreener historical endpoints
  • Cache the global ATH per token in a local KV store
  • Compute (ATH - current) / ATH at screening time

Effort: 3–4 days (API integration + caching layer + background fetcher)


2. Key Support Reclaim

Current state: No support-level detection exists in Meridian. price_trend and price_change_pct are windowed momentum, not structural levels.

How to close the gap:

  • Option A: Ingest Birdeye / DexScreener OHLCV and run local TA-lib pivots or volume-profile support zones
  • Option B: Use GMGN smart-money signals if they expose support/resistance markers via paid API
  • Reclaim logic: price crossed above a prior support level that held on ≥2 touches

Effort: 5–7 days (OHLCV ingestion + support detection + reclaim validation)


3. Wash Trading / Organic Accumulation

Current state: unique_traders and organic_score are used as proxies. They catch surface-level fakery but miss sophisticated wash rings.

Real detection requires:

  • Helius or QuickNode streaming: pull every swap for the pool over the last 24 hours
  • Build a transaction graph: cluster addresses by common funding sources, timing correlation, and circular trading patterns
  • "Vetted wallets" = ≥2 non-clustered holders with meaningful position sizes

Effort: 7–10 days (RPC integration + graph analysis + heuristic tuning)


4. Bundle Detection

Current state: Not implemented.

What bundle detection is: At token launch, a single entity buys a large percentage of supply in the first 1–3 blocks via multiple wallets.

How to close the gap:

  • Helius webhook or historical query: filter transactions by mint in the launch-block range
  • Cluster by block_time + fee_payer + similar buy sizes
  • Flag if clustered wallets collectively hold > X% of supply

Effort: 5–7 days (block parsing + clustering algorithm + threshold calibration)


5. Dev Sell Tracking

Current state: The dev address is known (token_x.dev), but there is no transaction monitoring.

How to close the gap:

  • Poll the dev wallet via Helius (getSignaturesForAddress) every N minutes
  • Parse sells: swaps token → SOL, or transfers to CEX deposit addresses
  • Alert / hard-reject if the dev sold > Y% of their stack recently

Effort: 3–4 days (polling service + sell parser + screening integration)


6. Removable LP Check

Current state: Not available.

What it means: Can the pool creator withdraw liquidity unilaterally? In Meteora DLMM, pool authority configurations vary.

How to close the gap:

  • Direct Solana RPC call: fetch the pool account and decode pool_creator / reserve_a_authority / reserve_b_authority
  • Check if authorities are burned (11111111111111111111111111111111) or controlled by a single key
  • Requires @solana/web3.js account decoding, not Discovery API data

Effort: 2–3 days (account decoding + authority checks + false-positive tuning)


7. Integration Wiring

Even after each individual detector works, they must be merged into a single screening pipeline:

  • Async security checks inside tools/screening.js
  • Caching layers (do not re-query ATH every 5 minutes)
  • Fallback semantics when APIs rate-limit or are disabled
  • Config toggles: useBirdeye, useHelius, magersihStrictMode

Effort: 3–5 days (glue code + error handling + testing)


Summary Table

| Gap | Primary Data Source | Build Time | |-----|---------------------|------------| | ATH / Drawdown | Birdeye / DexScreener | 3–4 days | | Support reclaim | OHLCV + TA-lib | 5–7 days | | Wash trading | Helius tx graph | 7–10 days | | Bundle detection | Helius block 0–3 | 5–7 days | | Dev sell tracking | Helius wallet poll | 3–4 days | | Removable LP | Solana RPC account decode | 2–3 days | | Integration glue | — | 3–5 days | | Total | | ~28–40 days |


Cost Reality Check

| Resource | Free Tier Limit | Paid Tier Cost | |----------|----------------|----------------| | Birdeye API | Rate-limited | ~$50–200/month for historical data | | Helius | 100 req/s free | ~$50–100/month for intensive tx fetching | | QuickNode | Limited | ~$50–300/month depending on plan |

Dev cost at different rates:

  • Self-built (evenings): 4–6 weeks of after-hours work
  • Offshore contractor: $3–6K
  • US/EU contractor: $8–15K

Pragmatic Alternative: Hybrid Mode

The current magersih branch already delivers 80% of the value for 5% of the work. A practical workflow:

  1. Bot does the mechanical filtering: MC, liquidity, concentration, basic momentum
  2. You eyeball the chart for 30 seconds: confirm "former runner + reclaiming support"
  3. Bot handles the rest: position sizing, entry shape, aggressive TP/SL

Full automation is only worth the build cost if you are deploying at scale (≥ dozens of pools per day). For selective low-cap hunting, the hybrid approach is the optimal risk/reward tradeoff.