Bot type
The launch lasts twenty minutes and everything fails at once
A Telegram token launch bot handles allowlist registration, enforces per-participant caps, and queues contributions fairly during a sale. Its job is to survive a twenty-minute rush without over-allocating. It cannot make an unregistered sale lawful.
Token launch bots: price, timeline and limits
- Fixed price
- $8,400 USD
- Delivery
- 32 calendar days from kickoff
- Update semantics
- At-least-once, no cross-update ordering
- Allocation writes
- Read-then-write is not atomic — requires a server-side lock
- Confirmation time
- Seconds to minutes, depending on network conditions
- TON finality
- Irreversible once confirmed
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
A token sale is a load test with money attached and no second attempt. Traffic arrives in a spike measured in minutes, every participant is trying to act simultaneously, and the failure modes are all expensive: over-allocation beyond the cap, double-counted contributions, an allowlist that admits people it should not, or a queue that visibly favours whoever refreshed fastest.
What makes it harder than an ordinary traffic spike is that correctness cannot be relaxed under load. A web service can shed requests during a peak. A sale cannot allocate more than the cap because it was busy. Every check has to hold at the worst moment, which means the design has to be correct under concurrency rather than correct under test conditions and hopeful afterwards.
The second problem is perception. A sale that sells out in ninety seconds will be accused of unfairness regardless of how it ran, and the only defence is a record participants can inspect: when registration opened and closed, how the queue was ordered, what each address was allocated, and why anyone was excluded. Projects that publish this weather the accusation. Projects that ask to be trusted do not.
How the build runs
Allowlist registration runs well before the sale
Eligibility checks, wallet binding and any verification happen in a period with no time pressure. Doing identity work during the sale window is how launches fall over.
deep-linkThe allowlist is frozen and published as a commitment
A hash of the final list is published before the sale opens. Participants can verify afterwards that the list was not altered once contributions began, which is the accusation that always follows.
commandsContribution capacity is reserved atomically
A contribution takes a reservation against the cap in a single transaction before any payment is requested. Checking the cap and then allocating as separate steps is what produces over-allocation under concurrency.
webhookThe queue orders by a rule stated in advance
Registration time, a verifiable random draw, or contribution order — whichever you choose, published before opening. An unstated ordering rule is indistinguishable from no rule when participants compare notes.
inline-keyboardPayment confirmation releases the reservation into an allocation
Reservations expire if unpaid, returning capacity to the queue. Without expiry, a participant who abandons at the payment screen holds capacity that nobody can use.
payments-apiReconciliation runs throughout, not afterwards
Allocations against on-chain contributions, continuously during the sale. A discrepancy found at minute three is recoverable; the same discrepancy found after close is a refund exercise and a credibility problem.
webhook
What Telegram will and will not let you do
Telegram delivers updates at least once and without cross-update ordering guarantees.
Every contribution handler is idempotent on a client key. A redelivered update during a rush would otherwise allocate twice, and the rush is exactly when redelivery is most likely.
Reading a cap and then writing an allocation as separate operations is not atomic.
Capacity is reserved with a conditional write in one operation. This is the single most common defect in launch systems and it only manifests under real concurrency.
On-chain confirmation takes seconds to minutes depending on network conditions.
Allocation cannot wait for confirmation without stalling the queue. Reservations bridge the gap and expire if confirmation never arrives, which is why expiry handling is load-bearing.
A bot may send roughly 30 messages per second overall.
Twenty thousand participants cannot be notified simultaneously that the sale has opened. The opening is announced in a channel, which is genuinely simultaneous, rather than by direct message.
A TON transaction is irreversible once confirmed.
An over-allocation cannot be undone by reversing payments. It becomes a manual refund programme, which is why correctness under concurrency is not negotiable here.
When not to build this
- Your sale is not structured lawfully in the jurisdictions your participants are in. The bot enforces your rules; it has no view on whether you were permitted to make them.
- You have no allowlist and no caps. Then this is a payment address, and a bot adds machinery without adding control.
- You cannot run a rehearsal at realistic concurrency. A launch system that has not been load-tested is untested, because every defect that matters appears only under load.
- You intend to change the rules during the sale. The audit trail then records that you did, and publishing it becomes worse than not having it.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework and the participant-facing sale flow. |
| Cloudflare Durable Objects | current | Single-threaded cap accounting, which is what makes atomic reservation possible. |
| Cloudflare Workers | current | API surface and chain confirmation watchers. |
| Cloudflare D1 | current | Allowlist, reservations, allocations and the audit record. |
| TypeScript | 5.9 | Strict mode, with amounts as integer minor units throughout. |
Questions people ask before committing
What actually breaks during a launch?
Over-allocation, almost always, from reading a cap and writing an allocation as two operations. Under real concurrency both requests see capacity and both allocate. It passes every test that does not run concurrently, which is why rehearsal at realistic load is not optional.
How do you make the queue defensibly fair?
By publishing the ordering rule before the sale opens and the resulting order afterwards. Any rule can be defended if it was stated in advance; none can be if participants learn it by inference after being disappointed.
Why publish a hash of the allowlist?
Because the accusation that the list was edited mid-sale is guaranteed. A commitment published beforehand makes it checkable, and turns an argument you cannot win into a verification anyone can run.
What happens if someone starts a contribution and abandons it?
Their reservation expires and the capacity returns to the queue. Without expiry, abandoned checkouts hold allocation that nobody can use and the sale appears full while capacity sits idle.
Can you handle the announcement to twenty thousand people at once?
Through a channel, yes — a channel post is one message everyone reads. Direct messages are paced at around thirty per second and would take over ten minutes, which is why the opening is announced in a channel rather than individually.
Does this make our sale compliant?
No. It enforces rules you have defined and produces evidence of enforcement. Whether the sale is lawfully structured is a question for your counsel and is entirely upstream of anything the bot does.