Bot type
Signals with a timestamp you can defend
A Telegram trading signal bot distributes signals to tiered subscribers, records exactly what was sent and when, and manages subscription state. Telegram cannot deliver simultaneously to a large list, and that constraint shapes the whole design. It has no view on whether your signals are any good.
Trading signal bots: price, timeline and limits
- Fixed price
- $6,700 USD
- Delivery
- 28 calendar days from kickoff
- Broadcast ceiling
- ~30 messages/second across all chats
- Channel economics
- One channel post serves every subscriber, not one message each
- Corrections
- A bot can edit its own messages after sending
- Delivery proof
- Send confirmation only, no read receipt
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Signal distribution looks like a broadcast problem and is really an accountability problem. Subscribers pay for information whose value decays in seconds, so the two questions that matter are whether everyone received the same thing and whether the timestamp on it can be defended. A group chat answers neither: messages can be edited, deleted, and posted at different times to different tiers with no record.
The constraint that determines the architecture is that Telegram paces bot messages at roughly thirty per second overall. A list of five thousand subscribers therefore takes about three minutes to reach completely. The first recipient and the last are separated by a real interval, and in a market that is a real advantage. Pretending otherwise, or claiming simultaneous delivery, is a promise the platform makes impossible to keep.
The defensible design accepts it and makes it transparent. Signal content is fixed and hashed at creation, delivery order is randomised per send so no subscriber is systematically first, and every subscriber's delivery timestamp is recorded and visible to them. Subscribers can verify that what they received matches what everyone else received, and that they were not consistently last. That is achievable, honest, and considerably more than most signal channels offer.
How the build runs
A signal is created and immediately frozen
Content, timestamp and a hash, written before any delivery begins. Freezing at creation is what makes the audit trail meaningful — a signal that can be edited after the fact records nothing useful.
commandsThe recipient list is resolved from live entitlement
Checked at send time rather than from a cached list, so a lapsed subscriber does not receive one more signal and a new one is not missed.
webhookDelivery order is randomised for every send
Telegram paces sends, so someone is first and someone is last. Randomising per send means it is not the same person each time, which is the only fairness available under the constraint.
broadcastEvery delivery is timestamped individually
Recorded per subscriber, not per signal. A subscriber querying their history sees exactly when each signal reached them, which is what turns a claim about fairness into something checkable.
webhookSubscribers can verify what they got
A command returns the hash of any signal alongside their own delivery time. Two subscribers comparing notes can establish that they received identical content, without trusting the operator.
commandsFailed deliveries are retried and reported
A blocked bot or a network error is recorded and surfaced, rather than silently reducing the recipient list. A subscriber who paid and received nothing is a refund, and it should be visible before they ask.
webhook
What Telegram will and will not let you do
A bot may send roughly 30 messages per second in total across all chats.
Five thousand subscribers take about three minutes to reach. Simultaneous delivery is not achievable, and any product claiming it is either using channels — where subscribers pull rather than receive — or misrepresenting the platform.
A channel post is a single message that all subscribers read, rather than one message per subscriber.
Channels genuinely are simultaneous, at the cost of losing per-subscriber entitlement and delivery records. Tiered products therefore use direct delivery and accept the window.
A bot can edit its own messages after sending.
Without content hashing at creation, a signal is retroactively editable and the history proves nothing. The hash is what makes the audit trail defensible.
A user who blocks the bot causes sends to fail with an explicit error.
Paying subscribers do occasionally block by accident. The failure is surfaced to operations rather than silently shrinking the list, since the subscriber has paid for something they are not receiving.
Telegram provides send confirmations but no read receipts.
You can prove a signal was delivered, not that it was seen. Terms should describe delivery rather than implying the subscriber received it in time to act.
When not to build this
- You are promising simultaneous delivery to a large list. Telegram cannot do it, and building on the promise means shipping something that breaches its own marketing.
- You are not licensed to give investment advice in the jurisdictions your subscribers are in. The bot delivers whatever you tell it to; it does not confer permission to say it.
- Your subscriber count is small and untiered. A channel is simpler, genuinely simultaneous, and free.
- You want the bot to generate signals as well as distribute them. That is a different product with a different risk profile, and conflating the two produces a system nobody can audit.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with paced broadcast and per-recipient result capture. |
| Cloudflare Workers | current | Runtime, with delivery batched across invocations. |
| Cloudflare D1 | current | Signals, hashes, subscriptions and per-subscriber delivery records. |
| Cloudflare Queues or cron | current | Paced delivery that survives an invocation limit mid-send. |
| TypeScript | 5.9 | Strict mode throughout. |
Questions people ask before committing
Can every subscriber receive a signal at the same instant?
Not through direct messages. Telegram paces bot sends at around thirty per second, so a five-thousand-subscriber list takes roughly three minutes end to end. A channel post is genuinely simultaneous, but gives up per-subscriber entitlement and delivery records.
How do subscribers know they were not systematically last?
Delivery order is randomised per send and each delivery is timestamped individually. A subscriber can query their own history and see the distribution over time, which turns a fairness claim into something they can check rather than trust.
What stops a signal being edited after the outcome is known?
Content is hashed at creation, before delivery begins, and the hash is retrievable by any subscriber. An edited message would no longer match, which is the whole point of freezing it first.
Does the bot decide what the signals are?
No. It distributes what you publish and records what it distributed. Signal generation is a separate product with a very different risk profile, and combining the two would make the audit trail meaningless.
How are subscriptions taken?
Through Telegram Stars for smaller amounts or a conventional provider for larger ones, with entitlement checked at each send rather than at signup. That is what makes lapse and renewal behave correctly.
What about regulation?
Distributing investment signals is regulated in most jurisdictions your subscribers are likely to be in, and the bot does nothing to address that. It is a question for your counsel, and it is upstream of the build rather than part of it.