Pending、Confirmed、Failed 與 Dropped 代表什麼？

狀態詞是介面摘要，不是跨鏈標準

不同區塊鏈、RPC、錢包和平台會使用相似字詞描述不同精度的狀態。pending 在某錢包可能表示已簽名但尚未廣播，在另一個資料源則表示節點 mempool 已收到。confirmed 也可能指已進一個區塊、達到某種共識門檻，或只是平台內部已接受。

因此排錯不能只截一個綠點或黃點。至少要知道狀態由誰產生、對應哪條鏈、是否有 TxID，以及底層區塊或 receipt 欄位。

常見狀態的實用解讀

Created/Signed

錢包已建立或簽署交易，不一定已送到節點。若沒有可查 TxID，先確認 RPC 連線與廣播回應。Solana 交易若延遲廣播，recent blockhash 還可能過期。

Submitted/Broadcast

發送端表示已嘗試送出。它比 signed 多一個網路動作，仍不等於節點長期保留或區塊已收錄。用 TxID 在正確鏈的資料源核對。

Pending/Unconfirmed

交易尚未達到穩定確認。Ethereum 類交易可受 nonce 與費率影響；Bitcoin 交易可能在 mempool 等待；不同節點看到的候選集合不一定完全一致。

Confirmed/Success

交易已被鏈上處理到某個確認層級。EVM 還應分辨 receipt status：進入區塊不等於合約執行成功。代幣轉帳要核對事件或餘額變化，而不是只看外層交易存在。

Failed/Reverted

交易可能已入塊但執行失敗，也可能在送出前被錢包拒絕。前者通常有鏈上 receipt 且可能已消耗費用；後者可能沒有鏈上紀錄。查看錯誤來自哪一層。

Dropped/Replaced/Expired

dropped 常表示某資料源不再保留候選交易；replaced 表示同一 nonce 或輸入出現另一筆交易；expired 在 Solana 等流程可能與有效 blockhash 時限有關。它們不應被統一翻譯成「資產消失」。

Finalized

某些鏈用 finalized 表示比一般 confirmed 更強的最終性。Solana commitment 就明確區分 processed、confirmed 與 finalized。平台仍可能在 finalized 後才進行自己的入帳程序。

三層狀態表

層級	典型問題	可用證據
發送服務	是否批准、簽名、排入提領佇列	平台訂單、錢包本地紀錄
區塊鏈	是否廣播、入塊、執行成功、確認程度	TxID、區塊、receipt、事件
接收服務	是否辨認、達門檻、分配到帳戶	存款狀態、官方工單

同一筆交易可以同時呈現「鏈上 success」和「平台 processing」，因為它們描述不同層。把三層拆開，就不會因兩個介面文字不一致而誤判。

一個不依賴顏色的排查句型

用完整句子記錄：「發送平台在 13:20 顯示 completed，提供 TxID X；TRON 瀏覽器顯示交易於區塊 Y 成功；接收平台仍顯示 waiting for confirmations。」這種描述比「一直黃燈」更容易讓自己與客服找到責任邊界。

如果沒有 TxID，就問發送端是否已廣播。如果有 TxID但鏈上 failed，就查失敗原因與資產是否仍在原地址。如果鏈上 success卻未入帳，就核對接收端支援、確認、合約與 Memo/Tag。

任何狀態都不需要把私鑰、助記詞或一次性驗證碼交給查詢工具。狀態證據應來自公開鏈上資料和官方帳戶紀錄。

同一筆交易為何會同時出現三種狀態？

錢包、區塊鏈與平台各自描述不同階段。錢包的「已送出」可能只表示已簽名並提交給節點；區塊瀏覽器的 success 表示鏈上執行結果；平台的 credited 則表示內部帳戶完成入帳。三者時間不同並不矛盾，也不能用其中一個替代另外兩個。

排錯時先標註狀態來源。例如寫「發送平台：completed；Ethereum receipt：success；接收平台：未入帳」，比只寫「交易完成了」更能定位責任邊界。

Pending、Success、Failed 分別能推論什麼？

鏈上狀態	能確認的事	還不能確認的事
找不到	尚無該資料來源可見交易	是否從未廣播或在別鏈
Pending	節點或 mempool 已知交易	最終是否被打包、替換或失敗
Success	交易按該鏈規則執行成功	平台是否已對帳、代幣是否為預期合約
Failed / reverted	預期狀態變更未完成	平台內部餘額是否已恢復

EVM 交易還要看 receipt 與 log。原生 value、代幣 Transfer 事件和合約內部呼叫可能呈現不同資訊；不能只憑頁面最上方的一個綠色圖示判斷所有資產流向。

「確認中」什麼時候屬於正常等待？

先確認交易在正確鏈、沒有被替換、確認數持續增加，再比較接收端公開門檻。若差距合理，等待比反覆提交相同交易安全。若確認數已超過要求但平台仍無入帳，應查最低金額、Memo/Tag、代幣合約與維護公告。

對 Bitcoin，未確認可能與 fee rate 和 mempool 有關；對 Solana，signature 可能因 blockhash 過期而沒有形成可查交易；不同鏈不應硬套相同的「pending」解法。

平台顯示 Completed，鏈上卻查不到怎麼辦？

先區分內部訂單完成與公鏈廣播。向發送平台索取完整 TxID 和實際網路，保存提款單號與時間。沒有 TxID 時，接收方無法用鏈上證據查充值，第三方也無法靠「節點工具」創造交易。

若平台給出的 TxID 對應另一個地址、數量或時間，將差異回報發送平台；不要拿不相關交易向接收方要求入帳。批次提款可能包含多個輸出，應鎖定自己的接收事件。

狀態改變時，哪些欄位必須一起更新？

不要只把 Pending 改寫成 Success。案件表應同時記錄查詢來源、區塊高度、確認數、receipt 結果、實際接收地址、資產合約與平台訂單狀態。這些欄位回答的是不同問題：鏈是否接受、合約是否成功、資產是否真的轉移，以及託管平台是否完成帳務。任何一欄缺失，都可能讓同一個綠色標籤被過度解讀。

若交易被 replaced，保存原 TxID 和替代 TxID 的關係；若是 dropped 或 expired，記錄錢包是否建立了新交易。這能防止客服只查舊識別碼，也避免使用者把兩筆互相衝突的交易當成兩次扣款。

給收款人的狀態說明應該怎麼寫？

用可核驗句子取代「系統卡住了」。例如：「交易已在 Ethereum 廣播，TxID 可查，目前仍未產生成功 receipt」；或「鏈上 Transfer 已成功，接收平台尚未把款項記入帳戶」。這種寫法讓對方知道應等待哪一層，也不會對尚未成立的結果作保證。涉及付款爭議時，同時保留原始報價、發票或聊天約定，因為鏈上狀態不會自動證明交易雙方的商業義務已全部履行。

結案時再寫一個最終狀態：被哪個區塊確認、是否由替代交易完成、合約是否成功、平台何時入帳。若仍有未知，就明確保留未知，不用單一顏色或「Completed」掩蓋。這種紀錄能在退款、重送或會計對帳時避免把同一事件計算兩次。