Inspiration
Ten assets. Constant updates. Limited attention.
Most market tools respond to information overload by adding more: more charts, more signals, more alerts. I wanted to try subtraction.
Ripple is an attention assistant. It takes ten assets and helps you decide which three to check first, while keeping the rest visible. The goal is to make the next inspection easier—not to turn every price movement into another notification.
I used cryptocurrency prices from Binance as the live data source because its public feed is free and available throughout the weekend. The broader problem is attention management under real-time information overload.
What it does
- Watch: Follow ten assets, with automatic updates every five minutes and an adjustable refresh interval.
- Prioritize: Rank assets by their past-30-minute volatility and highlight the top three. All ten remain accessible.
- Inspect: Click an asset to enlarge its price chart, compare observed prices with a 30-minute forecast, and see its estimated drawdown.
- Check current conditions: Compare each asset’s recent 10-minute volatility with its own 120-minute baseline, showing whether it is elevated or close to usual.
- Replay: Explore historical shocks as actual prices are revealed over time. A ripple map shows which assets triggered after others, representing timing associations rather than causation.
- Review the evidence: Compare methods against simple baselines and see the limitations and failed experiments alongside the results.
Historical recovery times appear separately as references, explicitly labeled “Historical statistics, not a forecast.” They do not claim to predict how long the current situation will last.
How I built it
A live data-to-interface loop
A Python backend fetches closed one-minute price and volume bars, validates their timestamps and values, and creates a shared snapshot for all ten assets. A lightweight JavaScript frontend displays rankings, current conditions, forecasts, and historical analysis.
Kronos-base receives the previous 256 minutes and generates a price path for the next 30 minutes. Drawdown and other numerical metrics are then calculated deterministically from that path.
Each forecast has an identifier and is cached against its input window. Switching assets reuses the same predictions. A new market window gets a new forecast, and old predictions are never silently overlaid on newer data.
Choosing methods by evidence
I built a historical catalog containing 84 shocks in January 2026 and 56 in February, then compared the original model with simple alternatives.
The model did not win every task:
| Measurement | Past-30-minute baseline | Original Kronos |
|---|---|---|
| January volatility Top3 recall — higher is better | 73.41% | 61.51% |
| January drawdown MAE — lower is better | 46.12 bps | 37.64 bps |
| February drawdown MAE — lower is better | 59.33 bps | 49.49 bps |
These results shaped the product: recent observed volatility determines priority; Kronos provides a separate drawdown estimate.
January was exploratory, and February was an observational follow-up. These comparisons support the current design but do not establish that the model will keep outperforming in future markets.
Fine-tuning—and deciding not to ship it
I also tested two LoRA fine-tuning experiments: one for volatility ranking and one for drawdown estimation. Both used predefined acceptance criteria and sealed final evaluation sets.
The ranking experiment improved the smaller-asset group’s exact-match score by 4.67 percentage points relative to the original model, but remained below simple baselines. Performance on the larger-asset group fell by 7 percentage points. The drawdown experiment did not demonstrate a reliable improvement.
Neither fine-tuned model entered the product. The experiments helped determine what to leave out.
What I learned
The most useful method is not necessarily the most sophisticated one. A simple historical baseline earned the ranking role because it performed better on that task.
I also learned that prioritization and risk estimation answer different questions. An asset outside the top three can still experience a large drawdown. Among historical cases where an omitted asset overtook the selected group’s weakest drawdown, the median excess was about 33%, and the 90th percentile exceeded 100%. Those figures describe already-missed cases, not the percentage of all events missed.
That finding changed how I describe the product: “check these first” does not mean “ignore everything else.”
Other results set clear boundaries. Direction prediction reached 51.15%, which did not establish a useful ability to predict up or down. In three selected replay events, only 10 of 30 asset-event outcomes fell inside the model’s sampled drawdown interval. Those intervals are therefore labeled uncalibrated.
Challenges
The hardest challenge was keeping the product’s claims aligned with what the evidence actually supported.
During a solo hackathon build, it is tempting to keep an impressive feature even when its results are weak. I had to make the opposite decision repeatedly: use the simpler ranking method, leave failed fine-tuning out of production, and distinguish historical references from live measurements.
The engineering challenge was keeping a changing interface consistent. Rankings, observed prices, and forecasts needed to refer to the correct data window. Cached forecasts, explicit identifiers, validation, and separate calculation and display layers made that manageable.
I am most proud of closing the loop: live data comes in, attention is prioritized, users can inspect the evidence, and historical results remain available to challenge the system’s choices.
What's next
The next step is to evaluate whether Ripple actually helps people inspect markets faster and miss fewer important changes—not just whether its forecasts score well.
I also want to test other market data sources, expand the asset universe, and explore priorities based on a user’s holdings or monitoring goals. Moving to stocks, ETFs, or foreign exchange would require adapting the feed and running fresh evaluations for their trading hours and behavior.
The central question stays the same:
With limited attention and constantly changing information, what should you check next?
Log in or sign up for Devpost to join the conversation.