Purpose: ปรับปรุง Binance_Business_Model.md จากระบบ Paper/Prototype ให้เป็นระบบที่พิสูจน์ได้ว่าอยู่รอดและสร้าง Cash Flow ได้ ก่อนนำเงินจริงเข้า Live

Core concept (v3): แยกเป็น 2 Book -- Book A (ETH Spot) สะสม ETH และสร้าง realized cashflow จาก Grid, Book B (USDT) ขาย Options premium ด้วยทุนของตัวเอง โดยมี ETH 4H Bollinger Band (200, 2.5) เป็นตัวกำหนด Risk Budget ของแต่ละช่วงตลาด ไม่ใช่สัญญาณเข้า trade และไม่ทำนายทิศทาง ETH

Status: 🟡 Paper / Pre-Live

Last Updated: 2026-10-06

Supersedes: Binance_Business_Model_v2_Improvement_Plan.md (2026-10-03)

What changed in v3

ℹ️ Section numbering Section 1-46 ใช้เลขเดิมของ v2 เพราะ BINANCE_OPTION_ENGINE/src/binance_options_engine/overlay/risk/v2_config.py อ้างถึง s4, s5.3, s9.2, s11-s15, s36 อยู่แล้ว ส่วนที่เพิ่มใน v3 ใช้รหัส V3-n และวางต่อจาก Section 1

1. Executive Decision

1.1 Business Model

ระบบนี้ไม่ใช่ "Options Trading Bot" และไม่ใช่ "Covered Call Bot" แต่เป็น:

ETH Cashflow Business ที่มีเครื่องจักร 2 ตัว และ Risk Engine คุมตรงกลาง

                         MASTER PORTFOLIO
                                │
                 ┌──────────────┴──────────────┐
                 │                             │
          BOOK A - ASSET                BOOK B - CASHFLOW
          ETH Inventory                 USDT Risk Capital
                 │                             │
          ┌──────┼──────┐               ┌──────┼──────┐
          │      │      │               │      │      │
         Grid   DVA   Hold          Short Put Short Call Hedge
                                      (core)  (tactical)
                 │                             │
                 └──────────────┬──────────────┘
                                │
                  ETH 4H BB(200, 2.5) REGIME ENGINE
                                │
                           RISK ENGINE
                                │
                  ┌─────────────┴─────────────┐
                  │                           │
            Economic Risk                Margin Risk
                  │                           │
                  └─────────────┬─────────────┘
                                │
                     NET CASHFLOW / ETH GROWTH

เป้าหมายหลักไม่ใช่การ maximize premium แต่คือ:

1. สร้าง Net Cash Flow อย่างสม่ำเสมอ
2. เพิ่ม/บริหาร ETH inventory อย่างมีวินัย
3. รักษา liquidity ในช่วง ETH crash
4. จำกัด tail risk
5. ทำให้ระบบหยุดตัวเองได้เมื่อสภาพตลาดหรือ exchange state ไม่ปลอดภัย
6. (v3) ปรับขนาด options risk ตาม market regime แทนการเปิด premium ตลอดเวลา

1.2 Core decisions ของ v3

⚠️ Warning BB ไม่ได้ทำให้ Options มีกำไรโดยตรง มันช่วยเรื่อง capital allocation และ risk control เท่านั้น ถ้า A/B test (V3-4) ไม่ดีกว่า baseline ให้ถอด filter ออก

V3-1. Two-Book Architecture

V3-1.1 Book A - ETH Asset Engine

เป้าหมาย: เพิ่มจำนวน ETH และสร้าง realized trading cashflow จาก Spot

KPI ของ Book A:

Realized Grid P&L
ETH Inventory (qty)
ETH from Grid / from Put Spot Leg / from manual funding
Average ETH Cost
Unrealized P&L

V3-1.2 Book B - Options Cashflow Engine

เป้าหมาย: สร้าง premium ด้วย USDT risk capital ที่อยู่ใน Options wallet จริง

ℹ️ Note Binance Options settle เป็น USDT (cash-settled) จึงไม่มีการส่งมอบ ETH คำว่า "assignment" ในเอกสารนี้หมายถึง Spot Leg ตาม §16: รับ settlement loss แล้วซื้อ ETH ใน Spot ที่ราคาใกล้ strike

V3-1.3 Cross-book rules

V3-1.4 พฤติกรรมตามสภาพตลาด

Options ไม่ใช่เครื่องที่ต้องเปิด 24/7 มันคือ cashflow overlay ที่เปิดตาม regime

V3-1.5 ตัวอย่างตัวเลข (illustrative เท่านั้น)

ทุน $100,000 ไม่ใช้ leverage: Book A ETH $60,000 / Book B USDT $40,000

$1,300 x 12 = $15,600 หรือราว 15.6% ต่อปีแบบ gross/simple

⚠️ Warning ตัวเลขนี้เป็นตัวอย่างเพื่ออธิบายโครงสร้าง ไม่ใช่ผลตอบแทนที่คาดหวังหรือรับประกัน เดือนจริงติดลบได้ และห้าม annualize จากช่วงสั้น (§34) ตัวที่ต้อง optimize คือ Net Cashflow / Max Drawdown ไม่ใช่ premium สูงสุด

V3-1.6 รายงาน 4 มุม

Cashflow ไม่เท่ากับ yield ระบบต้องรายงานอย่างน้อย:

1. Realized Cashflow
2. Unrealized P&L
3. Economic Portfolio P&L
4. Margin Risk

