Appendix
Storage and Runtime Reference
Appendix-level detail on the current runtime jobs, SQLite tables, and how the public scanner is materially assembled.
Current Implementation
This page is intentionally explicit and implementation-first. If the product or upstream APIs change, the current behavior described here can change with them.
Runtime components
| Component | Current role |
|---|---|
gamma_client.py | Fetch paginated markets and events from Gamma |
scraper.py | Build the active outcome snapshot and tags |
smart_money_scraper.py | Fetch holders, wallet PnL, and smart-money counts context |
auto_refresh.py | Coordinate hourly scrape and 6-hour smart-money runs |
main.py | Serve API routes and public static surfaces |
Primary tables
| Table | Current purpose |
|---|---|
active_market_outcomes | Active outcome snapshot shown in the scanner |
market_tags | Tag lookup for include/exclude category filtering |
holders | Sampled holders keyed by condition id and outcome index |
wallets_stats | Wallet PnL, alias, and wallet tags |
market_smart_money_stats | Stored background smart_money_win_rate values and timestamps |
Request logging
The metrics database also stores request_logs for API timing and diagnostics.
Indexing and read path
The backend ensures indices on commonly queried fields such as:
pricespreadvolume_usdliquidity_usdaprquestionoutcome_name
This is one reason the scanner can stay simple while still serving a large active snapshot.
Why this matters publicly
This appendix exists so users can understand where the app is doing straightforward storage and where it is applying interpretation layers. A transparent scanner is easier to trust, especially when it openly documents its own limits.