System transparency
Telegram alerts have a delivery chain, not an instant promise.
“Real-time alert” language can hide several independent systems. Polytrack instead documents the path from upstream availability to ingestion, classification, eligibility, Telegram delivery, and the subscriber's device so users know what a message can and cannot promise.
The chain starts before Polytrack receives a trade.
An execution must first become available through an upstream interface. Polytrack then has to poll or receive it, validate the record, attach market and wallet context, calculate alert reasons and severity, and store it. A delay or gap at any earlier stage cannot be repaired by Telegram.
The event timestamp and notification time therefore describe different moments. The first is source context; the second is a later delivery attempt after processing.
Eligibility is user-specific.
A signed-in subscriber connects a bot token and chat ID, then chooses HIGH severity alerts, watched-wallet alerts, or both. HIGH fan-out applies only to an eligible HIGH record and enabled subscribed users. A watchlist path applies only when the user saved the matching address and enabled that switch.
If the same trade is both HIGH severity and a watchlist match for one user, Polytrack sends the HIGH message and suppresses the immediate duplicate watchlist message. This is duplicate handling, not evidence that the two alert categories are identical.
Telegram is an external delivery system.
Polytrack calls the Telegram Bot API with the subscriber's configured bot and chat. A revoked token, invalid chat, blocked bot, Telegram rate limit, network error, service outage, or later device-notification setting can prevent or delay what the user sees.
A successful send response means Telegram accepted the request under its API behavior. It does not prove when a person read the message, whether a device displayed it, or whether the market remained unchanged.
- Alert generation and message delivery are separate stages.
- The user controls the bot credential and destination.
- Duplicate suppression reduces repeated messages but does not merge rule definitions.
- No fixed end-to-end latency or uninterrupted-delivery promise is made.
A message is a handoff into research.
An alert includes compact market, side, outcome, value, wallet, category, and reason context when available, plus a dashboard link. Its purpose is to help the subscriber decide whether to inspect the full record.
The message is not an order instruction. Polytrack does not control the user's wallet, place a trade, reserve liquidity, or promise that the source fields remain current when the message is opened.
Limitations
Keep these with the conclusion.
- This note documents product stages but does not promise a service-level objective.
- Upstream, Polytrack, network, Telegram, bot, chat, and device state can each affect timing.
- A send attempt can fail after the trade has already been stored in the dashboard.
- Alert content is research context, not financial advice or an execution signal.
Sources