A roadmap is a plan—not proof of delivery.
Clear status labels make it easier to understand what this prototype includes and what still needs to be built.
The roadmap is presented as a directional sequence rather than a promise of dates. The current deliverable is a website prototype with educational content, a demo dashboard, and a local simulator. No live monitoring, database, wallet, token, or notification infrastructure is connected.
Establish a transparent product surface
The first visible step is a coherent website that explains the product, links its concepts together, and states limitations clearly. This prototype includes the 15 core content routes, global navigation, SEO metadata, and an illustrative dashboard and simulator.
This is the only stage represented as delivered in the current build. It is not a claim that a production data service or token ecosystem exists.
Define coverage before promising monitoring
A subsequent stage would specify which BNB Smart Chain contracts, pools, and event families are in scope. It would define RPC reliability, indexing, backfill, finality handling, provenance, and freshness indicators before a live alert is shown.
This work is planned, not operational. The Technology page describes the architecture questions that need answers.
Build and validate the first monitoring surfaces
Whale activity, liquidity changes, and unusual selling activity would require separate classification rules and test datasets. Each signal should expose the transaction, threshold, baseline, and confidence caveats that produced it.
A useful release should measure false positives and missed events and include a review process for inaccurate labels. The feature pages currently describe goals, not working monitors.
Make contract observations auditable
A future scanner could collect verifiable public contract facts such as source verification, owner roles, mint behavior, and transfer restrictions. The team would need to publish scope and limits and avoid presenting a single score as a safety certification.
No scanner or audit is currently connected. See Risk Scanner and Security & Transparency for the intended language and evidence requirements.
Add persistence only with clear user controls
Saved watchlists, alert preferences, and history may require account-backed storage. A production implementation would need data minimization, authentication, deletion controls, and careful access checks. Opt-in notifications should be verified and easy to disable.
PostgreSQL, WalletConnect, and Telegram are not configured in this build. No user data is currently saved by the dashboard preview.
Evaluate token and API plans on their merits
A public API, community contribution program, and any $ALERT utility should be considered only after their product need and operating model are clear. A token launch should not be implied through artwork or roadmaps.
No contract, tokenomics, exchange listing, or API access is verified. Follow Ecosystem and $ALERT Token for disclosures if the status changes.
Good questions deserve clear answers.
These notes reflect the current prototype status. For product details, follow the linked guides and their stated limits.
Which milestones are complete?
The current website prototype is available. Live data ingestion and production monitoring are not complete.
Are dates committed?
No. This roadmap intentionally avoids delivery dates until implementation and dependencies are established.
Is the token launch on the roadmap?
The token is a concept only. No launch, contract, or tokenomics are verified.
THE INTELLIGENCE BEHIND EVERY MARKET SIGNAL.
Stay ahead by staying curious. Verify the event, question the interpretation, and keep the limits in view.