EXPERIMENT TRAIL / 多鏈與交易所內轉對帳
最初想解的問題
付款與帳單核對流程
款項可能來自不同區塊鏈，也可能是幣安／OKX 內轉而沒有鏈上紀錄；收款後仍要辨別它對應哪張帳單。
ORIGIN / 起源
先理解為什麼要開始
功能不是故事的起點；這個實驗先從一個反覆出現的現場問題開始。
當時背景
問題發生在什麼情境？
把四條鏈與交易所內轉放進同一條核對流程，讓商家直接收款後仍能辨別款項對應哪張帳單。
最初假設
我們以為改變什麼會有用？
如果把鏈上交易與交易所內轉分成兩條辨識路徑，再匯入同一份帳本，就能在商家直接收款的前提下核對更多付款情境。
PROCESS / 驗證過程
不是一次做完，而是沿著訊號調整
先看最初設計的驗證路徑，再沿時間線讀每次卡點、改動與結果。
INITIAL TEST PLAN
最初怎麼試
- 01
商家繼續用自己的錢包或交易所帳戶直接收款，系統不代收、不轉付。
- 02
鏈上付款以鏈別、交易編號、金額與帳單付款識別自動核對。
- 03
交易所內轉沒有鏈上紀錄時，改由入帳紀錄與帳單條件走另一條辨識路徑。
BUSINESS EXPERIMENT TIMELINE
事業實驗時間線
先看卡點、做法與結果；需要時再展開完整紀錄。
第一階段：帳單標準化與核對基礎
階段結果已確認卡點帳單格式各自不同做法統一欄位與核對狀態結果同一系統可讀、可追蹤CAUSE / 卡點
為什麼卡住
不同來源的帳單格式不一致，無法穩定進行自動付款核對，也容易出現重複匯入與資料錯配。
ACTION / 做法
這一階段改了什麼
- 統一帳單識別碼、應付金額與匯入來源。
- 建立去重規則、付款狀態與核對狀態。
OUTCOME / 果
目前看到什麼
不同來源的帳單開始能被同一套系統讀取、比對與追蹤，建立後續自動核對的資料基礎。
目前狀態完成基礎帳單結構。
下一步驗證讀取鏈上交易，自動尋找對應帳單。
證據邊界此階段只完成帳單資料標準化，尚未驗證自動付款配對。
第二階段：TRC-20 自動核對與 Payment Slot
已有初步結果卡點同額付款容易誤配做法TRC-20＋付款窗口結果正常交易可自動找帳單為什麼進到這一步帳單先有一致結構，下一步才能用付款窗口縮小交易配對範圍。
CAUSE / 卡點
為什麼卡住
人工提交 TxID 並逐筆確認效率太低；多人也可能在相近時間向同一地址支付相同金額，僅靠地址與金額容易誤配。
ACTION / 做法
這一階段改了什麼
- 建立 TRC-20 交易監測。
- 用 Payment Slot 將帳單、地址、金額、幣種與有效時間綁定。
OUTCOME / 果
目前看到什麼
正常交易可以自動尋找對應帳單；逾時、少付、多付或無法唯一判斷的交易則進入例外處理。
目前狀態完成單鏈自動配對基礎版。
下一步驗證建立 Payment Receipt 與 Ledger，保存完整核對過程並避免重複核銷。
證據邊界此時主要驗證 TRC-20 與付款窗口，例外情境仍需人工處理。
第三階段：Receipt 與 Ledger 基礎版
階段結果已確認卡點已付款狀態無法追溯做法Invoice→Receipt→Ledger結果可重算、不重複核銷為什麼進到這一步自動找到候選交易後，仍需要留下可追溯的付款紀錄與核銷過程。
CAUSE / 卡點
為什麼卡住
只將帳單標記為已付款，無法知道實際對應哪筆交易、收到多少或如何核銷，也無法防止同一筆交易被重複處理。
ACTION / 做法
這一階段改了什麼
- Invoice 保存應付帳單與應付金額；Payment Receipt 保存實際觀測到的付款紀錄。
- Ledger 記錄付款如何被配對、核銷或列為例外，並用冪等機制避免重複入帳。
OUTCOME / 果
目前看到什麼
付款與帳單核對流程形成可追溯、可重算且不會重複核銷的基礎帳本。
目前狀態付款與帳單核對基礎版成立，相關測試曾達到 397/397 通過。
下一步驗證讓不同區塊鏈共用同一套 Payment Receipt、Ledger 與核對規則。
證據邊界此階段證明基礎工程與測試可運作，不代表已完成大規模真實付款驗證。
第四階段：多鏈共用同一套帳本
已有初步結果卡點每條鏈各做一套太重做法四鏈轉成同一格式結果共用同一套帳本為什麼進到這一步帳本基礎成立後，把各鏈差異留在交易讀取層，避免重做整套帳務流程。
CAUSE / 卡點
為什麼卡住
不同使用者可能選擇不同區塊鏈；若每新增一條鏈就重新開發帳單與帳本系統，維護成本會快速增加。
ACTION / 做法
這一階段改了什麼
- 交易讀取層負責 TRC-20、Aptos、ERC-20 與 BSC-20，並轉成標準格式。
- 共同帳務層統一處理 Invoice、Payment Slot、Payment Receipt、Ledger 與 Reconciliation。
OUTCOME / 果
目前看到什麼
確認新增區塊鏈不需要重新製作整套帳務系統，只需增加對應的交易讀取能力。
目前狀態TRC-20 與 Aptos 完成初步驗證；ERC-20 改用 Infura，BSC-20 持續接入與測試。
下一步驗證處理沒有公開鏈上交易紀錄的交易所內轉。
證據邊界此時多鏈架構已成立，但各鏈的驗證程度並不完全相同。
第五階段：鏈上與交易所內轉雙軌對帳
目前階段已有初步結果卡點交易所內轉沒有 TxID做法鏈上／內轉雙軌辨識結果四鏈與兩家交易所有初步結果為什麼進到這一步四鏈共用帳本後，再補上沒有一般鏈上交易紀錄的交易所內轉辨識路徑。
CAUSE / 卡點
為什麼卡住
付款不一定透過公開區塊鏈交易，也可能透過幣安或 OKX 內轉完成；這類付款沒有一般鏈上 TxID，無法沿用原本的鏈上監測方式。
ACTION / 做法
這一階段改了什麼
- 鏈上付款依據鏈別、交易編號、地址、金額、時間與付款識別進行核對。
- 交易所內轉依據入帳紀錄、金額、時間與帳單條件進行辨識；兩條路徑都轉成 Payment Receipt 並匯入同一套 Ledger。
OUTCOME / 果
目前看到什麼
TRC-20、Aptos、ERC-20 與 BSC-20 已成功識別；幣安與 OKX 內轉且沒有一般鏈上紀錄的情境，也取得初步自動辨別成果。
目前狀態基礎版已完成，目前持續驗證不同交易所紀錄與例外付款。
下一步驗證測試誤配、重複入帳、金額不一致、逾時付款、相同金額與不同交易所紀錄格式，確認哪些情況可自動完成、哪些必須轉人工檢查。
證據邊界目前只確認四條鏈與幣安、OKX 內轉的初步結果，尚未證明所有交易所、幣種與例外情境都能可靠處理。
RESULT / 結果
目前有訊號，但答案還沒有定案
進行中的實驗會保留不確定性，讓下一個行動有清楚依據。
OBSERVATION / 目前訊號
到目前為止，看到了什麼？
TRC-20、Aptos、ERC-20 與 BSC-20 已成功識別；幣安／OKX 內轉且鏈上沒有紀錄的情境，也已取得初步自動辨別成果。
目前判斷
維持小範圍驗證，不把初步結果當成完成；下一輪測試會決定要放大、調整或停止。
下一個驗證
繼續測試誤配、重複入帳、金額不一致與不同交易所紀錄格式，確認何時必須轉人工檢查。
用一個更小、可觀察的動作取得下一個訊號。
VISITOR RESONANCE / 訪客共鳴
這個問題，你也遇過嗎？
這不是一般按讚；每一筆都要補上真實情況，幫助判斷需求是否存在。
正在讀取共鳴紀錄…