Ladder Dragon: บอทเทรด Spot ที่ออกแบบให้หยุดเมื่อไม่แน่ใจ

แก่นของเรื่อง

ถ้าจำได้อย่างเดียว ให้จำว่า ระบบนี้ไม่พยายามทำนายราคาให้แม่นขึ้น แต่ทำให้ทุกการตัดสินใจ "มีขอบเขต เห็นได้ กู้คืนได้ และวัดผลได้" ข้อเท็จจริงนี้มาจากคำอธิบายจุดประสงค์ของโปรเจกต์เอง

ทำไมแนวคิดนี้ได้ผล (กลไกเหตุและผล)

1. บอทเทรดพังบ่อยที่สถานะกลางทาง เช่น ซื้อได้แล้วแต่โปรเซสดับก่อนตั้งตัวป้องกัน ระบบจึงเขียน intent ลง journal ก่อนส่งคำสั่ง และเทียบกับ Binance ทุกครั้งที่ฟื้น
2. ถ้าอ่านสถานะไม่ได้หรือผลคำสั่งไม่ชัด ระบบเลือกหยุด (HALT) แทนเดา การหยุดมีต้นทุนต่ำกว่าการเปิด position ที่ไม่มีตัวป้องกัน
3. ตัวเลขกำไรขาดทุนมาจากการจับคู่ lot แบบ FIFO ด้วยจำนวน ราคา และค่าธรรมเนียมจริง ถ้าข้อมูลไม่ครบก็ไม่รายงานตัวเลข จึงไม่มีกำไรลวงตา
4. AI และกลยุทธ์ใหม่เริ่มใน SHADOW (เก็บหลักฐาน ไม่แตะคำสั่ง) และเข้า APPLY ได้ต่อเมื่อผ่านเกณฑ์สถิติบนข้อมูลที่เก็บหลังจากแช่แข็ง candidate แล้ว

20% ที่สำคัญที่สุดในทางปฏิบัติ

สิ่งที่รอได้: dashboard, Telegram report, การ deploy บน Raspberry Pi ซึ่งเป็นงานปฏิบัติการรอบตัวระบบ ไม่ใช่แกนของแนวคิด

ช่วยให้ดีขึ้นอย่างไร

โปรเจกต์ไม่ประกาศตัวเลขกำไร และระบุเองว่าไม่รับรองผลกำไร ตารางนี้จึงเทียบ "ความเสี่ยงที่ถูกควบคุม" ไม่ใช่ผลตอบแทน

ข้อแลกเปลี่ยนที่ต้องยอมรับ: เกณฑ์เข้มทำให้ช้า เช่น เฟสละ 45 วัน และต้องมี 56 decision ใหม่ก่อนยืนยัน (ตีความ: ค่าใช้จ่ายคือเวลาและโอกาสที่เสียไปตอนรอ)

Important canary ที่ผ่านพิสูจน์ได้เพียงวงจร BUY ถึง protection หนึ่งรอบ ไม่ได้พิสูจน์ว่ากลยุทธ์ทำกำไร และโปรเจกต์ระบุว่าผลนี้ไม่อนุญาตให้เพิ่ม exposure

ลองใช้

ตัวอย่างที่ 1: FIFO กับค่าธรรมเนียม (ตัวอย่างประกอบ)

ซื้อ 1 หน่วยที่ 100 แล้วซื้ออีก 1 หน่วยที่ 110 จากนั้นขาย 1.5 หน่วยที่ 120 ค่าธรรมเนียมรวม 0.18

รายงานของระบบใส่ค่าธรรมเนียมเป็นเครื่องหมายลบเพราะลดกำไรสุทธิ ถ้าไม่ทราบค่าธรรมเนียม ระบบไม่ใส่ศูนย์แทน

ตัวอย่างที่ 2: เกณฑ์ 6 จาก 7 block ผ่านง่ายแค่ไหน (ตัวอย่างประกอบ)

Confirmation แบ่ง decision เป็น 7 block block ละ 8 รวม 56 และต้องบวกอย่างน้อย 6 block สมมติ (ข้อสมมติของเรา ไม่ใช่ของโปรเจกต์) ว่าแต่ละ block บวกหรือลบด้วยโอกาสเท่ากัน:

เกณฑ์นี้เพียงอย่างเดียวจึงผ่านโดยบังเอิญได้ราว 1 ใน 16 นี่คือเหตุผลที่ต้องมีเกณฑ์ lower confidence bound และ Holm correction ซ้อนอีกชั้น

ตัวอย่างที่ 3: Holm correction (ตัวอย่างประกอบ)

ทดสอบ 3 สมมติฐาน ระดับนัยสำคัญ 0.05 เรียง p-value จากน้อยไปมาก เทียบกับ 0.05 หารด้วยจำนวนที่เหลือ

ถ้าไม่แก้ จะผ่านทั้งสามตัวเพราะทุกตัวต่ำกว่า 0.05 ซึ่งคือปัญหา multiple comparison ที่ Holm แก้

เมื่อไรควรใช้ ไม่ควรใช้