ตัวอย่าง monthly report:

MONTHLY REPORT                    Book A    Book B    Total
---------------------------------------------------------
Spot Grid realized                 +520                +520
Option Premium                               +920      +920
Option Loss                                  -210      -210
Hedge / Buyback                               -80       -80
Fees                               -25        -45       -70
---------------------------------------------------------
NET CASHFLOW                       +495      +585     +1,080
Economic P&L                                         +2,430
Max DD                                                -8.2%
Options Margin Utilization                    31%
Time in BB regime (N/Bu/Be/EBu/EBe)    62% / 18% / 14% / 3% / 3%

ตัวเลขใน report นี้เป็นตัวอย่าง format เท่านั้น

V3-2. ETH 4H Bollinger Band (200, 2.5) Regime Engine

V3-2.1 บทบาท

❗ Important ใน crypto ราคาอยู่นอก band ได้นาน และช่วงที่ premium แพงที่สุดมักเป็นช่วงที่ Short Put เสี่ยงที่สุด กฎ "แตะ Lower Band = ขาย Put" จึงห้ามใช้

V3-2.2 นิยาม

Window: 200 แท่ง x 4 ชั่วโมง = 800 ชั่วโมง หรือประมาณ 33 วัน

Middle   = SMA(close, 200)
sigma    = population stdev(close, 200)     # ddof = 0, ตรงกับ TradingView ta.stdev
Upper    = Middle + 2.5 x sigma
Lower    = Middle - 2.5 x sigma

%B       = (Price - Lower) / (Upper - Lower)          # ราคาอยู่ตรงไหนใน band
BBW      = (Upper - Lower) / Middle                   # ตลาดสงบหรือกำลังขยายตัว
BBW_pct  = percentile rank ของ BBW ใน 2,190 แท่งล่าสุด  # ประมาณ 1 ปีของแท่ง 4H
MidSlope = Middle[t] / Middle[t-30] - 1               # 30 แท่ง = 5 วัน
z(x)     = (x - Middle) / sigma                       # ระยะห่างของราคาหรือ strike เป็นหน่วย sigma

ความสัมพันธ์: %B = (z + 2.5) / 5 ดังนั้น %B = 0 คือ z = -2.5 และ %B = 1 คือ z = +2.5

V3-2.3 Regime classification

ตัวอย่าง: Upper = 3,200, Middle = 2,650, Lower = 2,100 -> sigma = 220, BBW = 0.415

V3-2.4 BBW และ slope flags

%B บอกว่าราคาอยู่ตรงไหน, BBW บอกว่าตลาดสงบหรือกำลังระเบิด สองตัวนี้ใช้ร่วมกันเป็น flag ที่ปรับ cap ลงได้อย่างเดียว:

s (slope threshold) ยังไม่กำหนด ต้องได้จาก backtest (V3-4) ตัวเลขทุกตัวในตารางนี้เป็น hypothesis

V3-2.5 Timing และ data rules

V3-2.6 Hysteresis: ลดเร็ว เพิ่มช้า

ทำ hysteresis ที่ระดับ cap ของแต่ละฝั่ง ไม่ใช่ที่ชื่อ regime เพราะ EXTREME_BULL เข้มกับ Put แต่หลวมกับ Call

cap ใหม่ < cap ปัจจุบัน   -> ใช้ทันทีที่แท่งปิด
cap ใหม่ > cap ปัจจุบัน   -> ใช้เมื่อ cap ที่สูงกว่าปรากฏติดกัน N แท่งปิด (initial N = 3 = 12 ชั่วโมง)

กันการสลับ regime ไปมาเมื่อราคาอยู่แถวเส้นแบ่ง

V3-2.7 BB เป็น slow layer

BB อัปเดตทุก 4 ชั่วโมง ส่วน crash model (§7), stress regime (§5.3) และ kill switch (§23) ทำงาน real-time ต่อไปตามเดิม และ tighten ได้อย่างเดียว ถ้า ETH ร่วง 20% ภายในแท่งเดียว ระบบต้องหยุดผ่าน real-time guard โดยไม่รอ BB

V3-2.8 BB ที่มีอยู่แล้วในโค้ด

V3-3. Dynamic Risk Budget

V3-3.1 หลักการ

Risk budget = ค่าต่ำสุดของ controller ทุกตัว แต่ละตัวลด cap ได้อย่างเดียว และระบบบันทึกว่าตัวไหน binding

PutCap  = min( PutCap_stress[stress_regime],
               PutCap_stress[NORMAL]  x M_put[bb_regime]  x F_put(flags) )

CallCap = min( CallCap_stress[stress_regime],
               CallCap_stress[NORMAL] x M_call[bb_regime] x F_call(flags) )

ทุก trade ยังต้องผ่าน gate เดิมของ v2 ครบ: Delta (§11), IV regime (§12), liquidity (§13), Portfolio ETH acquisition (§6), และ Book B standalone stress (XB-01)

V3-3.2 BB multiplier table

ค่าเริ่มต้นใช้ขอบล่างของช่วง (conservative) ขอบบนใช้ได้หลังผ่าน V3-4 เท่านั้น

ℹ️ Note ตารางนี้เป็น initial rule สำหรับ backtest ไม่ใช่ค่า production ค่า M_put = 0 ใน EXTREME_BULL และ M_call ที่ไม่ monotonic (BULL ต่ำกว่า NORMAL และ EXTREME_BULL) ยังเป็นคำถามเปิด -- OD-V3-01, OD-V3-02

