Source-backed facts
The verified source for this article is the GitHub repository: https://github.com/sueun-dev/exchange-listing-sniper
The repository describes exchange-listing-sniper as a low-latency Telegram → Bybit listing sniper. It is designed to detect new KRW spot listing signals from Upbit and Bithumb, then market-buy the same coin on Bybit within milliseconds. The repository description also mentions a C++/Rust hot path, MTProto ingest and money-safety guards.
Why Telegram → Bybit
For this kind of market-flow automation, Telegram is the event intake layer. Listing announcements and monitor feeds can reach Telegram quickly, so the system can treat each message as a candidate event instead of waiting for a slower manual workflow.
Bybit is the execution layer in this project. That separation matters: the source event is a Korean exchange KRW listing, while the order route is a different venue. The hard engineering work is not just speed. It is verifying that the parsed ticker maps to a tradable Bybit symbol and that guardrails allow the order.
A practical pipeline view
A developer can read the architecture as a sequence of small decisions:
- ingest Telegram messages with very low latency
- classify whether the message is related to Upbit or Bithumb
- detect whether it is specifically a KRW spot listing signal
- extract and normalize the ticker
- deduplicate repeated or mirrored messages
- map the ticker to the Bybit instrument
- apply money-safety checks and order limits
- submit the market order and record the result
The middle of the pipeline is where most failures hide. A fast parser that confuses a maintenance notice, an event notice or a non-KRW market for a new KRW spot listing would be dangerous.
Why low latency matters
New listing windows are crowded public events. Market makers, bots and manual traders can all react at once, and the order book may change faster than a human can verify the announcement and click through an exchange UI.
Low latency can reduce delay, but it does not remove market risk. A market order can face slippage, partial liquidity, symbol mismatch, API rate limits or exchange-side rejections. Speed is useful only when the signal is correct and the allowed order size is controlled.
What I would inspect before using code like this
I would review API permissions, allowed order size, symbol allowlists, idempotency, duplicate-message handling, logging, failure paths and exchange terms. I would also keep the system observable, because an automated order path should be easy to stop and audit.
This is a technical project note, not financial advice. It is not a buy or sell recommendation for any asset.
Top comments (0)