Build a Telegram Token-Creation Bot Without Holding User Keys

A Telegram token-creation bot does not need to ask users for recovery phrases or store their signing keys. Design it as an orchestration layer: collect a request, show a review, hand the proposed transaction to the user's wallet, and report verified results. That architecture reduces custody responsibilities, but it does not remove transaction or application risk.

The important design work happens before writing bot commands. Decide what Telegram identity proves, what the wallet must approve, what your backend may construct, and which evidence changes a request from submitted to completed. Keep those boundaries explicit in both the implementation and the support runbook.

Separate Chat, Session, and Wallet Authority

Use chat for starting the workflow and delivering status, with a web interface for structured inputs and review. Telegram's Mini Apps documentation describes its web integration and server-side validation of initData. Treat initDataUnsafe as untrusted, validate the signed initialization data, and apply a freshness policy appropriate to your session.

A validated Telegram session identifies a Telegram user; it does not prove control of a Solana wallet. Establish wallet ownership separately when your application needs it, using a domain-bound, single-use challenge with an expiry. A login signature should be clearly distinguishable from approval to create a token.

Never put a seed phrase field in the bot, Mini App, support form, or fallback flow. Store bot credentials and any developer-service credentials server-side. Those credentials are not user signing keys, but exposing them can still let an attacker abuse the integration.

Use a Five-Stage Request Lifecycle

Design a request record with a stable internal identifier and explicit stages:

Draft: validated inputs and selected network, with no signing approval yet.
Reviewed: the user has seen the configuration and current cost information.
Awaiting signature: a specific transaction is presented to the wallet.
Submitted: a signature is recorded, but the result is unresolved.
Completed or failed: chain evidence supports the stated outcome.

Add cancellation and expiry states where useful, but do not make every timeout equivalent to failure. Store the mint address when known and keep each transaction attempt under the same logical request. This is your application design, not an assumption that a provider exposes identical states or idempotency behavior.

Keep Signing With the User

Solana's transaction documentation describes instructions and signatures as parts of a transaction. Have the wallet authorize the actual intended message, not an opaque instruction to trust whatever the server does later. Review the network, payer, recipients, supply, decimals, authorities, and payments before asking for approval.

Bind the reviewed configuration to the request revision. If the user changes the recipient or supply, invalidate the previous review and prepare a new approval. If the backend receives signed bytes, check that they match the expected message before submitting them. Do not accept an arbitrary transaction merely because it arrived from an authenticated session.

A mint-account creation strategy may require additional signing material. Decide explicitly how that role is handled and distinguish it from the user's wallet and any ongoing mint authority. Do not market the whole design as having no keys anywhere just because user wallet keys stay outside your backend.

Worked Example: Recover From a Closed Mini App

Suppose a user drafts 75000 tokens with six decimals, receiving them into their connected wallet. The raw supply is 75000000000. Your review shows those values, the network, authority choices, and the current payment breakdown.

The wallet signs, your backend records signature T, and the user closes Telegram before a result appears. On reopening, load the existing request rather than starting creation again. Display submitted while checking T. Solana's signature-status reference supports status checks, including historical search where needed.

After the required confirmation, inspect the mint and intended balance before publishing the completion receipt. If the state is unresolved, preserve that uncertainty and continue reconciliation. The bot should not send congratulations because an HTTP submission returned successfully, nor encourage a fresh creation because the browser session ended.

Handle Expiry and Repeated Actions Deliberately

For recent-blockhash transactions, preserve the validity context returned by getLatestBlockhash. If a transaction needs rebuilding, first investigate its prior signature and state, then request a new review and signature for the changed message.

Deduplicate repeated Telegram updates and button actions in your own backend. A unique request identifier can prevent duplicate application jobs, but it is not automatically an on-chain guarantee. Test two simultaneous confirmation clicks and a delayed webhook arriving after a request has completed. Neither should silently prepare another launch.

Also test wallet rejection, a stale session, a changed connected wallet, wrong-network configuration, RPC interruption, and an unexpected payment instruction. Make the expected next action explicit for each case. A real wallet-browser fallback is useful when an embedded webview cannot complete the tested signing path; never replace it with server-side custody as a convenience shortcut.

Choose the Integration Route Honestly

The TokenAnvil API reference, checked October 23, 2026, documents POST /v1/tokens returning an unsigned base64 transaction, a mint address, the required signer, and blockhash validity information. The construction call does not submit to Solana: your integration must arrange wallet signing and submission. Keep the API credential on your server and verify the returned transaction against the reviewed request. This article is an integration architecture, not a ready-made hosted Telegram bot.

If those capabilities are unavailable, keep the bot as a guided handoff to the TokenAnvil no-code app. The user then completes the manual flow there. Do not describe that link-based handoff as API automation. Either route should finish with a clearly labeled mint, network, signatures, and verified outcome, without collecting the user's private signing material.