V3-3.3 Cap matrix (BB regime x stress regime, ไม่มี flag, ค่า default)

PutCap (% ของ Book B USDT)

CallCap (% ของ Book A ETH qty)

V3-3.4 Position ที่เปิดอยู่แล้ว

• Cap คุมเฉพาะ exposure ใหม่
• ถ้า exposure ปัจจุบันเกิน cap ใหม่ -> ห้ามเปิดฝั่งนั้นเพิ่ม และส่ง position เข้า buyback evaluation (§14)
• Regime อย่างเดียวไม่สั่งปิด position แบบบังคับ การปิดต้องผ่าน economics ของ §14 หรือ kill switch (§23)

V3-3.5 Hedge modes

v2 §38 ไม่อนุญาต futures hedge, more option legs และ complex delta hedge ใน v3 จึงนิยาม Hedge เป็น de-risking action เท่านั้น:

Long put protection และ futures hedge อยู่นอก scope ของ v3 -- OD-V3-03

V3-3.6 Book A actions ตาม regime

V3-3.7 Strike selection: BB กำหนดขนาด, Delta + IV + ระยะห่างกำหนด strike

ทุก candidate ต้องรายงาน:

z_strike = (Strike - Middle) / sigma

z_strike เป็นระยะห่าง ไม่ใช่ความน่าจะเป็น เพราะ BB window ~33 วัน ไม่ตรงกับ DTE ของ option และ distribution ของ ETH มี fat tail ใช้คู่กับ Delta (§11) และ Expected Move (§12) เสมอ

V3-3.8 Worked example

สมมติ Book A = 22.22 ETH ($60,000 ที่ 2,700), Book B = 40,000 USDT, band คงที่ตาม V3-2.3

Cap คิดจาก Book B USDT ปัจจุบัน ถ้า put ขาดทุนไปแล้ว ฐานจะเล็กลงด้วย จำนวนจริงปัดลงตาม lot size ของ venue

V3-3.9 Decision audit record

ทุก option decision (รวม NO TRADE) ต้องบันทึก:

bar_open_time, close, middle, sigma, upper, lower,
pct_b, bbw, bbw_pct, mid_slope,
bb_regime_raw, bb_regime_effective, flags,
stress_regime,
put_cap_bb, put_cap_stress, put_cap_final, put_binding,
call_cap_bb, call_cap_stress, call_cap_final, call_binding,
hedge_mode, z_strike, config_fingerprint

record นี้ทำให้ตอบจาก log ได้ว่าวันนั้นทำไมระบบไม่ขาย Put

V3-4. Validation Plan สำหรับ BB Filter

BB filter เป็น indicator ที่เพิ่มเข้ามา ซึ่ง v2 §38 / §46 เตือนไว้ ต้องพิสูจน์ว่าช่วยจริงก่อนใช้

🎯 Decision rule ถ้า VAL-01 หรือ VAL-03 ไม่ผ่าน ให้ถอด BB filter และกลับไปใช้ stress regime ของ v2 อย่างเดียว

Data gap: ราคา ETH 4H มีย้อนหลังหลายปี แต่ IV history ของ Binance Options สั้น ถ้าใช้ proxy (เช่น Deribit DVOL) ต้อง label ใน report ว่าเป็น proxy [ASSUMPTION]

V3-5. Open Decisions (owner)

ความขัดแย้งที่พบระหว่างแนวคิด v3, v2 และโค้ดปัจจุบัน ยังไม่ได้แก้ฝั่งใดฝั่งหนึ่งเงียบ ๆ

2. สิ่งที่ต้องปรับปรุงก่อน Live

Priority P0 — ต้องทำก่อนเงินจริง

3. เปลี่ยน KPI จาก "Premium" เป็น Business KPI

3.1 ห้ามใช้ Premium เป็น KPI หลัก

ตัวเลข:

Premium / Capital

ไม่เพียงพอ

เพราะ premium อาจมาจากการรับ tail risk และ Put assignment อาจเปลี่ยน USDT เป็น ETH ในช่วงตลาดลง

3.2 KPI หลัก

KPI-01 — Net Cash Flow Yield

Net Cash Flow Yield =
(
  Gross Option Premium
  - Option Fees
  - Spot Fees
  - Slippage
  - Buyback Cost
  - Other Trading Costs
)
/
Average Allocated Capital

ต้องรายงาน:

• Daily
• Weekly
• Monthly
• Annualized

KPI-02 — Total Economic Return

Economic Return =
Net Cash Flow
+ Realized Grid P&L
+ Mark-to-Market ETH Inventory Change
- Losses

ต้องแยก:

Cash Return
ETH Inventory Return
Total Economic Return

ห้ามรวมเป็นตัวเลขเดียวโดยไม่แยก component

KPI-03 — Liquidity Utilization

Liquidity Utilization =
Reserved Capital
/
Total Liquid Capital

รายงาน:

P50
P75
P90
P95
P99
Maximum

โดยเฉพาะช่วง ETH drawdown

KPI-04 — Maximum Drawdown

วัดทั้ง:

1. Portfolio USD DD
2. USDT DD
3. ETH-equivalent DD
4. Liquidity DD

KPI-05 — Recovery Time

วัด:

Peak
 ↓
Drawdown
 ↓
Recovery to previous peak

รายงานเป็น:

Median Recovery Time
Worst Recovery Time
P95 Recovery Time

KPI-06 — ETH Inventory Growth

แยก:

ETH from Grid
ETH from Put Assignment
ETH from manual funding

