KGEX 是什麼
KGEX 是 KryptoGO 的保管核心系統：替客戶保管鏈上資產、記客戶的帳、處理入金、出金與公司資產調度，並定期驗證客戶池的鏈上資產是否足以覆蓋對客戶的負債。 第一階段不含交易市場。這一段先講範圍、設計原則和 GCP 上的實作。
01 · 範圍
第一階段只做交易所的資金層
範圍是錢包、帳本、出入金、站內轉帳、對帳，以及支撐它們的客戶身份、員工權限與核准。交易與法幣不在範圍內；法遵／風險以決策接口接入（allow／review／reject／freeze），詳細規則與阻擋點待確認。
上面三層不在這套設計裡。分層是本文的示意，不是原文的架構分層。點每一層看說明。
01 · 範圍
資金層的四個部分
資產分成四個池子（未歸集的入金地址也算客戶資產），帳只記對客戶的負債，資金移動由狀態機推進，對帳則逐鏈對齊截止區塊後，按同一種資產合計比較資產是否 ≥ 負債。每一部分對應下面的一個互動區。
01 · 範圍
客戶資產與公司資產分開保管，只開公司 → 客戶一個方向
不同錢包、不同白名單、不同權限（簽署人可以相同，共用的風險待確認）。公司熱錢包補流動性給客戶池要核准，完成後那筆錢即歸入客戶資產；反方向預設禁止，第一階段不提供一般流程，後台也不顯示。
資金歸屬單向，客戶資產覆蓋的計算才算得清。
看每個方向經過哪些控制層
往冷端收是自動的，往熱端放要核准，從冷錢包出款再加一次鏈上 3-of-5 簽名，三道各自計票；客戶 → 公司預設禁止。
02 · 設計的三層
本文把設計分三類：不變量、實作、政策與配置
03 · 原則一
餘額可以快取，帳務真相只來自分錄
餘額存著是為了查得快，但它只是不可變分錄的投影；分錄、平衡檢查與投影在同一個 DB transaction 更新，同一個 idempotency key 不會產生第二次經濟效果。每一筆帳只做一件事：增加負債、減少負債、或把錢在可用與鎖定之間搬動。右邊是同一個客戶的四筆帳，第四筆刻意走進一個尚未決定的情況。
記錯了不改舊帳，再加一筆沖銷。
04 · 原則二
鏈上事實只認自己的 indexer
託管商回報「成功」不算成功，託管商回報的餘額不算資產。鏈上發生了什麼，只認自己掃鏈的結果；託管商的回報用來追蹤提交進度。
DB 跟託管商、鏈不可能一起原子提交，所以先保存意圖，再用證據收斂結果。
05 · 原則三
三種控制各自判定，但不是每筆都過三道
公司內部多人核准（是否允許這項操作）、託管商的規則引擎（放行、擋下或要求二次人工）、冷錢包鏈上多簽（鏈上授權）。三者不能互相抵算，且必須指向同一份內容。核准綁的是內容：送審後內容鎖定，要改就取消重提；申請人不能核准自己的申請；執行前再核對一次前提，避免核准的是甲、執行的是乙。哪種資金移動過哪幾道：
| 這筆錢 | 公司核准 | 託管商引擎 | 鏈上多簽 |
|---|---|---|---|
| 客戶出金・小額 | — | ✓ | — |
| 客戶出金・大額 | ✓ 超過門檻（初始建議 3000U） | ✓ 超過更高門檻（初始建議 10000U）再人工 | — |
| 公司熱錢包補錢給客戶熱錢包 | ✓ | ✓ | — |
| 熱 → 冷（歸集） | — | ✓ 白名單內 | — |
| 冷錢包往外搬 | ✓ | — | ✓ 3-of-5 |
| 站內轉帳 仍受暫扣額度限制 | — | — | — |
06 · 實作
GCP 架構
一個 modular monolith：業務邊界靠資料歸屬與 command 維持，執行程序只依長時間工作、擴展需求與密鑰權限拆開。四個 workload、CronJobs、兩條訊息通道；每一塊標了它對應上面哪條不變量。
07 · 入金政策
confirmed 就能用，finalized 才能提
入金一到 confirmed 就入帳、可站內使用；同時在帳戶上掛一個等值的出金額度限制，finalized 才解除。這是第一階段的政策，跟記帳原則分開評估。
中間不是鎖住那筆幣，是掛一個 BTC 計價的暫扣額度在整個帳戶上。原因：入金一 confirmed 就能換成別的幣，鎖那筆幣鎖不住；換成統一單位掛在整個帳戶，限制才跟著錢走。用 BTC 計價、以入帳當下的估值固定不變，是政策選擇。右邊按四步看它怎麼算。
它需要價格：入帳取一次、出金取一次（portfolio 與所選資產用同一份快照）。價格來源、取價時間、rounding、fallback 尚未決定。站內轉帳也套同一檢查，否則可以透過收款人繞過。