Crypto Lens

The problem

Crypto signals are scattered across price, technical indicators, news feeds, and macro/cycle metrics — and most automated feeds blur observable facts with buy/sell advice. Two different jobs get tangled together: aggregating the sources, and deciding what they mean.

Crypto Lens keeps them apart, and keeps the public surface honest.

What is being tested

Whether an agentic pipeline can pull scattered sources into market updates worth reading — and then serve them across two surfaces with deliberately different rules.

A scheduler runs the recurring pipelines that fill a local store, each writing to its own table: RSS/news sentiment four times a day; daily and hourly technical analysis across timeframes; hourly state classification, large-move alerts, and narrative triggers; hourly scans of mainstream-news sources; daily macro metrics; and a weekly long-term token and cycle snapshot.

Two outputs sit on top, separated by a routing rule enforced in code rather than by editorial discipline:

• a private research bot for the owner — token reports, market-state dashboards, portfolio and state views, CSV export, and manual pipeline triggers — which is allowed to carry verdict-bearing material like state labels, swing setups, and validated signals;
• a public channel held to observable facts only — large-move alerts and a weekly market/cycle snapshot with a rendered chart — with no conviction labels, no price targets, and no recommendations.

The central bet is that the fact/verdict boundary can be held in code.

Technology

An always-on service, not a request/response app.

• Python 3.13 asyncio service, with APScheduler driving every recurring pipeline.
• python-telegram-bot for both surfaces, with FastAPI/Uvicorn alongside.
• Pydantic-AI agents over Gemini (via OpenRouter and the Google API) for the token narratives, behind a significance/change gate that suppresses low-information updates.
• Market and macro data via ccxt / python-binance, CoinGecko, CoinMarketCap, FRED, and yfinance; TA-Lib for indicators; feedparser and Tavily for news and RSS.
• SQLite for persistence, one table per pipeline.
• Deployed from a Dockerfile (TA-Lib built from source) as two processes — jobs and telegram — defined in a Procfile.

What works today

• The scheduler with the full set of recurring jobs, and a private bot with working handlers — report, news, state, portfolio, summary, export, manual run, market analysis, push, and help.
• Multi-timeframe technical analysis, a rule-based state classifier, RSS sentiment ingestion and summarization, a unified narrative service, insight generation, and a trading-signal validator.
• A long-term metrics subsystem with collectors across Binance, CoinGecko, CoinMarketCap, FRED, yfinance, and sentiment, plus cycle, correlation, and aggregation calculators.
• Public-channel chart rendering and centralized message formatting that respects Telegram's message-splitting and photo-caption limits, with a test suite over the TA, charts, move-alert policy, formatting, and insight components.

What I learned

What the build settled, ahead of any signal-quality data:

• The fact/verdict separation only holds if it is enforced in code. On an always-on system, editorial discipline fails; a routing rule does not.
• A significance/change gate is what keeps a continuous feed from becoming noise — emit a narrative only when something has actually moved.
• One pipeline feeding two surfaces is efficient, but it couples the whole system to a long list of external APIs and two persistent processes. That coupling is the real cost of the design.
• Discipline about what to publish is not the same as proven signal quality — which is exactly what the project still cannot show.

Limitations and what's next

What the repository does not show is whether any of it is right. There is no measure of signal accuracy, alert precision, or narrative quality, and no audience data for the public channel.

The configuration is also still moving: the model layer carries commented-out alternatives, and there are legacy tables and an in-progress long-term-metrics plan — signs of a system being tuned rather than settled.