The problem
In digital-asset markets, a significant share of sharp price moves is preceded by an observable supply event: a scheduled token unlock, a burn, a large transfer to an exchange. The information is public and recorded on-chain — but scattered across several networks and data providers, and it rarely arrives at the right moment.
This project consolidates those signals into a single stream, scores them by significance, and alerts. It is deliberately an observation tool: the execution side exists in the code but stays disabled by default, behind several locks.
What I built
Multi-chain monitoring
one high-throughput network and four EVM-compatible networks tracked in parallel.
Multi-source aggregation
several providers of unlock schedules and market data, with automatic fallback from one to another.
Scoring engine
events weighted by relative magnitude and context, to strip out noise.
Instant alerts
formatted notifications pushed over messaging.
Automatic discovery
periodic sweep of the largest assets to extend coverage without manual configuration.
Backtesting
historical replay of signals to measure their relevance before trusting them.
Dashboard
an interface for reviewing events and their scores.
Architecture & technical decisions
The system is written in asynchronous Python, because the workload is almost entirely network waiting: querying chain nodes and external APIs in parallel is precisely the case where async changes the achievable scale.
Each signal family is handled by an independent worker — unlocks, valuation, on-chain events, news — coordinated by a scheduler. A source going down does not take the system down: it degrades one dimension of the score, visibly.
External providers sit behind a common interface with retries and fallback. In this field APIs change, impose quotas or disappear: no single source may be structural.
The execution side is protected by a three-position switch — off, paper, live — with strict risk limits and a test environment by default. The default behaviour of an automated financial tool should be to do nothing.
Technical challenges
Contradictory data. Two providers rarely announce the same unlock schedule: you have to arbitrate, timestamp, and keep the provenance of every data point.
Noise. An alerting system that alerts too often stops being read — scoring exists as much to filter as to rank.
API quotas. In-memory TTL caching, exponential retries and call batching to stay within provider limits.
Measuring relevance. Backtesting exists precisely to avoid believing a signal on its apparent obviousness.
Safety discipline. Strictly separating observation from execution, and making inaction the default.