เพื่อดูว่า Options Overlay เพิ่ม ETH inventory จริงหรือเพียงแค่สร้าง USDT cash flow

4. เพิ่ม Capital Allocation Model

ไม่ควรปล่อยให้ระบบมอง capital เป็นก้อนเดียว

ให้แบ่งเป็น:

TOTAL CAPITAL
│
├── CORE ETH INVENTORY
│
├── OPTIONS MARGIN
│
├── PUT COLLATERAL
│
├── SPOT LEG RESERVE
│
├── EMERGENCY LIQUIDITY
│
└── OPERATIONAL BUFFER

(v3) แต่ละ bucket สังกัด book เดียว:

Grid USDT working capital (เงินรอซื้อของ grid) อยู่ใน Book A ห้ามนับเป็น PUT COLLATERAL

แต่ละ bucket ต้องมี:

• Owner
• Minimum
• Target
• Maximum
• Transfer rule
• Emergency rule

5. ปรับ PUT Budget

5.1 ปัญหา

Current:

PUT notional <= 88% of USDT
Free USDT >= 10%

โครงสร้างนี้มี liquidity risk เพราะใน ETH crash หลาย puts อาจ ITM พร้อมกัน

5.2 เปลี่ยนจาก Fixed 88% เป็น Dynamic Utilization

ไม่ควรกำหนด 88% เป็นค่าถาวร

ให้คำนวณจาก stress scenario:

Max Put Exposure =
f(
    available USDT,
    stress loss,
    expected assignments,
    margin requirement,
    liquidity reserve,
    ETH drawdown
)

5.3 Proposed Initial Framework

ให้ทดลอง:

NORMAL
Put Utilization <= 60%

CAUTION
Put Utilization <= 45%

STRESS
Put Utilization <= 25%

EXTREME
No new Put

หมายเหตุ: ตัวเลขเหล่านี้เป็น starting parameters สำหรับ stress testing ไม่ใช่ final production values

Final value ต้องมาจาก simulation

(v3) ค่าเหล่านี้คือ PutCap_stress ใน V3-3.1 และเป็นเพดานเสมอ BB regime ลดได้อย่างเดียว:

PutCap = min( PutCap_stress[stress_regime], 60% x M_put[bb_regime] x F_put(flags) )

6. เพิ่ม Portfolio-Level Put Exposure

ปัจจุบันต้องไม่ดูเฉพาะ Put แต่ละตัว

ต้องดู:

Total Potential ETH Acquisition

เช่น:

Put #1 → 2 ETH
Put #2 → 3 ETH
Put #3 → 4 ETH

Potential Assignment = 9 ETH

ระบบต้องรู้ว่า:

Current ETH
+
Potential Assigned ETH

จะกลายเป็นเท่าไรภายใต้ full assignment

7. เพิ่ม Crash Scenario Model

ต้องมีอย่างน้อย:

ETH -10%
ETH -20%
ETH -30%
ETH -40%
ETH -50%
ETH -60%
ETH -70%

แต่ละ scenario ต้องคำนวณ:

ETH price
Open Put ITM
Settlement loss
Spot purchase requirement
Remaining USDT
Remaining Options collateral
Margin usage
MM ratio
ETH inventory
Portfolio DD
Liquidity utilization

8. เพิ่ม Multi-Event Stress Test

ไม่ควรทดสอบเฉพาะราคาลง

ต้อง test:

Scenario A — ETH Crash

ETH -40%
Put ITM
Several assignments

Scenario B — ETH Crash + IV Spike

ETH -40%
IV ↑
Option margin ↑

Scenario C — Crash + Spot Slippage

ETH -40%
Settlement S != execution price

Scenario D — Crash + Transfer Failure

Put ITM
Transfer delayed
Spot leg waiting

Scenario E — Crash + API Failure

Exchange API unavailable

Scenario F — Strong Rally

ETH +30%
Short Call ITM

Scenario G — Gap Move

ETH jumps significantly between
snapshot → order → fill → settlement

9. Covered Call ต้องแยกเป็น "Economic Covered" และ "Exchange Covered"

Binance architecture ทำให้ ETH ใน Spot ไม่ได้เป็น collateral ของ Options wallet

ดังนั้น:

Economic Position:
ETH-backed call

Exchange Position:
USDT-margined short call

ระบบต้องแสดงสองมุมนี้แยกกัน

(v3) เลิกใช้ชื่อ "Covered Call" ในระบบ ใช้ USDT-funded Short Call แทน เพราะ position นี้ economically correlated กับ Book A แต่ไม่ได้เป็น margin-covered position ถ้า ETH พุ่ง Book A ได้ unrealized gain แต่ Binance ไม่เอากำไรนั้นมาหัก margin ของ Book B ให้ (XB-04, XB-05)

9.1 Call Risk Model

ต้องคำนวณ:

Call Margin
+
Potential ITM Settlement
+
Required Buffer

ไม่ใช่ดูแค่ CC_MARGIN

9.2 ลด Call Exposure หาก Margin Stress

เพิ่ม dynamic rule:

Normal:
Call <= 30% ETH

Margin Stress:
Call <= 20%

High Stress:
Call <= 10%

Extreme:
No new Call

Final values ต้องผ่าน simulation

(v3) ค่าเหล่านี้คือ CallCap_stress และเป็นเพดานเสมอ:

CallCap = min( CallCap_stress[stress_regime], 30% x M_call[bb_regime] x F_call(flags) )

