SCREENERBOTDocs
DocsDashboard GuidesFiltering
Dashboard / Filtering

Solana token filtering you can inspect, explain, and tune

ScreenerBot evaluates discovered tokens through ordered, deterministic stages. A token stops at the first enabled rule it fails, while every decision remains visible through live status, historical analytics, and the rejection explorer.

Execution

Sequential with early rejection

Configuration

Hot-reloadable dashboard controls

Evidence

Reason, source, token, and timestamp

The actual Filtering dashboard

These guides mirror the eight tabs available in the desktop dashboard. Status, Analytics, and Explorer explain results; the remaining tabs configure the stages that produce them.

StatusLive cache health, data coverage, passed candidates, blacklists, and top rejection reasons.AnalyticsPass rate and rejection behavior across preset or custom time ranges.ExplorerBrowse rejection reasons and inspect the exact tokens rejected by each rule.CoreMinimum token age and post-exit cooldown checks that run first.On-ChainSymbol, authority, known-scam, and combined-risk checks.DexScreenerToken profile, liquidity, market cap, activity, volume, and momentum filters.GeckoTerminalIndependent market checks with multi-window activity and pool metrics.RugCheckReport risk, authorities, holders, insiders, LP structure, creator share, and transfer fees.

Filter chain

Enabled stages run in order. The first failed rule records a specific reason and stops evaluation for that token. Passing every active stage makes the token available to downstream selection and trading logic.

01CoreAge and cooldown02On-ChainIdentity and authorities03DexScreenerPrimary market profile04GeckoTerminalIndependent market checks05RugCheckSecurity report rules06AIOptional final analysis

When a token passes

  • Every enabled stage returned an acceptable result.
  • The token appears in the current passed set used by downstream candidate selection.
  • Passing is not permanent; refreshed data or changed configuration can alter the result.
  • Passing is not a promise of safety, execution quality, or profitability.

When a token is rejected

  • The first failed rule records a source and human-readable reason.
  • Status summarizes the current rejection pressure.
  • Analytics compares reasons and sources across time.
  • Explorer reveals the exact token records behind a reason.

A safer tuning loop

01

Observe

Start in Status and confirm the snapshot is fresh.

02

Compare

Use Analytics to find the dominant category and rule.

03

Inspect

Open Explorer and review representative rejected tokens.

04

Adjust

Change one setting, save it, and repeat the observation cycle.