Bithumb Listing & Risk-Lifecycle Alerts

Detect the Bithumb events a trading bot can act on: new spot listings, caution releases (designation lifted), and final delistings. Real-time WebSocket dispatch, parsed in microseconds, with a deterministic event ID per stage.

Why monitor Bithumb announcements?

Bithumb is one of South Korea's largest cryptocurrency exchanges, ranking among the top exchanges globally by volume. Like other Korean exchanges, Bithumb listing notices can trigger significant price movements on international markets due to the isolated nature of Korean crypto trading.

Beyond listings, Bithumb publishes a structured sequence of risk notices through which a token can travel before delisting — a pre-warning, an official caution designation, extensions, and either a release or a final delisting. We capture every stage. Combined with Upbit listing notice alerts, monitoring Bithumb gives you comprehensive coverage of the Korean exchange market.

What Bithumb notices we monitor

We monitor Bithumb's official announcement and notice channels continuously. We forward new spot listings, caution releases (the 유의 종목 지정 해제 event that lifts a previous caution flag), and spot delistings. The intermediate stages of the risk lifecycle (pre-warning, formal designation, extension, deposit halts) are detected internally but kept off the broadcast — they generate noise without a clear actionable trade. Maintenance windows, routine network upgrades, and event marketing are filtered out.

Bithumb risk-lifecycle events on the wire

Two event types reach the bus: caution_released (rehabilitation 지정 해제 — warning lifted, often a technical bounce) and spot_delisting (final removal 거래지원 종료). Both are emitted from the same Seoul-based detection engine as listings, parsed locally in microseconds and forwarded over a warm TCP link to Tokyo for WebSocket broadcast.

How the Bithumb lifecycle plays out

A typical risk track for a Bithumb token, on Bithumb's side: 유의촉구 (pre-warning) → 거래유의종목 지정 (designation) → 지정 연장 (extension) → either 지정 해제 (release — we broadcast this as caution_released) or 거래지원 종료 (delisting — we broadcast this as spot_delisting). The cycle can take a few weeks. A single Bithumb announcement sometimes covers several tickers across stages — for example one ticker released and another delisted in the same notice — and we split those into separate WebSocket events with distinct listingType values so your bot can route them independently. See our blog post for the full walkthrough with real examples.

Connecting to Bithumb alerts

Filter for Bithumb announcements using the ?cex=bithumb parameter, then route on the listingType field:

# Bithumb — every event type
import json, websocket

def on_message(ws, msg):
    data = json.loads(msg)
    if data["type"] == "announcement":
        print(f"BITHUMB: {data['ticker']} — {data['title']}")

websocket.WebSocketApp(
    "wss://cryptolisting.ws?cex=bithumb",
    header=["X-API-Key: YOUR_KEY"],
    on_message=on_message,
).run_forever()

Korean exchange announcement strategy

Monitoring both Bithumb and Upbit together gives you full coverage of the Korean market. Sometimes a token listing notice appears on Bithumb first, sometimes on Upbit. The exchange that announces first typically causes the bigger pump:

# Monitor all Korean exchanges
"wss://cryptolisting.ws?cex=bithumb,upbit"

Speed advantage for Bithumb notices

Our detection engine runs 24/7, making us faster than Telegram bots and email alerts — but also faster than other WebSocket-based listing notice providers. Our purpose-built infrastructure is optimized at every layer — just raw speed from Bithumb announcement detection to your client. Bithumb events are currently dispatched from our Tokyo endpoint wss://cryptolisting.ws; we operate a separate Upbit-specialized mirror in AWS Seoul (wss://kr.cryptolisting.ws) for clients trading Upbit from Korea. We also monitor Binance listing notices. See the full API reference for details.

Frequently asked questions

What kind of Bithumb announcements does CryptoListing.ws forward?

The high-signal ones a trading bot can act on: new spot listings, spot delistings, and caution releases (the 유의 종목 지정 해제 event that lifts a previous caution flag). Maintenance windows, routine network upgrades, event marketing, and intermediate caution-lifecycle stages (pre-warning, designation, extension, deposit halts) are detected internally but kept off the broadcast — they generate noise without a clear actionable trade. The goal is a feed where every message is worth the bot attention.

Why does Bithumb matter alongside Upbit?

Bithumb is the second-largest Korean exchange and lists tokens that do not always appear on Upbit, or appear later. Listings on Bithumb produce their own Kimchi premium effect, often smaller than Upbit but still tradeable. Subscribing to both exchanges captures the full Korean retail-driven listing alpha — and both also surface caution-release and delisting events, so the structural-risk channel is identical across the two.

How is Bithumb different from Upbit for bot trading?

Both are KRW-denominated and serve Korean retail. Upbit has higher volume and faster price action; Bithumb tends to have less crowded listing trades but smaller pumps. Many bots run identical strategies on both exchanges via separate API keys, then compare PnL per listing to tune their parameters. Both exchanges also surface a caution lifecycle on existing tokens — we forward the two stages a bot can act on (caution_released as a positive technical signal, spot_delisting as the final removal).

Where is the Bithumb detection engine hosted?

Our Bithumb detection engine runs in Seoul, directly polling the official Bithumb announcement feed. Detection happens locally and the parsed announcement is forwarded to the Tokyo central server over a warm TCP connection in a few milliseconds, then broadcast to all subscribed WebSocket clients.

How do I filter for Bithumb only?

Append ?cex=bithumb to the WebSocket URL. To get all Korean listings on one stream, use ?cex=bithumb,upbit and use the listingExchange field to route orders to the correct venue. The schema is identical across exchanges, so handler code stays uniform.

What does Bithumb's caution / designation system mean for my bot?

It's a multi-stage risk lifecycle on tokens already trading: pre-warning, formal designation as 'investment caution' / 'trading caution', extension, then either release or final delisting. We narrow the broadcast to the two stages that drive trades — caution_released (positive resolution, warning lifted, often a technical bounce) and spot_delisting (final removal). The intermediate stages are detected on our side but not forwarded; their information value rarely justifies the noise.