ผลคือใน regime ปกติ Call ใช้ได้ราวครึ่งหนึ่งของ v2 (15% แทน 30%) ตามหลัก Short Call = tactical

10. เปลี่ยน Strike Selection ให้เป็น Risk-Aware

ปัจจุบัน:

Call:
sell_zone_top x 1.02

Put:
next_buy_zone x 0.98

ยังดีสำหรับ Grid integration แต่ควรเพิ่ม:

Delta
IV
Liquidity
Spread
Distance from Spot
Expected Move
Portfolio Exposure

(v3) เพิ่ม z_strike (ระยะห่างจาก BB middle เป็นหน่วย sigma) เป็น input อีกตัว รายละเอียดใน V3-3.7 BB ไม่ได้เลือก strike เอง แค่ตั้ง gate ขั้นต่ำ

11. เพิ่ม Delta Constraint

ทุก option candidate ต้องมี:

Call Delta <= configured max
Put Delta <= configured max

และต้องแยก:

Individual Delta
Portfolio Delta

ไม่ควรให้หลาย option ที่ดูเหมือน risk ต่ำเมื่อแยกกัน แต่รวมกันมี directional exposure สูง

12. เพิ่ม IV Regime

แบ่ง:

LOW IV
NORMAL IV
HIGH IV
EXTREME IV

ไม่ควรใช้ premium absolute value อย่างเดียว

ต้องดู:

Premium / Expected Move
Premium / Margin
Premium / Risk Capital

13. เพิ่ม Option Liquidity Filter

Current:

bid/mark <= 10%
spread <= 20% mark
IV >= 40%
premium >= 5 USDT

ควรเพิ่ม:

Open Interest
Volume
Bid Size
Ask Size
Quote Age
Last Trade Age

และ reject option ถ้า:

OI ต่ำ
Quote stale
Bid size ไม่พอ
Spread กว้างเกิน threshold

14. แก้ Buyback Logic

Current:

buyback cost <= 20% of premium

ควรเปลี่ยนจาก fixed percentage เป็น economics-based rule

ตัวอย่าง:

Remaining Premium
vs
Remaining Risk
vs
Time to Expiry

เช่น:

Close if:

Remaining Expected Profit
<
Risk Capital Saved

หรือใช้:

Premium Capture %

เป็นหนึ่งใน input

15. เพิ่ม Time-to-Expiry Risk

Option ที่เหลือ 1 วันกับ 10 วันไม่ควรใช้ risk model เดียวกัน

เพิ่ม:

DTE bucket

0–1 DTE
2–3 DTE
4–7 DTE
8–14 DTE

และกำหนด behavior ต่างกัน

16. Spot Leg ต้องมี State Machine ที่แข็งแรงขึ้น

Current:

SETTLEMENT
→ TRANSFER
→ MARKET BUY
→ CLOSED

ต้องเพิ่ม:

CREATED
→ FUNDED
→ BUYING
→ PARTIAL_FILL
→ COMPLETE
→ RECONCILED
→ CLOSED

กรณีซื้อไม่ครบ:

PARTIAL_FILL

ต้องมี explicit policy

ห้ามปล่อยให้ระบบอยู่ใน state ที่ไม่รู้ว่า asset เป็นของใคร

17. Partial Fill Policy

กำหนดชัดเจนว่า:

Bought >= X%

ทำอะไร

และ:

Bought < X%

ทำอะไร

ตัวอย่าง:

>= 95%
→ complete

50–95%
→ continue / retry

< 50%
→ emergency handling

ตัวเลขต้องกำหนดจาก testing

18. Reconciliation เป็น P0

ต้อง reconcile อย่างน้อย:

Internal Ledger
vs
Spot Wallet
vs
Options Wallet
vs
Open Orders
vs
Open Positions
vs
Settled Options

Invariant สำคัญ:

Internal ETH
==
Exchange ETH

Internal USDT
==
Exchange USDT

ภายใน tolerance ที่กำหนด

ถ้าไม่ตรง:

HALT NEW ORDERS

19. เพิ่ม Double-Entry Ledger

ทุก transaction ต้องมี:

Debit
Credit
Timestamp
Source
Reference
Exchange transaction ID
Strategy ID
Position ID

ตัวอย่าง:

OPTION_PREMIUM
OPTION_FEE
SETTLEMENT_LOSS
SPOT_PURCHASE
SPOT_FEE
TRANSFER
BUYBACK

ทำให้ audit ได้ย้อนหลัง

20. Transfer Manager ต้องเป็น Transactional

ทุก transfer ต้องมี:

REQUESTED
→ SUBMITTED
→ PENDING
→ CONFIRMED

และ failure:

FAILED
RETRYING
ESCALATED

ห้าม retry โดยไม่มี idempotency

21. เพิ่ม Idempotency

ทุก operation สำคัญต้องมี unique ID:

order_id
transfer_id
settlement_id
spot_leg_id
reservation_id

ถ้า process restart:

system restart

ต้องสามารถ resume ได้โดยไม่สร้าง duplicate transaction

22. Restart / Recovery Test

ต้องทดสอบ:

Restart before order
Restart after order
Restart after fill
Restart before settlement
Restart after settlement
Restart during transfer
Restart during spot buy
Restart after partial fill

ระบบต้อง reconstruct state จาก exchange + ledger

23. Kill Switch

เพิ่ม kill switch ระดับ:

LEVEL 1
Stop new Calls

LEVEL 2
Stop new Puts

LEVEL 3
Stop all new Options

LEVEL 4
Cancel pending orders

