How a Confirmation-First Telegram Trading Workflow Reduces Execution Risk
Turning fast-moving community signals into validated, auditable order flows.
- Published
In a fast-moving Telegram trading community, the shortest path from a signal to an exchange order can look like the best product experience. Fewer taps mean less delay. But an irreversible action involving live futures orders is not an ordinary conversion funnel: speed has to be balanced against ambiguity, stale information, inconsistent sizing, duplicate input, and simple human error.
I built Kaiyn Trading Bot around a different question: how can the workflow remain quick while making every consequential transition explicit? The result is a confirmation-first system that treats a trading signal as the beginning of a stateful product flow, not as a command to place an order immediately.
The operating problem
Kaiyn Capital distributes market commentary, signals, chart updates, and risk discussion through Telegram. That environment is useful precisely because information moves quickly, but the same speed creates operational friction. A user still needs to interpret the signal, decide how to enter, calculate a position, confirm the stop-loss direction, and check that the order is valid for the exchange contract.
Leaving every step manual creates inconsistent execution. Automating everything behind one button creates a different problem: the system can act before the user has seen the assumptions it made. The product therefore needed a middle ground—structured automation with deliberate confirmation boundaries.
The confirmation-first workflow
Confirmation happens twice, for two different actors. The signal sender first approves what will be distributed. The end user later approves the calculated order that may reach the exchange.
- 01
Create and preview the signal
An authorized sender creates a signal in a private Telegram conversation. The bot assigns a permanent signal ID, prepares the message and chart, and asks the sender to confirm before anything reaches the community.
- 02
Let the user choose an order mode
After the confirmed signal is forwarded, users can select a market order or a GTC limit order. This choice starts a private order workflow instead of executing immediately from the public channel.
- 03
Calculate and validate
The bot checks API configuration, fetches current market and contract information, calculates position size from the user’s fixed 1R amount, and validates local risk caps and exchange rules.
- 04
Persist a pending order
A validated order becomes a PostgreSQL-backed pending order. Telegram callbacks carry only short tokens; the full order state remains in the database and can survive a bot restart within its time-to-live.
- 05
Show the final confirmation
The user sees the order mode, calculated size, price assumptions, and risk information before explicitly confirming or cancelling the order.
- 06
Claim, revalidate, and submit
On confirmation, the bot claims the pending order with a row lock, repeats the relevant validation with fresh market data, submits the order to Bitget, and persists the result and audit event.
Confirmation is a product boundary, not a modal
A confirmation screen is only useful when it changes what the user can understand. Asking “Are you sure?” after hiding the calculation adds friction without adding control. In this workflow, the preview is where the system exposes the order mode and its derived values before the action becomes irreversible.
The server also persists previews and pending orders instead of storing the entire state inside Telegram callback data. This makes confirmation a real lifecycle with pending, processing, executed, failed, cancelled, and expired states. It also means that an active preview can survive a bot restart while its session remains valid.
Put risk checks on both sides of confirmation
The order preview uses a fixed 1R amount and the distance between the calculation price and stop loss to derive the position’s notional value and quantity. Financial values on the order path use Decimal arithmetic and PostgreSQL Numeric fields rather than binary floating point.
Before showing the preview, the bot checks the contract status, minimum order size, minimum notional value, quantity and price precision, per-order limits, and the direction of the stop loss. It also applies local maximum-position and daily-trade limits, choosing the stricter value when a user-level override exists.
Those checks run again after confirmation with current market and contract data. The second pass matters because confirmation introduces time: a preview can be valid when rendered and invalid when the user finally acts.
Design for uncertainty without resubmitting
Repeated Telegram clicks are handled by claiming a pending order under a database row lock and moving it into a processing state. The exchange request also receives a deterministic client order ID derived from the pending order token. Together, these controls are designed to reduce duplicate submissions; they are not presented as a guarantee that a distributed system can never fail.
A harder case appears when the exchange request may have succeeded but the local process did not receive a conclusive response. The health monitor reconciles stale processing orders by looking up that client order ID through Bitget’s order detail and history endpoints. It updates local state when it finds the order, but it does not automatically submit another one. In a live trading workflow, an uncertain missing response is safer to investigate than to interpret as permission to retry.
Operations are part of the product surface
The visible experience ends with an execution summary, but a workflow used over time also depends on audit events, administrator alerts, health checks, retention cleanup, database backups, and a documented restore path. These features do not make the primary interaction more attractive. They make the product inspectable when something goes wrong.
The same principle shaped the deployment pipeline. CI exercises the Docker Compose path with migration checks, type checks, tests, and PostgreSQL integration coverage. Releases are published as container images and deployed only after production environment approval. The operating model is therefore documented alongside the user flow rather than treated as an invisible implementation detail.
The product principle
Confirmation-first does not mean maximizing the number of warnings or clicks. It means choosing the transitions where a person needs new information or where the system needs to re-establish validity. In this project, those transitions sit between drafting and publishing a signal, between selecting an order mode and creating a pending order, and between confirming and submitting to the exchange.
The broader lesson applies beyond trading infrastructure: when software turns informal intent into a consequential external action, the product should make assumptions visible, persist an inspectable state, and treat uncertainty as a first-class outcome rather than hiding it behind an automatic retry.