Signal Ingress
Telegram Auth
Confirm Execute
YES
NO
Audit State
StatusFilled
Latency42ms
1R Risk CheckEncrypted APIPostgreSQLDockerCI/CD
專案速覽
- 專案類型
- 交易基礎設施
- 核心專注
- 訊號到執行的工作流 / 具備風險意識的訂單驗證 / 符合稽核標準的後端基礎設施
- 技術堆疊
- Python, Telegram, PostgreSQL, SQLAlchemy, Docker, GitHub Actions
- 公開成果
- 開源 GitHub 專案
- 免責聲明
- 本專案作為工程與工作流設計的作品集展示。不代表任何財務建議或交易獲利保證。
社群背景與痛點
Kaiyn Trading Bot 源自我創立並營運近三年的加密貨幣交易社群 Kaiyn Capital 內部的實際營運問題。
在以 Telegram 為主的交易社群中，市場新聞、行情討論、交易訊號和圖表更新的速度非常快。這種即時性對交易來說很有用，但也帶來了一定程度的操作摩擦：用戶必須在短時間內解讀訊號、計算與管理風險與下單，在多個應用程式內切換的過程，總是難以避免的出現執行錯誤。
建立這個專案是為了讓此工作流更加結構化。我們不再將交易訊號視為純文字訊息，而是透過機器人將其轉化為具備驗證、固定風險部位控制與清晰稽核紀錄的一站式執行流程。
線上 Demo
專案價值
本專案展示了如何將混亂的交易社群流程，轉化為更安全、可稽核、且需操作確認的系統化執行機制。
背景與挑戰
加密貨幣交易社群經常透過 Telegram 發送訊號，但手動執行往往帶來摩擦、不一致的部位大小、重複操作以及模糊的確認流程。
解決方案
我建立了一個結構化的執行工作流，將 Telegram 上的訊號傳遞與確認優先的交易操作、交易所規則驗證、風險部位計算及後端稽核紀錄相互連結。
工作流程
- ▹訊號解析
- ▹用戶確認
- ▹固定風險部位計算
- ▹交易所合約驗證
- ▹訂單準備
- ▹訂單執行
- ▹稽核追蹤
專案亮點
- ▹將 Telegram 上的交易訊號無縫轉換為結構化的執行工作流。
- ▹採用確認優先執行 (confirmation-first execution) 機制與固定 1R 風險部位控管 (fixed-risk sizing)。
- ▹內建加密 API 憑證儲存、稽核軌跡 (audit trail)、資料庫備份與 CI 檢查流程。
- ▹設計理念為生產級的營運工具，而非標榜獲利的自動交易機器人。
核心能力展現
- ▹將社群工作流程的問題轉化為軟體系統設計
- ▹設計具備風險意識的交易基礎設施
- ▹建構具備狀態管理、驗證與稽核能力的後端工作流
- ▹跳脫單純腳本思維，邁向生產級營運工具設計
代表性產出
訊號解析工作流
將非結構化的 Telegram 訊息解析為嚴謹且經過驗證的 JSON 格式資料。
Signal Webhook Payload
{
"asset": "BTC-USDT",
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
}
Strict JSON validation enforced
確認優先流程
互動式 Telegram 使用者介面，要求用戶在訂單執行前進行明確授權。
Interactive Auth
Execute Trade?
BTC-USDT LONG @ 1R
後端稽核管線
透過 PostgreSQL 進行不可變的狀態追蹤，確保訂單絕不重複執行。
Immutable Audit Trail
14:02:01Signal received[ok]
14:02:02Risk validated (1R)[ok]
14:02:05User confirmed[ok]
14:02:06Order executed[ok]
14:02:06State committed to DB[ok]
技術堆疊
PythonTelegramPostgreSQLSQLAlchemyDockerGitHub Actions
本專案作為工程與工作流設計的作品集展示。不代表任何財務建議或交易獲利保證。