LEVEL 5
Emergency reconciliation

ไม่ควรใช้คำว่า "halt" แบบเดียวกับทุกสถานการณ์

(v3) BB regime gate แยกจาก kill switch Kill level เป็นแบบสะสม (Level 2 รวม Level 1) แต่ BB regime ปิดฝั่งได้ไม่เรียงลำดับ เช่น EXTREME_BULL ปิด Put แต่ยังเปิด Call ได้ จึงให้ BB ทำงานผ่าน cap = 0 ของแต่ละฝั่ง (V3-3) ส่วน kill switch ยังใช้กับเหตุ operational และ real-time risk ตามเดิม ถ้าทั้งสองสั่งพร้อมกัน ใช้ตัวที่เข้มกว่า

24. Risk Budget ต้องแยก Strategy Risk กับ Operational Risk

TOTAL RISK
│
├── Market Risk
│   ├── ETH crash
│   ├── ETH rally
│   └── IV spike
│
├── Options Risk
│   ├── Call
│   └── Put
│
├── Liquidity Risk
│
├── Exchange Risk
│
└── Operational Risk

25. เพิ่ม Exchange Failure Scenario

ต้องทดสอบ:

API timeout
Rate limit
Order rejection
Transfer delay
Incorrect quote
Stale quote
Options settlement delay
Spot market unavailable
Account permission failure

ระบบต้องตอบได้ว่า:

เมื่อ Binance ไม่ตอบ 30 วินาที / 5 นาที / 30 นาที ระบบทำอะไร

26. Paper Trading ต้องแบ่งเป็น 3 ระดับ

Level 1 — Pure Simulation

Market data จริง

Order จำลอง

Level 2 — Binance Demo

Order จริงใน demo/test environment

ทดสอบ:

Options
Wallet
Transfer
Settlement
Spot

Level 3 — Shadow Live

อ่านข้อมูลบัญชีจริง

แต่:

NO LIVE ORDERS

ระบบตัดสินใจเหมือน Live และบันทึกว่า:

ถ้าส่งจริงจะทำอะไร

แล้วเทียบกับตลาดจริง

27. Live Ramp-Up

ห้าม:

Paper
↓
100% Capital

ให้:

Paper
↓
Demo
↓
Shadow Live
↓
5% Capital
↓
10%
↓
25%
↓
50%
↓
Production

แต่ละ stage ต้องมี acceptance criteria

28. Acceptance Criteria

Strategy

ต้องผ่าน:

Positive Net Cash Flow
Positive Risk-adjusted Return
Acceptable Max DD
Acceptable Recovery Time

Liquidity

ต้องผ่าน:

No negative cash
No unplanned borrowing
No forced liquidation
No unresolved spot leg

Operational

ต้องผ่าน:

100% state recovery
100% ledger reconciliation
No duplicate orders
No duplicate transfers

29. Backtest Dataset

ต้องครอบคลุม market regimes:

Bull
Bear
Sideways
High Volatility
Low Volatility
Crash
Fast Recovery
Slow Recovery

ไม่ควรใช้เฉพาะช่วงที่ ETH sideway เพราะ option selling จะดูดีเกินจริง

(v3) label ทุกแท่งด้วย BB regime ด้วย (V3-2.3) แล้วตรวจว่า dataset มีช่วง EXTREME_BEAR และ EXTREME_BULL มากพอให้ผลแยกตาม regime มีความหมาย ถ้าบาง regime มีตัวอย่างน้อย ให้ระบุใน report ว่าผลของ regime นั้นยังเชื่อถือไม่ได้

30. Monte Carlo

สร้างอย่างน้อย:

10,000 paths

โดยสุ่ม:

Return
Volatility
IV
Gap
Slippage
Fill Rate
Transfer Delay
Settlement Delay

ดู:

P50
P90
P95
P99
Worst Case

31. Monte Carlo Output ที่ต้องมี

ทุก simulation ต้อง report:

Ending Capital
Ending ETH
Ending USDT
Annualized Cash Yield
Total Return
Max DD
Max Liquidity Utilization
Max Margin Usage
Number of Assignments
Number of Calls ITM
Number of Spot Leg Overdue
Number of Risk Halts
Recovery Time

32. Business Model Dashboard

Dashboard ควรมี 5 sections:

A. Capital

Total Capital
ETH
USDT
Options Margin
Reserved
Free

B. Cash Flow

Premium
Fees
Buyback
Settlement
Net Cash Flow

C. Inventory

ETH Holdings
Grid ETH
Put-assigned ETH
Average ETH Cost

D. Risk

Portfolio DD
Margin Usage
MM Ratio
Put Utilization
Call Utilization
Liquidity Utilization

E. System

Open Positions
Pending Transfers
Pending Spot Legs
Reconciliation
Kill Switch
System Health

F. Regime (v3)

ETH 4H Close
BB Upper / Middle / Lower
%B
BBW / BBW_pct
MidSlope
BB Regime (raw / effective)
Flags (SQUEEZE / TREND_UP / TREND_DOWN)
Stress Regime
PutCap / CallCap (final + binding controller)
Hedge Mode
Bars until cap can increase (hysteresis)

Section A-C ต้องแสดงแยก Book A / Book B / Total

33. เพิ่ม "Cash Flow vs Inventory" Report

ทุกเดือนต้องตอบได้:

How much cash did the business generate?

How much ETH did the business accumulate?

How much risk capital was used?

How much capital was locked?

How much return came from premium?

How much return came from ETH price appreciation?

