Solana 交易簽名查不到：Blockhash、Commitment 與 Finalization

「簽名完成」不等於 RPC 一定查得到

Solana 交易在送出前由帳戶簽名。錢包可以先產生 signature，再嘗試送往 RPC；如果網路中斷、RPC拒絕、模擬失敗或 recent blockhash過期，使用者可能看見本地紀錄，公共 RPC卻沒有可回傳的交易。

所以 signature查不到時，先判斷交易是否真正廣播，不要直接把它歸類為鏈上 failed。鏈上失敗通常仍能透過 getTransaction 看到交易與 meta error；完全查無則可能更早就停止。

第一關：signature、地址與 cluster

Solana地址、交易 signature與 blockhash都可能以 Base58顯示，長度和用途不同。從錢包的交易詳情複製 signature，不要從帳戶頁複製地址，也不要使用畫面中帶省略號的縮寫。

再確認 cluster。mainnet、devnet與 testnet是不同資料集合；測試網路 signature不會出現在主網瀏覽器。若使用自訂 RPC，也要核對它連接的 genesis與 cluster，而不是只看網址名稱。

第二關：commitment 與 RPC 可用性

getTransaction允許指定 commitment。資料源可能因尚未達要求層級、歷史保留策略或節點落後而回傳 null。使用另一個同 cluster的可信 RPC或瀏覽器交叉驗證，有助於區分單一資料源問題。

不要把降低 commitment誤解成改變交易結果。它只改變你願意接受的觀察層級；真正的 finalized狀態仍由叢集進度決定。

第三關：recent blockhash 是否仍有效

交易訊息包含 recent blockhash，讓驗證者判斷交易是否太舊。RPC提供 isBlockhashValid之類的方法檢查某個 blockhash在指定 commitment是否仍有效。若已失效，舊交易不能靠長期等待恢復；錢包需要取得新 blockhash、重建訊息並再次讓使用者簽名。

重新簽名應被視為新交易流程：

1. 重新核對收款地址、mint、金額與指令。
2. 確認舊交易沒有在其他資料源落地，避免重複付款。
3. 取得新的 recent blockhash。
4. 查看模擬與費用付款帳戶。
5. 在可信錢包內簽名並保存新 signature。

查到交易後看 meta，而不只看外框

getTransaction結果包括區塊位置、訊息與 meta。meta中的 error可表明指令執行失敗；token balances和 log messages則有助於確認哪個程式、mint與帳戶發生變化。

結果	解讀	下一步
多個同 cluster資料源都查無	可能未廣播或已過期	回錢包查看廣播回應與 blockhash
低 commitment可查，高 commitment不可查	尚未達較高層級或資料源差異	觀察進度並交叉驗證
可查且 meta error存在	已上鏈但指令失敗	分析 log與程式條件，不照舊重送
可查且成功	鏈上完成	核對 owner、mint、數量與接收端入帳

避免把排錯變成授權風險

查 signature 只使用公開字串；檢查 blockhash 也只依公開資料。seed、私鑰、錢包備份與遠端控制一律不屬於查詢資料；任何「修復簽名」網站若要求匯入助記詞，應立即停止。

若交易由平台提領，使用者可能看不到原始 blockhash或廣播回應。此時保存平台訂單號與 signature，向發送平台官方支援詢問是否已廣播、是否已重建交易；不要自行猜測並向接收地址重複付款。

Signature 與平台訂單號如何區分？

Solana signature 是交易的鏈上識別值；平台提款單號、錢包請求 ID 或應用訂單號只在各自系統中使用。從原始活動頁面找標為 signature 或 transaction 的完整字串，不要從圖片手打。若服務沒有提供，詢問是否已向 Solana 網路提交以及實際 signature 是什麼。

查詢時移除空格和標籤，使用可信 Solana 資料來源。不同 RPC 的歷史保留與索引可能不同，可用官方方法或多個可靠來源交叉查證，但不要把查無結果自動解釋成「驗證者扣住交易」。

Recent blockhash 過期時為何可能沒有永久交易？

Solana 交易引用 recent blockhash，只有有限有效窗口。簽名後若 RPC 未及時傳播、網路擁塞或應用延遲提交，blockhash 可能失效。交易就不能按原訊息被處理，原 signature 也可能不出現在歷史交易查詢中。

重新操作會使用新 blockhash 並產生新 signature。重簽前先確認原收款方沒有收到資產、錢包活動中沒有替代 signature，避免因介面逾時造成雙付。商戶訂單應把每個候選 signature 都綁定同一付款意圖。

找得到 Signature 但顯示錯誤怎麼辦？

