Bithumb 上幣與風險生命週期提醒

檢測交易機器人可執行的 Bithumb 事件：新現貨上幣、解除警示（指定撤銷）以及最終下幣。實時 WebSocket 派送，微秒級解析，每個階段都有確定性的事件標識。

為什麼要監控 Bithumb 上幣公告？

Bithumb 是韓國最大的加密貨幣交易所之一，按交易量位居全球前列。與其他韓國交易所一樣，由於韓國加密市場相對孤立，Bithumb 上幣公告也可能在國際市場上引發顯著的價格波動。

除了上幣之外，Bithumb 還會在代幣下幣之前釋出一套結構化的風險通知序列 — 預警示、正式警示指定、延長，以及最終的解除或下幣。我們會捕獲每一個階段。結合Upbit 上幣公告提醒，監控 Bithumb 可讓您全面覆蓋韓國交易所市場。

我們監控的 Bithumb 公告型別

我們持續監控 Bithumb 官方的公告與通知頻道。我們轉發新現貨上幣、解除警示（解除前一警示標記的 유의 종목 지정 해제 事件）以及現貨下幣。風險生命週期的中間階段（預警示、正式指定、延長、充值暫停）在我們這一側會被檢測到，但不會向外廣播 — 它們會帶來噪音，但不構成清晰可執行的交易。維護視窗、常規網路升級與活動營銷則會被過濾掉。

傳遞到推送匯流排上的 Bithumb 風險生命週期事件

進入推送匯流排的事件型別有兩種：caution_released（恢復事件 지정 해제 — 警示被解除，往往伴隨技術性反彈）以及 spot_delisting（最終下架 거래지원 종료）。兩者均由位於 Seoul 的檢測引擎與上幣事件一起派發，本地以微秒級解析，再透過常駐 TCP 鏈路轉發到 Tokyo 進行 WebSocket 廣播。

Bithumb 生命週期的演進過程

在 Bithumb 一側，一個代幣典型的風險軌跡為：유의촉구（預警示）→ 거래유의종목 지정（指定）→ 지정 연장（延長）→ 要麼 지정 해제（解除 — 我們以 caution_released 形式廣播），要麼 거래지원 종료（下幣 — 我們以 spot_delisting 形式廣播）。整個週期可能持續數週。一條 Bithumb 公告有時會同時涉及多個處於不同階段的代幣 — 例如同一條通知中一個代幣被解除警示、另一個代幣被下幣 — 我們會將其拆分為獨立的 WebSocket 事件，賦予不同的 listingType 值，便於您的機器人獨立路由。完整的走查與真實示例請參閱我們的部落格文章。

連線到 Bithumb 上幣提醒

使用 ?cex=bithumb 引數過濾 Bithumb 公告，然後按 listingType 欄位路由：

# Bithumb — 所有事件型別
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()

韓國交易所公告策略

同時監控 Bithumb 與 Upbit，可讓您全面覆蓋韓國市場。代幣上幣通知有時先出現在 Bithumb，有時先出現在 Upbit。率先公告的交易所通常會引發更大的拉盤：

# 監控所有韓國交易所
"wss://cryptolisting.ws?cex=bithumb,upbit"

Bithumb 公告的速度優勢

我們的檢測引擎全天候 24/7 執行，使我們比 Telegram 機器人和郵件提醒更快 — 同時也比其他基於 WebSocket 的上幣公告服務更快。我們專門打造的基礎設施在每一層都經過最佳化 — 從 Bithumb 公告檢測到您的客戶端，純粹是速度。Bithumb 事件目前從我們的東京端點 wss://cryptolisting.ws 派發；我們在 AWS Seoul 另外運營一個 Upbit 專屬映象（wss://kr.cryptolisting.ws），供從韓國交易 Upbit 的客戶使用。我們也監控 Binance 上幣公告。詳情請參閱完整 API 文件。

常見問題

CryptoListing.ws 轉發哪些 Bithumb 公告？

高訊號、可被交易機器人執行的事件：新現貨上幣、現貨下幣以及解除警示（解除前一警示標記的 유의 종목 지정 해제 事件）。維護視窗、常規網路升級、活動營銷以及警示生命週期的中間階段（預警示、指定、延長、充值暫停）在我們這一側會被檢測到，但不會向外廣播 — 它們會帶來噪音，但不構成清晰可執行的交易。目標是讓每一條進入推送的訊息都值得機器人關注。

為什麼除了 Upbit 還要看 Bithumb？

Bithumb 是韓國第二大交易所，會上線一些 Upbit 上沒有、或上線得更晚的代幣。Bithumb 上幣也會帶來自身的泡菜溢價效應，雖然通常小於 Upbit，但仍然可交易。同時訂閱兩家交易所，就能捕獲韓國散戶驅動的全部上幣 alpha — 兩家交易所同樣會發出解除警示與下幣事件，因此結構性風險這條通道在兩家之間是相同的。

機器人交易上 Bithumb 與 Upbit 有何不同？

兩家都以 KRW 計價，服務韓國散戶。Upbit 成交量更大、價格行為更迅速；Bithumb 的上幣交易擁擠度較低，但拉盤幅度也較小。許多機器人透過各自的 API 金鑰在兩家交易所執行相同的策略，然後按每次上幣比較 PnL 以調參。兩家交易所也都會就已交易的代幣發出警示生命週期事件 — 我們僅轉發機器人能據此交易的兩個階段（caution_released 作為正面的技術性訊號，spot_delisting 作為最終下架）。

Bithumb 檢測引擎部署在哪裡？

我們的 Bithumb 檢測引擎執行在首爾，直接輪詢 Bithumb 官方公告源。檢測在本地完成，解析後的公告會在數毫秒內透過常駐 TCP 連線轉發到東京中央伺服器，再廣播給所有已訂閱的 WebSocket 客戶端。

如何僅過濾 Bithumb？

在 WebSocket URL 後追加 ?cex=bithumb。如果想在同一條流上接收所有韓國上幣，使用 ?cex=bithumb,upbit，並透過 listingExchange 欄位把訂單路由到正確的交易場所。各交易所的 schema 完全一致，處理程式碼可以保持統一。

Bithumb 的警示 / 指定體系對我的機器人意味著什麼？

這是針對已交易代幣的多階段風險生命週期：預警示、正式指定為「投資警示」/「交易警示」、延長，最終要麼解除、要麼下幣。我們將廣播範圍收窄到推動交易的兩個階段 — caution_released（積極的解決，警示被解除，往往伴隨技術性反彈）和 spot_delisting（最終下架）。中間階段會在我們這一側被檢測到，但不會向外轉發；其資訊價值通常不足以抵消噪音。