One local system turns noisy Solana markets into controlled decisions
ScreenerBot is a continuously running Rust service graph, not a single buy-and-sell script. Independent systems discover tokens, enrich and filter them, maintain two distinct price paths, evaluate safety and strategies, route swaps, and manage positions under your configuration.
Runtime
One Rust process with an embedded dashboard
Orchestration
21 dependency-managed services
Money unit
SOL for sizing, pricing, and P&L
Ownership
Keys, config, and databases stay local
A service graph, not one loop
Connectivity, tokens, pools, filtering, OHLCV, positions, transactions, wallets, Auto Trader, AI, Telegram, and the webserver have separate lifecycles. The service manager starts enabled systems in dependency order, monitors their health, and stops them in a coordinated shutdown.
Readiness before execution
A loaded dashboard does not automatically mean trading is ready. Connectivity, tokens, positions, pools, and transactions must all publish readiness before manual or automated trade endpoints can execute.
Three startup tiers use the same application
ScreenerBot starts only the services that are safe and useful for the credentials currently available.
Setup tier
No config.toml
The webserver starts alone so the first-run flow remains available.
Preview tier
Wallet and RPC skipped
Discovery, tokens, filtering, events, and the dashboard run without wallet-dependent trading.
Full tier
Credentials validated
All enabled services start in dependency order; trading remains gated until critical systems report ready.
The market-to-position lifecycle
This is the logical path of an opportunity. Background refresh, filtering, pricing, storage, and health monitoring continue around it at different cadences.
Discover candidates
Enabled market and token feeds run concurrently, returning new, updated, trending, boosted, verified, and actively traded Solana candidates.
Output / Normalized mint candidates
Normalize and deduplicate
Invalid addresses, SOL, and stablecoins are removed. Candidates from multiple sources merge into one token identity before storage.
Output / One record per mint
Load market and risk context
Background updates collect metadata, liquidity, market activity, authorities, holders, RugCheck data, and pool snapshots.
Output / Inspectable token context
Apply deterministic rules
Metadata and on-chain checks run before external market and risk stages. Optional AI filtering runs only after standard filters pass.
Output / Passed, rejected, or blacklisted
Track prices and signals
Direct pool reserves supply live SOL prices for trading and P&L, while historical OHLCV candles supply strategy and indicator context.
Output / Execution price + signal history
Evaluate entry safety and strategy
Only pool-tracked tokens that passed filtering reach the entry loop. Safety checks must pass before an enabled strategy can signal a buy.
Output / No action or trade decision
Quote and submit
Enabled swap routers are queried concurrently. ScreenerBot selects the highest output, signs locally, submits, and records the transaction.
Output / Confirmed position or visible failure
Manage the open position
The exit loop continually applies blacklist, emergency risk, optional AI, stop-loss, trailing, ROI, time, and strategy rules in priority order.
Output / Hold, DCA, partial exit, or close
Two price systems with separate jobs
ScreenerBot deliberately does not use historical API candles as the primary trading price.
Live pool prices
Pool accounts are fetched through Solana RPC and decoded locally. Reserve math produces fast SOL-denominated prices for entry decisions, current position value, P&L, stops, DCA, and exits.
Historical OHLCV
Candles come from the shared ScreenerBot data cache first, with configured provider fallbacks. They support charts, indicators, and strategy conditions across multiple timeframes.
The two streams may appear together on a chart, but they are not interchangeable. Pool prices drive money decisions; OHLCV supplies historical strategy context.
Filtering narrows the market before strategies
Passing filters means a token is eligible for further consideration. It is not an instruction to buy.
Metadata
Name, symbol, age, description, and general eligibility.
On-chain
Program ownership, authorities, token accounts, and low-cost scam checks.
Market source
Enabled DexScreener or GeckoTerminal liquidity, cap, volume, change, and pool rules.
RugCheck
Risk score, authority, insider, holder, transfer-fee, and liquidity-provider rules.
Optional AI
Runs last so AI credits are spent only on tokens that passed deterministic checks.
Auto Trader has independent entry and exit loops
New exposure and existing-position protection are separate controls so one can pause without silently changing the other.
Entry loop
The loop intersects tokens that passed filtering with tokens that have live pool prices, then applies these gates in order before a strategy can create a decision.
Exit loop
Each auto-managed position is evaluated by priority. The first matching exit condition produces the decision for that cycle.
Manual positions remain yours
A manual buy defaults to manual management. The automated exit and DCA loop leaves that position alone until you explicitly return it to Auto Trader management.
Execution and safety form a hierarchy
Enabled routers quote concurrently, the highest valid output is selected, and the wallet signs locally. Eligible failures can fall back, but a submitted transaction is never duplicated. Around that path, different safety controls intentionally have different scopes.
Force stop
Halts entry, exit, manual swap execution, and automated execution until explicitly resumed.
Loss limit
Blocks new entries after the configured realized-loss threshold while exit monitoring continues.
Monitor toggles
Pause entries independently; disable exits only when open positions will be managed another way.
Per-entry guards
Connectivity, capacity, duplicate exposure, cooldown, blacklist, and strategy checks block unsafe buys.
Local domain storage
Tokens
Identity, metadata, market, security, pools, and filtering state.
Pools & OHLCV
Live pool history and historical candlesticks remain separate.
Positions & transactions
Entry, DCA, partial exit, close, signatures, and P&L records.
Events & actions
Discoveries, decisions, errors, service state, and visible trade progress.
Wallet & configuration
Encrypted credentials, balances, settings, and user-defined controls.
Your machine is the control plane
Configuration, encrypted wallet material, SQLite databases, logs, and the trading process live on the computer running ScreenerBot.
Everything important is observable
Dashboard state, actions, transactions, events, service health, RPC metrics, and logs expose the path from candidate discovery to execution or rejection.
Automation executes your policy
ScreenerBot automates repeated work, but the boundaries and risk policy remain yours.
ScreenerBot continuously handles
- Discovery, normalization, and data refresh
- Pool monitoring and SOL price calculation
- Filter evaluation and rejection recording
- Strategy, entry, DCA, and exit monitoring
- Quotes, transactions, records, events, and health metrics
You remain responsible for
- Wallet selection, funding, backups, and machine security
- RPC reliability and enabled market sources
- Token filters, blacklists, and allowed risk
- Position sizing, DCA exposure, and exit configuration
- When manual or automated trading is allowed to run
Install ScreenerBot
Choose desktop or headless operation.
Configure safely
Use preview mode or connect a wallet and RPC.
Tune filtering
Inspect every pass and rejection stage.
Control automation
Configure entry, exit, DCA, and safety.