Bot type
Moving value in a chat, with the failure modes taken seriously
A Telegram wallet bot lets users hold a balance, send transfers and withdraw, inside a chat. It is the highest-risk build in this catalogue: custody, replay protection and idempotency decide whether it is a product or an incident. Non-custodial designs avoid most of that risk and should be preferred where they fit.
Crypto wallet bots: price, timeline and limits
- Fixed price
- $11,800 USD
- Delivery
- 45 calendar days from kickoff
- Update semantics
- At-least-once, with no ordering guarantee across updates
- TON finality
- Irreversible once confirmed
- Username stability
- Usernames can be released and reused by someone else
- Custody
- Holding user funds is regulated — VARA-licensed in Dubai
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Wallet bots are popular because they collapse a genuinely awkward flow. Sending value to another person normally means addresses, network selection, gas and a confirmation screen written for people who already understand it. In a chat it becomes a message to a username. For tipping, rewards, in-community economies and payouts, that difference is the entire product.
It is also where the largest losses in Telegram-native crypto happen, and the reasons are unglamorous. A transfer endpoint that is not idempotent pays twice when an update is redelivered. A withdrawal that trusts a client-supplied amount pays whatever it is told. A balance updated before the chain confirms is a balance an attacker can spend twice. None of these are exotic; all of them appear repeatedly in post-mortems.
The first architectural question is therefore custody, and it should be answered before anything else. A custodial bot holds keys and is responsible for user funds, which brings key management, operational security and, in most jurisdictions, regulatory exposure. A non-custodial design connects the user's own wallet and never holds anything — a smaller product, a much smaller liability, and the right answer more often than teams expect. Choosing custody because it is more convenient, without pricing the obligations, is the most expensive decision available here.
How the build runs
Custody is decided first and documented
Custodial or non-custodial, and what that means for keys, for insurance and for the regulator in your jurisdiction. Everything downstream depends on this and it is not a detail to settle during implementation.
commandsDeposits are credited only on confirmation
The bot watches the chain and credits after the confirmation depth you set. Crediting on broadcast is the mechanism behind most double-spend losses in bots of this kind.
webhookEvery balance change is a ledger entry, not an update
Double-entry, append-only, with the reason and the reference. A balance you can only observe is a balance you cannot audit, and reconciliation after an incident is impossible without the history.
webhookTransfers are idempotent on a client-supplied key
The same transfer request, delivered twice, moves value once. Telegram updates are at-least-once, so this is a correctness requirement rather than a defensive nicety.
commandsWithdrawals pass limits and, above a threshold, a human
Per-transaction and rolling limits, a cooling period on newly added addresses, and manual approval above an amount you set. The friction is the control; removing it removes the control.
inline-keyboardReconciliation runs continuously and alerts on drift
Ledger total against on-chain holdings, on a schedule. A discrepancy detected within minutes is an investigation; the same discrepancy found at month end is a loss.
webhook
What Telegram will and will not let you do
Telegram delivers updates at least once, with no ordering guarantee across updates.
Any handler that moves value must be idempotent and must not assume sequence. This single property causes more wallet-bot losses than any cryptographic weakness.
A TON transaction is irreversible once confirmed, and there is no arbiter.
A withdrawal sent to a wrong address is gone. Address validation, confirmation screens and cooling periods on new addresses are the only protection, and they belong in the design rather than in a support policy.
Telegram usernames can be changed and released, and reused by someone else.
Sending to `@username` resolves to a numeric user id at the moment of the transfer. Storing a username as a payee identity means a released handle can inherit someone else's incoming payments.
Chain reorganisations can invalidate a transaction that appeared confirmed.
Confirmation depth is set per chain and per amount rather than as one global constant. A depth that is safe for a tip is not safe for a five-figure withdrawal.
Holding user funds is a regulated activity in most jurisdictions, including under VARA in Dubai.
A custodial wallet bot is a licensing question before it is an engineering one. This is scoped with your counsel, and a build that skips it is building a liability.
When not to build this
- You have not taken legal advice on custody in your jurisdiction. Holding user funds without that is the fastest way to turn a product into an enforcement matter.
- A non-custodial design would meet the requirement. If users can connect their own wallet, do that — it removes almost the entire risk surface and most of the cost.
- You cannot fund an operational security practice. Key management for a custodial wallet is an ongoing discipline, not a build task, and an unmaintained one fails eventually.
- The amounts involved are trivial. If the wallet exists to move small tips, an off-chain points system with no withdrawal is a fraction of the cost and the risk.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with all value-moving handlers written idempotently. |
| Cloudflare Workers | current | API surface and chain watchers. |
| Cloudflare D1 | current | Append-only double-entry ledger and reconciliation state. |
| TON Connect | 2.x | Non-custodial wallet connection, where that design is chosen. |
| TypeScript | 5.9 | Strict mode, with amounts as integer minor units rather than floats. |
Questions people ask before committing
Should the wallet be custodial or non-custodial?
Non-custodial wherever it meets the requirement. It removes key management, most of the operational security burden and, in most jurisdictions, the licensing question. Custody should be a deliberate decision with legal advice behind it, not a default chosen for convenience.
What stops a redelivered update paying a user twice?
Idempotency keyed on a client-supplied identifier, checked inside the same transaction that moves value. Telegram guarantees at-least-once delivery, so duplicate updates are expected behaviour rather than an edge case.
Can we credit a deposit as soon as we see it?
No. Crediting on broadcast rather than on confirmation is the standard route to a double-spend loss. Confirmation depth is set per chain and scaled with the amount, because what is safe for a tip is not safe for a large withdrawal.
Is a Telegram username safe to use as a payee identity?
No. Usernames can be released and re-registered by someone else. Transfers resolve to the numeric user id at the moment they are made, and stored payee records key on that id rather than on the handle.
What does regulation look like for this in Dubai?
Holding customer funds is a regulated activity, and VARA has a specific regime for virtual asset service providers. The scoping conversation includes it explicitly, because the licensing answer can change the architecture entirely.
How do you detect that something has gone wrong?
Continuous reconciliation of the ledger against on-chain holdings, with an alert on any drift. The design assumption is that something will eventually go wrong; the requirement is that it is found in minutes rather than at month end.
Why is this the most expensive build in the catalogue?
Because roughly a third of the effort is in failure handling — reorgs, stuck transactions, partial withdrawals, reconciliation — rather than in features. That work is invisible in a demo and is the entire difference between a wallet and an incident.