ก้าวแรกที่เล็กที่สุด

รัน DRY กับ Binance Spot Testnet ด้วย BOT_LIVE_CONFIRMED=NO และ AI ปิด (AI_ADVISOR_ENABLE=0) แล้วดู dashboard ว่ามี order, protection และสถานะ HALT ครบหรือไม่ ยังไม่ต้องใส่คีย์ Mainnet

ทดสอบก่อนและหลัง

ทดสอบความเข้าใจ

กรอบความรู้: ข้อเท็จจริงเทียบกับข้อสรุป

คำอธิบายในหน้านี้อิงเอกสารของโปรเจกต์ ไม่ได้อ่านซอร์สโค้ดหรือรันระบบเอง จึงแยกระดับความมั่นใจดังนี้

ภาพรวมระบบ

Ladder Dragon เป็นระบบ Python แบบโอเพนซอร์ส (MIT) สำหรับ Binance Spot เวอร์ชัน 2.20.352 ณ วันที่ตรวจ 2026-10-10 และสถานะที่ประกาศคือ experimental

เจ็ดชั้นของระบบ

ความเสี่ยงที่ระบบตั้งใจควบคุม

กลไกหลัก

1. Entry ladder แบบปรับตัว

Ladder คือชุดคำสั่งซื้อที่วางเป็นขั้นราคาต่างกัน (คำนิยามทั่วไป ไม่ใช่สูตรของโปรเจกต์) ระบบปรับขั้นด้วยตัวชี้วัด ATR, EMA, VWAP, ADX และ market regime สูตรระยะห่างที่แน่ชัดไม่ได้อยู่ในเอกสารที่อ่าน

2. Protection ฝั่ง exchange

BUY ที่ fill แล้วถือว่าปลอดภัยเมื่อตรวจ OCO ทั้งสองขาแล้วเท่านั้น กฎที่เอกสารระบุ:

• OCO ที่ราคาไขว้กันไม่ถูกส่ง
• ถ้าติดตั้ง protection ไม่สำเร็จแบบชัดเจนใน LIVE ระบบพยายามปิด position ฉุกเฉินแบบที่ยืนยันได้
• ความไม่แน่ใจจากการอ่านสถานะไม่อนุญาตให้ถอด protection
• inventory ที่บอทจัดการกับ inventory เดิมของบัญชีแยกกัน และ protection ของฝั่งแรกไม่ครอบคลุมฝั่งหลัง

3. Journal และ recovery

Executor บันทึก intent ก่อนส่ง mutation ไปที่ exchange ผลที่ไม่ทราบเข้าสู่ reconcile หรือ HALT HALT บล็อกทุก mutation แต่ระบบที่สถานะดียังเก็บหลักฐาน SHADOW แบบไม่สั่งคำสั่งต่อได้

4. Accounting แบบ FIFO

5. Risk Manager

ควบคุม reserve, CAP, ขาดทุนรายวัน, spread, ความสดของข้อมูล และ gap risk จากจุดเดียว ส่วน ladder_dragon/risk/ ยังมี circuit breaker, VaR และ Expected Shortfall

6. AI และ prediction

AI ได้รับ aggregate ที่ตรวจแล้ว ไม่มีเครื่องมือสั่งคำสั่ง และกลับไปใช้กลยุทธ์ deterministic เมื่อผลลัพธ์ไม่ถูกต้องหรือผู้ให้บริการผิดพลาด

7. กระบวนการยืนยันทางสถิติ

flowchart TD
    A[Selection: เทียบ candidate บน snapshot เดียวกัน] --> B[Operator freeze 1 candidate]
    B --> C[manifest JSON + SHA-256]
    C --> D[Confirmation: 56 decision ใหม่ 7 block x 8]
    D --> E{ผ่านเกณฑ์ block และ CI + Holm}
    E -->|ผ่าน| F[Operator อนุมัติ APPLY]
    E -->|ไม่ผ่าน| G[คงอยู่ใน SHADOW]

การเรียงลำดับในแผนภาพเป็นการต่อภาพของเรา เอกสารระบุกฎแต่ละข้อแยกกัน

กลยุทธ์ที่เทียบกับ baseline NO_TRADE/USDT นับต้นทุนโอกาสของช่วงที่ไม่เทรดด้วย และ cohort ที่เข้าเทรดจริงเป็นเพียง diagnostic อนุมัติ APPLY ไม่ได้ PANIC มี safety veto แยก ไม่ทดสอบ expectancy

8. Defensive ensemble

ระดับการปล่อยใช้งาน

ตัวเลข canary: notional สูงสุด 10 USDT ตัวอย่างคำสั่งใช้ 6 USDT และค่าธรรมเนียมสูงสุด 0.02 USDT คิดเป็น 0.02/6 = 0.33% ของ notional

สถาปัตยกรรมโค้ด

bin / FastAPI routes
        |
application services (supervision, verification)
        |
domain services (strategy, risk, AI policies)
        |
infrastructure adapters (execution, SQLite, Binance)