這已不是「找不到」問題。讀取 err、log messages、涉及程式、帳戶前後餘額與 fee。錯誤可能是帳戶不存在、mint 不符、計算資源不足、程式條件拒絕或 blockhash 問題。提高 priority fee 只影響排程，不能修復錯誤帳戶與指令。

查詢結果	可推論	下一步
完全無紀錄	未證明鏈上處理	查提交/RPC/blockhash 與新 signature
有紀錄且 err	指令執行失敗	讀 logs，確認資產是否未移動
成功	鏈上內容已執行	核對接收帳戶、mint、平台入帳
只在錢包顯示 pending	本地狀態可能過時	以公開查詢和餘額變化交叉核對

RPC 問題與真正鏈上結果如何分開？

單一 RPC 逾時、落後或限制歷史查詢，會讓應用暫時看不到交易；這不等於全網沒有紀錄。比較最新 slot、高度與多個可信來源，確認資料服務的同步狀態。助記詞絕不可搭配陌生人給的私有 RPC 使用；RPC 查詢只使用公開地址或 signature。

若自建或開發應用，保存送出時的 RPC 回覆、signature、blockhash 與 last valid block height，才能分辨提交被拒、已提交未確認或過期。一般使用者則保存錢包通知與時間，交由官方支援核對。

Signature、地址、mint 與 blockhash 要分開辨認

Solana 介面會同時出現多種 Base58 字串。Signature 識別一筆已簽訊息，錢包地址識別 owner 或帳戶，mint 識別 token，blockhash 則限制訊息有效期。把地址貼進 signature 搜尋框，或拿平台訂單號去瀏覽器查，都會得到空白，卻不能證明付款沒有建立。

複製時保留完整字串與來源欄位。聊天軟體可能折行或截短，截圖也不利於逐字核對。平台提領至少要同時保存內部單號與公開 signature；前者用於平台客服，後者才用於鏈上查詢。

錢包顯示已送出，但 RPC 從未接受時會怎樣？

錢包可能在本地簽名後先建立活動紀錄，再把序列化交易送給 RPC。網路中斷、節點拒絕、simulation 失敗或 blockhash 過期，都可能讓訊息未形成可長期查詢的鏈上結果。此時要讀錢包錯誤與 RPC 回覆，而不是假設 signature 必定已進入全網。

如果要重送，先確認原 signature 在多個同步來源都沒有成功結果，並重新取得 recent blockhash。新交易會產生新 signature；兩筆都要保留。支付系統還應使用唯一訂單狀態阻止使用者連按送出造成多筆有效付款。

null、錯誤與歷史裁剪不是同一種結果

RPC 回傳 null 可能表示節點尚未見到、查詢參數或 cluster 錯誤、節點不保留足夠歷史，或交易從未被接受。若 signature 可查但 meta 中有 err，則交易已進入鏈上紀錄但執行失敗；這時應讀 log、fee、pre/post balances，而不是繼續問「為何找不到」。

對較舊交易，使用保留歷史資料的可信瀏覽器或 archival 服務，並核對主網。不要因一個免費 RPC 不保存舊 slot 就付費給陌生「恢復節點」。公開 signature 查詢不需要錢包連線。

Commitment 不同會如何影響查詢？

Processed、confirmed、finalized 代表不同確認程度。較高 commitment 的查詢可能暫時看不到剛處理的交易，但這只是資料門檻差異；先在較低層找到交易，再追蹤它是否提升。若交易曾 processed 後消失，記錄 slot 與節點來源，檢查是否落在未保留的分支。

平台若要求 finalized，鏈上 confirmed 並不等於平台違約。工單應寫明目前 commitment、首次出現時間與平台規則；避免只用「成功」一詞混合不同終局程度。

Token 轉帳還要核對哪些帳戶？

找到 signature 後，確認目標 owner、目的 token account、mint、數量與實際 balance 變化。Associated token account 可能在交易中建立，外層帳戶列表不一定直接顯示使用者熟悉的主地址。只看到成功狀態而沒有預期 mint 的變化，不能向收款人宣稱 token 已到。

假 token 可以複製名稱與符號。對平台充值，mint 必須在其支援清單；對個人收款，雙方應事先書面確認 mint。若錯 mint 已成功轉入，這是資產識別問題，不是 signature 查詢問題。

開發端應保存什麼可觀測資料？

保存交易訊息摘要、signature、blockhash、last valid block height、送往哪個 RPC、sendTransaction 回覆、simulation 結果與後續 status 查詢。不要把私鑰、完整助記詞或登入 token 寫進日誌。這組資料足以區分簽名成功、提交失敗、節點接受但未確認、執行失敗與最終成功。

