Telegram bot for P2P exchange: where the deal breaks
In a Telegram bot for P2P exchange, a deal rests on three or four points where it most often breaks, and almost always they are interconnected.
The first is manual confirmation of receipt: the operator checks the transfer against the statement and presses a button, and while he is asleep, in another chat, or simply lost in thought, the seller's coins remain on hold.
As long as this step is manual, deal time is measured not in minutes but by a person's presence online.
The second is a dispute without evidence. Chat correspondence, screenshots in the administrator's DMs, payment details given by voice give the arbitrator nothing but one side's word against the other's.
The result is a decision "by reputation," manual review of every claim, and an equally unpleasant aftertaste for both buyer and seller.
The third is a stalled deal when the operator goes offline. Inside, the status has already changed to "paid," but outside the bot there is no transfer; the discrepancy accumulates silently until support starts looking for it based on a complaint.
Peak load on requests only accelerates this: the queue grows faster than operators can close it, and deals that no one remembers appear in the database.
Below, we break down how these bottlenecks are closed by code rather than by instructions for operators.
What changes after launch: deal speed and dispute resolution
When a deal goes through Telegram, the bottleneck is not the wallet but the person behind the screen.
The operator manually checked the transfer, confirmed receipt, and opened a dispute for every discrepancy: a single deal took dozens of minutes, and at peak requests the queue grew faster than it was processed.
After automation, p2p deal time is reduced to 3-6 minutes — from confirmation of terms to transfer of coins to the second party.
Automatic dispute resolution relies on evidence, not correspondence.
The bot records the moment terms are confirmed, the time the transfer appears on the network, the transaction hash, and attached screenshots, checks them against described rules, and closes the dispute itself if the picture is unambiguous.
A discrepancy in amount, someone else's payment details, or repeated payment goes to the operator with a ready-made summary — the share of disputes handled without their involvement remains at 70-80%.
Resilience to peak load is separate work, not "the bot will withstand it." Events are processed idempotently: a repeated notification does not create a second deal, and a surge in requests is absorbed by a queue with rate limiting.
If the payment node's response is delayed, the task returns to work rather than hanging without a status.
The reduced load on operators is visible in the share of manual operations — it drops severalfold, because the person handles only exceptional scenarios rather than confirming every deal.
At the same time, an entire class of failures disappears: lost payment, double confirmation, deal without closure.
Deal execution models: auto-hold, guarantor, hybrid
Choosing a deal model is not about interface convenience but about who holds the funds when the parties diverge and how the dispute is resolved.
Auto-hold of funds covers the flow of standard deals, a manual guarantor covers large amounts and non-standard conditions, and a hybrid exchange model switches mode based on the deal limit.
This also determines the bot's design: where the deposit is held, who signs the payout, and which events are logged.
| Model | When it fits | Limitations |
|---|---|---|
| Auto-hold of funds | Standard pairs, amounts within the limit, parties with history | Requires automatic receipt verification and reputation-based confirmation; disputes take longer |
| Manual deal guarantor | Large amounts, new counterparties, non-standard conditions | An operator appears in the chain: deal time depends on their availability, and a policy and separation of rights are needed |
| Hybrid exchange model | A flow of deals of different sizes in one bot | Two sets of rules; switching between modes must be idempotent |
Deal limits are set not by a single number but by a set of thresholds: by amount, by pair, by account age, and by number of completed deals. The threshold rises automatically — as reputation grows, the manual guarantor is enabled less and less often.
It is critical that when the model changes, the deal status does not diverge between the parties and the operator: otherwise a dispute is opened for an already closed deal.
We usually assemble auto-hold and hybrid in one circuit — the flow does not hit the operator, while large amounts remain under control.
Step-by-step implementation: from flow audit to handover
The work proceeds in iterations, and the order here is not accidental: each stage relies on the artifacts of the previous one.
First, we capture how deals currently proceed, then transfer that logic into the bot — this way controversial points surface before launch, not on a live flow.
- Deal audit — we analyze the current process: who initiates the exchange, where payment is confirmed, and at what point the deal is considered closed. The output is a state map and a list of bottlenecks.
- Exchange model design — we describe the deal's finite state machine: transitions, timeouts, cancellation and arbitration rules, and behavior for duplicate payment.
- Bot setup in Telegram — participant and operator roles, amount and frequency limits, operation log, idempotent handling of repeats.
- Test circuit — a sandbox with test networks: running standard deals, load testing and testing with slow responses from external services.
- Failure scenario checks — connection loss, stalled deal, amount discrepancy, counterparty refusal: we record how the system exits each case and what the operator sees.
- Handover to support — access, dispute review policy, on-call duty, and metrics that show the flow is healthy.
We train operators on the test circuit: they conduct training deals themselves and analyze incidents. After handover, we stay in touch for the first weeks — we make adjustments based on actual requests without rebuilding the logic.
Handover: deal model, policies, access, and documentation
After delivery, the client's team retains not only a working bot but also a set of documents by which the process is run further without us.
P2P exchange relies on manual decisions, so when an operator changes or an incident is reviewed, what matters is not the contractor's memory but a recorded procedure.
- Deal flow diagram — from order placement and collateral lockup to transfer confirmation and unlocking, with timeout, auto-cancellation, and manual review handoff points.
- Access policies — role matrix (operator, senior operator, administrator), mandatory two-factor login, and an immutable action log.
- Operator manual — step-by-step scenarios for standard situations: request without incoming funds, amount mismatch, complaint about a counterparty, disputed transfer.
- Dispute review policy — response times, list of accepted evidence, criteria for deciding in favor of a party, and procedure for notifying both parties.
- Monitoring setup — alerts for processing delays, series of cancellations, spike in disputes, payment provider unavailability, and balance discrepancies.
- Integration documentation — list of external services, procedure for rotating access keys, and replacing a provider without stopping the exchange.
- Recovery procedure — policy for rollback to the previous version, backup scheme, and target time for returning the service to operation.
At acceptance, we go through each item together with your team: we consider a document accepted when a person who did not participate in development can work from it.
Case study: an exchange with manual moderation was moved to automation
The client came with a working P2P exchange in Telegram: requests were collected in a shared chat, and each deal was manually handled by an operator — checking payment details, waiting for transfer confirmation on the network, and manually unfreezing funds.
With a flow of 300-400 requests per day, a shift of four operators could not keep up, and peak hours turned into a queue.
What the metrics showed before
Average deal time remained at 40-50 minutes: half was spent waiting for the operator to become free.
The share of manual confirmations was almost 100%, and stalled deals consistently accounted for 8-12% of daily volume: payment arrived but the operator did not manage to mark it, or vice versa — funds were frozen and the client left. Each such deal was reviewed manually using logs and correspondence.
What we changed
The deal was moved into a finite state machine: states "awaiting deposit," "network confirmation," "lockup," "payout" — with hard timeouts and auto-unfreezing when they expire.
The bot reconciles incoming transfers by address, amount, and number of network confirmations, and escalates only discrepancies and disputed cases to the operator. The entire deal state is written to the log, so review proceeds step by step rather than through correspondence.
What the result was
Deal time dropped to 6-9 minutes, and manual confirmations remained at 12-15% — these are non-standard amounts and disputed statuses. The class of stalled deals disappeared: each is either brought to completion automatically or closed by timeout with a refund.
The shift was reduced to one or two operators, and during peak the queue no longer grows. A separate effect is predictable support: "where is my money" requests decreased because the status is visible to the client in the chat at every step.
How does auto-hold of funds differ from a human guarantor?
The difference is who holds the key to the locked amount. A human guarantor keeps the assets in their own wallet, and both parties trust them as the sole custodian.
With auto-hold, the amount is locked by conditional escrow: the contract accepts only a predefined set of signatures and does not release funds to anyone except the address provided by the logic.
Automation wins in mass scenarios — exchanging a digital asset for a transfer through a payment system. Confirmation from both parties and a timer close the deal without an operator: from marking receipt of funds to unlocking, seconds pass.
The contract has no offline mode, time zone shifts, or temptation to hold the balance — the failure class of "the intermediary disappeared with the money" is absent here.
A human is needed where the contract is blind: a forged receipt, a revoked transfer, payment from a third party's account. Escrow logic distinguishes "confirmed / not confirmed" but does not distinguish a genuine statement from a fake one.
Therefore, in schemes with a third signature, the arbitrator gains access to banking history and correspondence — the operator's role narrows to dispute resolver rather than custodian of funds.
The speed of dispute closure is set by the lockup window, not the guarantor's mood. If the arbitrator does not sign on time, the contract returns the funds along the original route itself.
Counterparty trust is built on a transparent and immutable unlocking condition, the same for both parties — not on the intermediary's reputation. The working choice is a hybrid: auto-hold for standard deals, an arbitrator for edge cases.
An engineer's doubts: limits, keys, stalled deals
Doubts at the start rarely concern functionality — usually they are about boundaries: where automation stops, who has signing authority, and what happens when one of the parties stops responding.
Below are four questions asked before work begins, and our answers in terms of what exactly is configured in the system.
How is deal volume limited?
Limits are set at several levels: minimum and maximum per deal, cumulative volume per day, and the number of simultaneously open deals for a user. For new counterparties, thresholds are lower; for verified ones, higher.
Exceeding them does not lead to rejection: the deal is either split or sent for manual confirmation to the on-duty operator.
Where are wallet keys stored and how are access rights separated?
The hot wallet holds only the working balance within the limit; the main volume is in cold storage. Payout signing is performed by a multi-share scheme, some of which are held on a hardware module, so compromising one node does not allow funds to be withdrawn.
Roles are separated: the operator handles deals, the risk role expands limits, and the administrator cannot single-handedly sign a payout. Every action is logged with role and time.
What happens when payment is stalled?
The deal does not remain in uncertainty: every step has a timeout, and states are described explicitly and as a finite set. A background task carries network confirmation through to the end; repeated checks are idempotent — a duplicate notification will not debit funds twice.
If the window expires, the escrow is returned automatically or the deal goes to arbitration, and both parties receive a message with the status and a link to the details.
How is the counterparty checked before a deal?
Access to volumes above the threshold opens after verification. The address is checked against risk lists, and deal history, share of successfully closed deals, and behavioral signals are taken into account — for example, a large volume on a fresh account. Such signals do not block permanently but raise the level of verification up to manual review.
Describe your scenario — we will return with an estimate and a plan where these limitations are already broken down by configuration and roles.
Let's discuss the task and return with a work plan
To return with an estimate and work plan rather than general timelines, we need project inputs.
The more specific the inputs, the faster we will assemble the solution design and give a realistic launch timeline for the exchange — without rework at the junction with the payment provider and liquidity provider.
- Exchange scenarios: which asset pairs and fiat directions we serve, limits per deal and per user per day.
- Role of the parties in the deal: who holds funds until confirmation — the bot, a smart contract, or a guarantor operator; how the dispute is resolved.
- Fiat acceptance: which payment methods, whether automatic receipt reconciliation is needed or manual confirmation by an operator.
- User checks: whether verification is required, amount thresholds, and rules for blocking suspicious scenarios.
- Rate and liquidity: where we take the price from, whether there is a reserve, and how we calculate the exchange's spread and commission.
- Notifications and reconciliation: which events go to the user and operator, and what we export for daily balance reconciliation.
- Load and roles: how many deals per day we expect, how many operators work simultaneously, and whether an admin panel with access separation is needed.
- Existing systems: what already works — wallet, cash desk, accounting system — and what must integrate with the bot.
Describe the task in this scope — we will return with a solution design, stage-by-stage estimate, and work plan: from deal prototype to exchange launch.