กฎการพึ่งพา: โค้ดใน package ห้าม import bin ส่วนโมดูล prediction ห้าม import ความสามารถสั่งคำสั่งของ exchange

เกณฑ์ที่บังคับด้วย harness

ติดตั้งและตรวจสอบ

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[test,dashboard]'
cp .env.example .env

ต้องใช้ Python 3.10 ขึ้นไป ห้าม commit .env, database, log, archive หรือ private key และใช้คีย์ Binance แบบอ่านอย่างเดียวแยกสำหรับ dashboard

Exit code: 0 PASS, 1 FAILED, 2 BLOCKED การ deploy ใช้ SHA เต็ม 40 ตัวอักษรจากรายงาน PASS เท่านั้น และห้ามลบหลักฐานหรือลดเกณฑ์เพื่อเปลี่ยนผล

แพลตฟอร์มที่รองรับ

Replay และ backtest

Replay อ่านเหตุการณ์ตลาดแบบ JSONL ตามลำดับเวลา จำลองข้อมูล L2 กับคิว price-time ในเครื่อง และไม่อ้างว่าสร้าง L3 ของ Binance ได้ตรงตามจริง หลักฐานต้องมี hash ของ archive และ latency ที่วัดได้ ผลจำลองถูกเทียบกับผลจริงของคำสั่งที่จบแล้ว และ calibration archive หนึ่งชุดมีรายงานตรวจสอบได้หนึ่งฉบับ

Dashboard และ Telegram

ข้อจำกัด ความเสี่ยง และความเข้าใจผิด

Warning ซอฟต์แวร์นี้ส่งคำสั่งจริงได้ ไม่ใช่คำแนะนำการลงทุน และโปรเจกต์ไม่รับรองผลกำไร โดยค่าเริ่มต้นเป็น DRY

ข้อจำกัดที่โปรเจกต์ยอมรับเอง

ความเข้าใจผิดที่พบบ่อย

ข้อผิดพลาดที่ควรหลีกเลี่ยงเมื่อนำไปใช้

• ข้าม Testnet แล้วใช้คีย์ Mainnet ทันที
• ใช้คีย์เดียวทั้งเทรดและ dashboard
• ตีความผล BLOCKED ว่าเกือบผ่าน
• ปรับเกณฑ์ให้หลวมเพื่อให้ผลเปลี่ยน
• เก็บ .env หรือ database ไว้ใน Git

Checklist ก่อนขึ้น LIVE

ความหมาย: 🟢 โปรเจกต์ระบุว่าต้องทำและต้องมี, 🟡 ต้องตรวจเองต่อบัญชี, 🔴 ช่องว่างที่ยังเปิด, ⚪ ทำที่หลัง

ข้อมูลที่ไม่มีและข้อสมมติ

Decision และขั้นต่อไป

Recommendation ถ้าจะเรียนรู้จากโปรเจกต์นี้ ให้เริ่มจากเอกสาร Runtime safety and reporting และ Implementation status เพื่อเก็บตารางตัดสินใจของ operator ก่อนอ่านโค้ด แล้วค่อยเอาแนวคิด journal, protection ที่ตรวจแล้ว และ SHADOW ไปใช้กับบอทของตัวเอง

Sources

• โปรเจกต์: https://github.com/potekhinskill/Ladder-Dragon (MIT, อ่านเมื่อ 2026-10-10)
• ไฟล์ที่อ่านจริง: README.md, docs/INTRODUCTION.md, docs/ARCHITECTURE.md
• ไฟล์ที่ไม่ได้อ่าน: docs/RUNTIME_SAFETY_AND_REPORTING.md, docs/IMPLEMENTATION_STATUS.md, docs/CONFIGURATION.md, DECISIONS.md, MISTAKES.md

ตัวย่อที่ใช้ในหน้านี้

ตัวย่อทางเทคนิคและการเทรด

ตัวย่อด้านโหมดและระบบ

แถวที่มาจากความรู้ทั่วไปไม่ใช่นิยามของโปรเจกต์: ATR, EMA, VWAP, ADX, OCO, STOP, TP, FIFO, PnL, L2, L3, OHLC, VaR, HMM, USDT, RAG, CI, SHA-256, JSON, SQLite, API, WSL2, CLI, ASGI, FastAPI, MIT, Semgrep, IP, Pi ส่วน DRY, SHADOW, APPLY, HALT, PANIC, NO_TRADE, CAP อ่านความหมายจากบริบทที่โปรเจกต์ใช้ ค่าตัวอย่างในคอลัมน์ "อ่านค่าอย่างไร" เป็นตัวอย่างประกอบของเรา

สัญลักษณ์ในสูตรและหน่วย

Summary

• ใช้แนวคิดได้ทันที: journal ก่อนส่งคำสั่ง, protection ที่ตรวจแล้ว, แยก cash flow กับ PnL
• อย่าตีความเกณฑ์สถิติว่าเป็นหลักฐานของกำไร มันคือเกณฑ์กันความบังเอิญ
• ช่องว่างที่ต้องตรวจเอง: สูตร ladder, ผลย้อนหลัง, ความถูกต้องของโค้ด