Case study: how an OTC desk runs 80 Telegram accounts
Case study: how an OTC desk runs 80 Telegram accounts
OTC crypto desks live and die on relationships. The product is trust, and trust is built in chat. Most of the desks I’ve talked to in Singapore and Hong Kong run their entire deal flow through Telegram, which means the accounts themselves are a business-critical asset. lose an account and you lose the client history, the group access, the signal lists, sometimes the deal in progress.
this case study is based on a small OTC desk i consulted for in late 2025. three operators, combined book of roughly $2-8M per month depending on market conditions, working across Southeast Asia, the Middle East, and Europe. they needed 80 accounts, not because of any grey-area activity, but because they were running separate personas per market, per product line, and per operator, plus keeping backups for every primary. they also had a handful of accounts used purely for inbound leads, never for actual trading conversations, to reduce the blast radius if an account got flagged.
the headline result: after a month of setup and two months of operation, their account loss rate dropped from around 30% per month (phones, manual SIM juggling) to under 8% per month, and the setup cost per new account fell from roughly $18 to under $4.
the setup
the core stack was four tools:
AdsPower for browser fingerprint isolation. they were on the team plan at $30/month for the base tier, scaling to around $50/month once they added enough profiles. each Telegram Web account lives in its own browser profile with a unique canvas fingerprint, WebGL hash, and user-agent. AdsPower lets you clone profiles and set proxy per-profile, which matters when you‘re managing this many accounts. if you want a comparison of antidetect browsers at different price points, antidetectreview.org covers a solid range and their AdsPower review is one of the more honest ones i’ve seen.
residential proxies through Smartproxy, paying around $7.50 per GB on their pay-as-you-go plan. the desk used approximately 18-22 GB per month to keep 80 accounts active, mostly because Telegram Web is lightweight. total proxy spend: roughly $140-165/month. they assigned one proxy location per account and did not rotate within an account session, which is the right call. Telegram tracks IP consistency over time, and random rotations are a common reason accounts get checkpoint-challenged.
SMS-Activate for virtual numbers. at the time, a Telegram verification on a US number was around $0.15-0.25 depending on availability, Russian and Indian numbers cheaper at $0.05-0.10. for 80 accounts, initial verification cost was approximately $10-16. re-verification after a ban costs the same, so keeping the ban rate low matters financially as well as operationally.
a self-hosted n8n instance on a $6/month Hetzner VPS to handle session keepalive pings and account health monitoring. nothing exotic, just a workflow that loaded each profile in sequence once every 18-24 hours through a headless Chrome instance via Playwright, sent a message to a dummy contact, and logged the response. if an account failed the keepalive three times in a row, it triggered a Slack alert.
total monthly infra cost at steady state: $315-380/month for 80 accounts, or roughly $4-5 per account per month.
scale numbers at the end of month three: - 80 accounts provisioned - 71 active (88.75% survival) - 6 soft-banned (accessible but not receivable) - 3 hard-banned - average account age: 74 days
what worked
static ip-per-account, no exceptions. the single highest-impact change from their old setup was assigning one proxy exit node to one account and never changing it. Telegram’s trust scoring is not public, but based on what i’ve seen across multiple projects and what the Telegram API documentation implies about session integrity, IP changes during an active session correlate strongly with suspicion flags. they used Smartproxy’s sticky session feature to pin to the same datacenter exit for each account. account bans dropped almost immediately after this change.
warming new accounts for 10 days before use. fresh accounts that got pushed straight into group activity were the first to get banned. the desk built a simple onboarding queue: new account gets created, sits in rotation for 10 days doing only passive activity (viewing public channels, reading messages), then gets moved to active status. this is tedious but it works. for context, the accounts that skipped warming had a 3-month ban rate of about 35%. accounts that completed warming had a ban rate of about 9%.
separating inbound and outbound account roles. 20 of the 80 accounts were inbound-only: they were posted in group bios, pinned in channel descriptions, used to receive first contact. they never initiated conversation, never joined new groups, never sent files. keeping these accounts low-activity meant they survived longer and gave the desk a stable surface for new client contact. you can read more about role-based account structures in the multiaccountops.com guide to account segmentation.
profile-level 2FA on everything. they set unique passwords on every account and stored them in Bitwarden. accounts without 2FA that got hit with a phone number challenge were unrecoverable when the SIM had been recycled by the provider. accounts with 2FA had a recovery path. this sounds obvious but it’s skipped constantly in practice.
a spreadsheet over automation for the first month. before the n8n setup was running, they tracked account health in a shared Google Sheet. account name, proxy assigned, last active, ban status. low-tech but it forced discipline before they automated. the automation came later and built on a pattern they already understood. if you want to see how others structure multi-account spreadsheets before automating, the multiaccountops.com ops template library has a few starting points.
what broke
SMS number recycling. SMS-Activate numbers are temporary. the desk found out mid-setup that three accounts they’d verified had their underlying numbers reassigned to other users who then triggered Telegram to re-verify ownership. when the original accounts were challenged, the new owners of the numbers received the SMS codes. accounts gone, no recovery. the fix: after verification, they moved every account to email-based 2FA immediately, and added a note in the spreadsheet for which number was used so they could flag if it reappeared. this is a real operational risk that’s easy to underestimate.
AdsPower profile sync conflicts. when two operators were logged into AdsPower simultaneously and one opened a profile that the other had running, the session cookies overwrote each other. this soft-corrupted four accounts over the first month. the fix was dumb but effective: a shared Notion doc with a “currently in use” column that operators updated manually before opening any profile. they evaluated AdsPower’s multi-user lock feature but found the free-tier version of the control didn’t block concurrent opens fast enough. the paid team tier helped but wasn’t perfect. still, a manual lock convention cost nothing and worked reliably.
Hetzner’s outbound SMTP block killing n8n alerts. the Slack integration in n8n for their health alerts relied on a webhook, not SMTP, so this wasn’t actually a problem for alerts. but when they tried to add email-based reporting, Hetzner’s default policy of blocking port 25 on new VPS instances caught them. not a catastrophic failure, just a half-day debugging session. they switched to Postmark for transactional email and it cost $1.50/month at their volume. documenting this because it’s a common Hetzner gotcha.
the numbers
at month three, here is what the operation looked like financially:
| line item | monthly cost |
|---|---|
| AdsPower team plan | $50 |
| Smartproxy residential | $155 |
| SMS-Activate (new + re-verifications) | $22 |
| Hetzner VPS | $6 |
| Postmark | $2 |
| Bitwarden Teams | $5 |
| total | $240 |
that’s $240/month for 71 active accounts, or $3.38 per active account per month.
their previous method: three operators each managing 25-30 accounts manually, using personal SIMs and their own devices. total cost was lower in cash (maybe $50/month in SIM cards), but the time cost was enormous and the account loss rate meant they were re-onboarding clients constantly.
they didn’t share revenue numbers with me, but i can say the operational logic made sense: an OTC desk that loses a client relationship because an account got banned is losing potential future transaction volume, not just a $4 asset. the cost to maintain account stability was not the interesting number. the relevant question was what it cost to lose account stability, and the answer was “occasionally, entire client relationships.”
for CAC context: client acquisition in OTC is relationship-driven and happens over months. if a Telegram account death resets a relationship mid-cultivation, that’s a real cost even if it’s hard to put a number on. the desk treated the $240/month as insurance, not infrastructure.
lessons
ip consistency is the highest-leverage variable. more than profile uniqueness, more than warming time, sticky IP per account was the change that most visibly reduced ban rates. treat it as non-negotiable.
backups are not optional at this scale. for every primary account, there should be a backup at 50% warmup state, ready to take over. at 80 accounts you will have failures; the question is whether the failure is recoverable or catastrophic. the desk had a 1:1 primary-to-backup ratio for their most important client-facing accounts and a 4:1 ratio for their less critical ones.
automate the monitoring before you automate the management. know which accounts are alive before you start scripting actions against them. the n8n keepalive monitor was worth more than any automation they ran.
compliance context matters for how you structure the accounts. this is not legal advice, but if you’re operating an OTC desk in a jurisdiction with AML/KYC requirements, how you document client interactions on Telegram may be relevant to your obligations. the FinCEN guidance on virtual currency businesses from 2013 is old but still the foundational US document on this. operators in Singapore should check MAS guidelines directly. this is not legal or tax advice.
low-tech discipline scales better than early automation. the spreadsheet-based phase taught the operators exactly what the automated phase needed to track. jumping straight to automation without that period would have produced an automated system that monitored the wrong things.
account roles reduce blast radius. inbound accounts, outbound accounts, group-monitoring accounts, and deal-execution accounts should not overlap. when one category gets targeted, the others survive. see the multiaccountops.com blog for more on role separation in multi-account operations.
would i do it again
yes, with one change: i would spend the first two weeks building the monitoring layer before provisioning any accounts at scale. the desk came in wanting 80 accounts on day one, and i pushed back on that but not hard enough. we provisioned 40 on day one and the ones that didn’t get logged into the health monitor for the first week had a higher early-ban rate. the monitoring is not just a nice-to-have, it’s how you learn which accounts need attention before they die.
the cost structure works. $240-380/month for 80 accounts is cheap compared to the alternative, which is operator time and recurring client relationship damage. the antidetect-plus-residential-proxy stack is mature enough that the failure modes are known and manageable. SMS verification is the weakest link and the one i would spend the most time hardening, either through number-porting to persistent virtual lines or through account transfer to email auth as fast as possible after creation.
if you’re running a smaller operation, say 15-20 accounts, most of this stack is overkill. a single Dolphin Anty subscription and a datacenter proxy per account gets you most of the way there at a fraction of the cost. the full stack described here starts making sense above 40 accounts where manual tracking breaks down and you need automated health monitoring to keep up. for more on proxy selection at different account counts, proxyscraping.org has useful breakdowns of residential versus datacenter tradeoffs that are worth reading before you commit to a provider.
the OTC context added one dimension that pure growth-hacking operations don’t have: compliance pressure. the desk was legitimately trying to manage client relationships across jurisdictions, not evade detection. that meant every choice in the stack needed to be defensible, not just functional. that’s a different optimization target than pure survival rate, and it shaped some of the decisions above.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.