นี่คือ report ที่สำคัญที่สุดของ business model

34. อย่าใช้ Annualized Yield จากช่วงเวลาสั้น

ตัวอย่าง:

7-day premium = 1%

ไม่ควรสรุปทันที:

1% x 52 = 52% APY

เพราะ:

• IV เปลี่ยน
• opportunity เปลี่ยน
• assignment เปลี่ยน
• liquidity เปลี่ยน
• market regime เปลี่ยน

ให้รายงาน:

Realized Annualized
Rolling 30D
Rolling 90D
Rolling 180D
Rolling 365D

35. Core Business Rule

ระบบต้องรักษาหลักการ:

Do not sell premium simply because premium is available.

ต้องขายเมื่อ:

Premium
+
Strike
+
Delta
+
Liquidity
+
Portfolio Exposure
+
Stress Risk

อยู่ในกรอบที่รับได้พร้อมกัน

36. New Decision Engine

เปลี่ยนจาก:

Can I sell this option?

เป็น:

Does this option improve the portfolio?

Scoring ไม่ควรใช้เป็นคะแนนเพื่อ "force trade"

ให้ใช้เป็น decision diagnostics:

Premium Quality
Risk Quality
Liquidity Quality
Portfolio Fit
Capital Efficiency

ถ้าไม่ผ่าน → No Trade

37. No-Trade เป็นผลลัพธ์ปกติ

ระบบต้องยอมรับ:

NO TRADE

เป็น successful outcome

ตัวอย่าง:

IV ต่ำ
Liquidity ต่ำ
Margin สูง
Put exposure สูง
Portfolio DD สูง

ผลลัพธ์:

NO NEW OPTION

ไม่ใช่พยายามหา trade เพื่อสร้างรายได้ทุกวัน

38. สิ่งที่ไม่ควรเพิ่มตอนนี้

ไม่ควรเพิ่ม:

Futures hedge
Leverage
Martingale
More option legs
Iron Condor
Calendar Spread
Complex Delta Hedge
AI prediction
Directional signal

ก่อนพิสูจน์ architecture ปัจจุบัน

เพราะจะทำให้ attribution และ risk model ซับซ้อนขึ้น

(v3) BB(200, 2.5) ไม่ใช่ directional signal ในความหมายของ section นี้ เพราะใช้ลดขนาด risk เท่านั้น ไม่เปิด trade และไม่เพิ่ม cap เกิน v2 แต่ยังเป็น indicator ที่เพิ่มเข้ามา จึงต้องผ่าน V3-4 ก่อนใช้จริง (OD-V3-05) รายการด้านบนยังห้ามเหมือนเดิม รวมถึง futures hedge ที่ตาราง BB เดิมพูดถึง (OD-V3-03)

39. Final Architecture

                            MARKET DATA
                                 │
              ┌──────────────────┼──────────────────┐
              ↓                  ↓                  ↓
       ┌─────────────┐   ┌───────────────┐   ┌─────────────┐
       │ GRID ENGINE │   │ BB REGIME     │   │ OPTIONS     │
       │ (Book A)    │   │ ENGINE (4H)   │   │ CHAIN / IV  │
       └──────┬──────┘   │ %B BBW Slope  │   └──────┬──────┘
              │          └───────┬───────┘          │
   Grid Zones / Inventory        │            CALL / PUT
              │           BB caps + flags     CANDIDATES
              │                  │                  │
              └──────────────────┼──────────────────┘
                                 ↓
                           RISK ENGINE
                                 │
     ┌───────────────┬───────────┼───────────┬────────────────┐
     ↓               ↓           ↓           ↓                ↓
 Stress Regime   Market Risk  Liquidity   Operational   Book B Standalone
 (v2 §5.3)                     Risk         Risk        Stress (XB-01)
     │               │           │           │                │
     └───────────────┴───────────┼───────────┴────────────────┘
                                 ↓
                   RISK BUDGET = min(all caps)
                                 ↓
                          DECISION ENGINE
                                 │
                           ┌─────┴─────┐
                           │           │
                         TRADE      NO TRADE
                           │     (audit record V3-3.9)
                           ↓
                    COLLATERAL MANAGER
                           │
                  ┌────────┴────────┐
                  ↓                 ↓
          OPTIONS (Book B)     SPOT (Book A)
                  │                 │
                  └──── Spot Leg ───┘
                           ↓
                 LEDGER / DB (per book)
                           │
                           ↓
                     RECONCILIATION
                           │
                           ↓
                      RISK MONITOR
                           │
                     ┌─────┴─────┐
                     ↓           ↓
                  CONTINUE      HALT

40. Production Invariants

ระบบต้อง enforce:

I01: No trade if reconciliation is dirty
I02: No trade if market snapshot is stale
I03: No new trade if liquidity reserve is insufficient
I04: No new trade if margin stress is excessive
I05: No duplicate order
I06: No duplicate transfer
I07: No ETH on wrong wallet
I08: No unresolved spot leg before new option exposure
I09: No trade beyond portfolio exposure limits
I10: No live order before demo acceptance
I11: Every financial movement must have ledger entry
I12: Every position must be reconstructable after restart
I13: (v3) No new option if BB regime is UNKNOWN (stale data or warm-up incomplete)
I14: (v3) No cap above the v2 stress-regime cap; BB and flags can only lower it
I15: (v3) Every option decision, including NO TRADE, must carry a regime audit record
I16: (v3) Book B must pass stress on its own capital; no implicit credit from Book A ETH
I17: (v3) No automatic transfer between Book A and Book B
I18: (v3) Regime is computed from closed 4H bars only