重試策略應在 blockhash 有效期與冪等業務鍵之間協調。單純每隔幾秒建立新交易會改 signature，讓付款與訂單失去一對一關係，也增加雙付風險。

官方支援案件怎樣描述才容易處理？

提供完整 signature、主網、錢包或平台版本、建立時間區間、目的地址、mint、金額、所有可信查詢來源及錯誤原文。若有新 signature，明確列出新舊關係和哪一筆被收款方確認。不要只說「哈希不見了」，也不要把瀏覽器搜尋結果截圖當唯一證據。

任何支援若要求助記詞、私鑰、遠端控制或向指定地址支付「節點同步費」，都超出正常查詢範圍。停止聯絡，從官方 App 或親自輸入的網域重新開案。

Durable nonce 與一般 recent blockhash 怎樣區分？

多數一般交易使用 recent blockhash 並受 last valid block height 限制；某些進階流程使用 durable nonce account，生命週期與重送判斷不同。不要看到舊簽名仍可被某介面引用，就假設它一定是 durable nonce。查看交易訊息、錢包或應用文件，確認使用的機制，再決定是否過期。

如果不了解 nonce account 的控制權，不要照陌生教學手動 advance 或關閉。這可能影響尚待簽署的交易，尤其在離線簽名或多簽流程中。

與收款人確認時，不能只問「有沒有看到」

請對方核對預期 owner、mint、數量與相應 signature，並說明錢包是否只是不顯示 token。若是平台，提供充值網路、地址與帳戶工單；平台內部入帳延遲不能由 Solana RPC 修復。雙方共享公開資料即可，不需要任何一方傳送 seed。

若最後使用新 signature 完成付款，書面註明舊 signature 未形成有效結果或已失敗，避免收款方日後將兩筆都列為應收。

對行動錢包的本地活動紀錄要保持什麼警覺？

App 可能在廣播前建立本地項目，也可能因快取暫時保留過期交易。更新或重裝前保存必要的 signature、錯誤與時間，但不要只靠本地列表判斷鏈上結果。可信瀏覽器與同步 RPC 才能提供公開可重現證據。

若清除快取後紀錄消失，這不會改變鏈上已確認交易；反過來，本地項目仍在也不能讓未廣播交易生效。把介面狀態與共識結果分開，是避免重送的關鍵。

平台批次提領時，為什麼內部狀態可能先完成？

平台可以先完成帳戶扣款、風控或批次排程，稍後才建立並廣播 Solana transaction。介面寫 Completed 可能是內部工作流，不一定等於公開 signature 已存在。向平台索取實際主網 signature 和接收地址，沒有它時接收方無法在鏈上查款。

平台若重新組批次，可能提供新的 signature。核對新交易中是否包含自己的 owner、mint 和數量，並保存舊單號關係。不要拿批次中的其他 token account 當成自己的款項。

Blockhash 過期後重新簽名，怎樣防止雙付？

先在多個可信來源查原 signature 與預期接收地址，再確認原訊息的 last valid block height 已經過去且沒有成功結果。重新取得 blockhash 後，新交易會有新 signature；業務系統必須用同一訂單鍵標記它是替代嘗試，而不是第二筆應付款。

若原交易稍後出現成功證據，立即停止重試並與收款方核對。不要以為不同 signature 就一定代表只有一筆能生效，因為使用新 blockhash 的兩筆獨立轉帳都可能有效。

交易找到後，怎樣確認沒有只完成 fee payment？

查看 transaction meta 的錯誤、SOL pre/post balances、token balance 變化、program log 與實際指令。Fee payer 支付費用不代表 token transfer 成功；某個前置指令成功也不代表全部操作完成。對平台充值，最終還要核對目的 owner、token account、mint、數量與 commitment。

如果只有 fee 減少而預期資產沒有變化，把案件分類為執行失敗，不要要求接收方按成功款入帳。保存 log 與錯誤，讓錢包或 DApp 支援能重現。

事件關閉後要更新哪些重試規則？

記錄造成查不到的實際原因：錯 cluster、錯識別碼、RPC 落後、提交被拒、blockhash 過期或平台未廣播。針對原因更新流程，例如保存 sendTransaction 回覆、限制重試次數、以 last valid block height 決策、將內部單號與 signature 分欄。不要只加一個更長等待時間掩蓋根因。

同時保留安全邊界：所有查詢只用公開資料，任何重簽都在可信錢包核對 owner、mint、數量和 fee payer，永不把 seed 交給「節點工程師」。