Trading core services
TON trading via Telegram — confirm ~60s → ~10s. Market-data ~40 req/s typical, peak ~100 overnight. Built from scratch.
- Node.js
- TypeScript
- MongoDB
- Redis
- Telegram
- Web3 / blockchain
- API design
Intro
TON traders mostly used dapps (ston.fi, DeDust) — high latency meant slow fills and real asset loss. Volume was high and the audience already lived in Telegram, so we built a Telegram-native trading path on self-hosted nodes with custodial wallets for speed, not a web non-custodial clone of ston.fi.
Architecture
- 01Telegramuser channel · commands
- 02Core serviceorders · contract calls · custodial wallet · snipe queues
- 03Market-data scraperRPC → TG display · ~40 req/s · peak ~100
- 04Tx validatorfast confirm → user
- 05LiteServer / Full Nodeself-hosted · accuracy of chain data
- 06MongoDBcustodial wallet state · durable writes
What I did
- Owned core — receive Telegram commands, contract calls, custodial wallet in DB, and pending/snipe order queues (snipe timing was contested per block; I do not claim sole ownership of snipe product strategy)
- Owned market-data scraper — RPC → Telegram display at ~40 req/s typical, peak ~100 for 1–2h overnight
- Owned in-core tx validator so confirms reached users faster — on-chain confirm path ~60s → ~10s
- Worked with a product team of 3 backend + 1 DevOps dedicated to LiteServer; today in this role I lead 4 backend and formally mentor 1 — ops bar 99.9% SLA · ~1 serious incident/year
Hard problems
False success on multi-layer TON contract paths
- Symptom
- UI/bot could report success while the contract stack was still stuck on an intermediate validation step — user believed the trade landed.
- Cause
- TON execution validates across multiple contract layers; failure at any layer leaves the intent incomplete without a single clear “done” signal if you only watch the first hop.
- Fix
- Validator in core waited on the full confirm path before telling the user; treated partial hops as in-flight, not success. Confirm latency band above is the public outcome — no finer failure-rate claim.
Snipe timing vs contested blocks
- Symptom
- Early submit failed; late submit filled at a worse price — every block mattered.
- Cause
- Pending/snipe queues race the chain; there is no safe “always early enough” without risking reject, and no safe “always late” without adverse fill.
- Fix
- Queued intents with explicit timing windows and validator feedback into Telegram; accepted that snipe is a contested product surface, not a guaranteed edge. No public win-rate published.
Problem
TON volume sat in dapps with painful latency. Traders needed something fast and reachable; blockchain users already operated inside Telegram. Self-hosting LiteServer / Full Node plus a custodial wallet path let us call contracts faster than routing users through a slow dapp UX.
Trade-offs
- Custodial wallets — signing inside Telegram without holding keys is impractical; we did not ship a web non-custodial competitor to ston.fi because the product bet was Telegram speed, not feature parity with DEX UIs.
- Self-hosted nodes — primary reason was accuracy of chain information we showed and acted on, not just raw throughput.
- ston.fi API — used only to query / display pool listings. We never executed contracts through their API (financial risk).
Outcomes
Confirm path ~60s → ~10s. Market-data scraper held ~40 req/s typical and ~100 at overnight peak (1–2h). Public bands above; client names and finer trading latency stay internal.