41. Go-Live Checklist

Strategy

• 12–24M backtest
• Bull regime tested
• Bear regime tested
• Sideways tested
• Crash tested
• IV spike tested

Risk

• Dynamic Put utilization
• Portfolio Delta
• Portfolio Gamma/Vega exposure where applicable
• Liquidity stress
• Margin stress
• Max DD
• Recovery time

Two-Book and Regime (v3)

• Ledger แยก Book A / Book B, transfer ข้าม book มี approval
• Book B standalone stress (XB-01)
• BB regime engine: closed-bar, warm-up, stale -> UNKNOWN
• BB values ตรงกับ TradingView (ETHUSDT 4H, BB 200, 2.5) ภายใน tolerance
• Hysteresis ของ cap ทำงาน (ลดทันที / เพิ่มหลัง N แท่ง)
• A/B: filter vs baseline (VAL-01)
• Walk-forward (VAL-03)
• Parameter sensitivity อยู่บน plateau (VAL-04)
• OD-V3-01 ถึง OD-V3-07 ตัดสินแล้ว

Operations

• Demo order
• Demo settlement
• Demo transfer
• Demo spot leg
• Partial fill
• Restart recovery
• API failure
• Reconciliation

Production

• Shadow Live
• 5% capital
• Acceptance criteria met
• 10% capital
• Acceptance criteria met
• 25% capital
• Acceptance criteria met

42. Final Decision Framework

ระบบจะไม่ถาม:

"ETH จะขึ้นหรือลง?"

แต่จะถาม:

1. ETH inventory อยู่ตรงไหน?
2. Grid zone อยู่ตรงไหน?
3. Option premium คุ้มกับ risk หรือไม่?
4. ถ้า ETH crash 30–50% เรามี liquidity พอหรือไม่?
5. ถ้า Put ทั้งหมด ITM เราซื้อ ETH ได้หรือไม่?
6. ถ้า Call ITM เราจ่าย settlement ได้หรือไม่?
7. Binance wallet state ตรงกับ internal ledger หรือไม่?
8. ถ้า exchange/API หาย ระบบจะอยู่รอดหรือไม่?
9. หลัง trade นี้ portfolio risk เพิ่มหรือลด?
10. ถ้าไม่มี trade วันนี้ ระบบยังถือว่าทำงานสำเร็จหรือไม่?
11. (v3) ETH 4H อยู่ใน BB regime ไหน และ cap ของฝั่งนี้ยังเหลือหรือไม่?
12. (v3) Book B รับ worst case ได้ด้วยทุนของตัวเองโดยไม่พึ่ง Book A หรือไม่?

ถ้าคำตอบข้อใดข้อหนึ่งเป็น "ไม่":

NO TRADE / HALT

43. Final Business Objective

เป้าหมายของระบบไม่ใช่:

MAXIMUM PREMIUM

และไม่ใช่:

MAXIMUM ETH

แต่คือ:

                 MAXIMIZE
            Sustainable Cash Flow
                     │
                     │
             under controlled
                     │
                     ↓
             Portfolio Risk
                     │
                     ↓
             while preserving
                     │
                     ↓
                 Liquidity

หรือสั้นที่สุด:

Generate cash flow from ETH inventory without allowing option selling to destroy liquidity.

v3 ปรับประโยคนี้ตาม Two-Book:

Grow ETH in Book A, harvest premium with Book B's own USDT, and size Book B's risk by market regime so a crash cannot drain liquidity.

44. Current Status

45. Recommended Development Order

STEP 1
Freeze current strategy logic
        ↓
STEP 2
Build ledger + reconciliation (แยก Book A / Book B)
        ↓
STEP 3
Build historical simulator
        ↓
STEP 3b (v3)
Build BB regime engine (closed-bar, audit record)
+ run A/B / walk-forward / sensitivity (V3-4)
        ↓
STEP 4
Build crash / liquidity stress engine (รวม Book B standalone)
        ↓
STEP 5
Determine dynamic Put/Call limits
(stress cap x BB multiplier ถ้า STEP 3b ผ่าน)
        ↓
STEP 6
Build state-machine recovery tests
        ↓
STEP 7
Run Binance demo E2E
        ↓
STEP 8
Run Shadow Live
        ↓
STEP 9
5% capital
        ↓
STEP 10
Evaluate 30–60 days
        ↓
STEP 11
Scale only if acceptance criteria pass

46. Bottom Line

Do not add more strategies yet.

The current architecture is already sufficiently sophisticated.

The next value does not come from:

more indicators
more options
more leverage
more AI

It comes from:

better liquidity model
+
better stress testing
+
better accounting
+
better exchange-state handling
+
better production controls

The core hypothesis to prove is:

Can the system repeatedly harvest option premium while maintaining enough liquidity to survive a severe ETH drawdown without forced liquidation or uncontrolled inventory accumulation?

If the answer is yes, this can legitimately be treated as an ETH cash-flow operating model rather than merely an options trading strategy.

If the answer is no, adding more yield-generating strategies will only make the underlying risk harder to see.

v3 addendum. Two-Book does not add a strategy. It changes the accounting so Book B has to survive on its own USDT, which is the constraint Binance already imposes. The BB(200, 2.5) filter is the one new component, and it only lowers risk caps. It stays in the system only if the A/B test in V3-4 shows better Net Cashflow / Max DD than the v2 stress regime alone; if it does not, remove it.