代幣遷移已完成，但新代幣沒有出現在錢包裡

2026-09-03

你已經給兌換合約授權、發出了舊代幣餘額，瀏覽器上那筆交易也標成了綠色。舊的代幣符號消失了，卻沒有任何東西補上它的位置。要麼新的單位根本不存在，要麼它們存在、只是沒有任何東西把它們畫出來。這兩種情況在錢包介面上看起來一模一樣，需要的應對卻完全不同。

一筆完成的兌換到底證明了什麼

一筆已確認的兌換交易告訴你的是：你的調用進了區塊，且最外層那段執行沒有回滾。就這些。成功的回執狀態是關於這次調用的陳述，不是這次調用給你記了什麼的清單。

遷移兌換有兩條腿，這也是這個落差在這裡格外要緊的原因。一條腿把你的舊單位劃走，另一條把新單位付回來。回執覆蓋的是整筆交易，而合約可以被寫成：第二條腿做得比你預期的少，甚至什麼都不做，而第一條腿並不因此撤銷。

所以要回答的問題不是兌換成沒成功，而是新餘額現在是否已經記在你的地址名下；如果記了，為什麼沒有東西把它畫出來。這是兩次獨立的排查，按這個順序做，可以省下就一筆你其實已經持有的餘額去和客服爭論的功夫。

新餘額到底記在哪裡

新代幣是一個有自己帳本的普通合約，ERC-20 代幣標準把你的持倉記了兩遍：一遍是入帳那一刻的事件，一遍是合約在被問到時會回答的數值。

事件就是 Transfer 事件。標準說，代幣發生轉移時必須觸發它，包括零值轉移。標準還說，創建新代幣的代幣合約應當觸發一個 Transfer 事件，並把發送方地址設為 0x0。因此，向你的地址增發的遷移會留下一條從零地址到你的轉移記錄，而從預存儲備中支付的遷移會留下一條從該儲備出發的轉移記錄。兩種情況下都有一行可查。

數值就是 balanceOf。標準把它描述為返回另一個帳戶按給定持有者地址的帳戶餘額。它是一次讀取，不花錢，回答的是此刻而不是兌換那一刻。在區塊瀏覽器上打開新合約，用你自己的地址調用 balanceOf，它返回的數字就是權威答案。

你能讀到什麼	它能說明什麼
兌換交易的回執狀態	只說明最外層調用沒有回滾
一條指向你地址的轉移事件	說明當時確實給你記了新單位
新合約上的 balanceOf 讀數	說明你此刻在那本帳裡持有多少
錢包的資產列表	關於所有權什麼也說明不了

為什麼餘額是你的、錢包卻什麼都不顯示

最後一行解決的是這件事裡修起來不花錢的那一種。錢包不會為你的地址去掃描鏈上每一個合約，它畫的是一份被告知要跟蹤的資產列表，而上週才部署的合約在有人把它放進去之前不在那份列表裡。

這是一個已知的空缺，不是故障。EIP-747 是 wallet_watchAsset 方法背後的標準，它把該方法描述為允許客戶端向用戶的錢包建議一個要跟蹤的代幣，並寫明：沒有它，每個錢包要麼需要預載入一份已批准資產清單，要麼用戶必須手動把資產添加到錢包裡。遷移產生的正是這種情形。

修法是手動添加該合約，地址要取自項目自己的公告，而不是搜索結果或聊天訊息。錢包一旦開始跟蹤它，如果餘額本來就在，就會立刻顯示出來，因為你的持倉什麼也沒變。如果讀數仍然是零，顯示問題就被排除了，剩下的全在鏈上。

當兌換記給了一個不是你的地址

兌換合約必須決定付給誰，而那個地址不總是你心裡想的那個。如果合約把新單位記給調用者，那麼簽名的那個帳戶就是收到的那個帳戶；當同一個瀏覽器配置檔案裡開著兩個帳戶時，那可能就是錯的那個。

更麻煩的一種牽涉到中間方。放在中心化平台上的舊單位坐落在該平台的地址上，從充值地址發出的兌換會付給該地址的歸屬方。智能合約錢包或多簽也是同理。去讀那條轉移事件，注意它的接收方欄位：它指名了被記帳的地址；如果那不是你的地址之一，這些代幣本來就不會出現在你正在看的地方。

有一種純事務性的情況值得先排除。有些遷移把新代幣發在與舊代幣不同的鏈上，於是入帳落在一條你的錢包沒有指向的網絡上。切換網絡幾秒鐘就能解決。

當舊單位劃走了、卻什麼也沒回來

如果轉移事件不存在、新合約上的 balanceOf 讀數為零，而舊餘額確實已經不見了，那就是支付這條腿沒有跑起來，原因不多。

第一種是儲備被清空。以預存代幣支付而不是增發的兌換，可以接受你的存入卻付不出來，因為它支付所用的帳戶已經被清空。這正是兌換窗口期限要防的那種失敗，也是為什麼發出之前先讀儲備比讀公告更要緊。

第二種是到帳數額比預期小，而不是沒有。在斷定什麼都沒到之前，先核對兌換比例和兩個合約的小數位。一個持有 40,000 個舊單位的錢包，按每四個舊單位換一個新單位歸併，應得 10,000 個新單位，也就是它習慣看到的那個數字的 25%。在小數位不同的新合約上，一次正確的入帳也可能把小數點渲染在一個陌生的位置上。

第三種是舊單位去了一個沒有掛支付腿的地方。把代幣直接發到合約地址、而不是通過那個負責調用它的介面，並不會觸發兌換。標準之所以讓這成為可能，是因為 approve 允許一個支出方從你的帳戶中最多支取一個設定的額度，而 transferFrom 用於一種支取工作流，讓合約代表你轉移代幣。兌換合約期待的是從你這裡拉走，而不是被塞給一個它從未被告知的東西。

平台替你的帳戶跑的遷移

另一條路徑會產生同樣的抱怨，原因卻完全不同。如果遷移期間你把舊代幣放在中心化平台上，平台會兌換自己的池內餘額並改寫你的帳戶條目，整件事表現為一次代幣符號變更，沒有任何屬於你的交易掛在上面。

在這條路徑上沒有兌換交易可查，所以那些鏈上檢查一條都用不上。真正適用的是該平台自己的時間表：舊代幣的充提暫停、對帳戶餘額施加的兌換、以及以新符號恢復。在暫停期間尚未被兌換的餘額是被暫停了，不是丟了。

這兩條路徑的升級路線也不同。沒有給你入帳的平台是一個有具名對手方可以回答的客服問題。而沒有付款的鏈上兌換在環節裡沒有對手方，因為合約執行的就是被寫進去的東西。

按順序要查的幾件事

順序	查什麼	否定的答案排除了什麼
1	你的錢包是否在新代幣發行所在的網絡上	鏈選錯造成的顯示問題
2	你是否手動添加了新合約地址	錢包沒有跟蹤新合約
3	balanceOf 是否對你的地址給出答案	剩下的一切顯示層解釋
4	兌換是否帶著一條指向你的轉移事件	已經入帳、之後又被轉走
5	那條事件指名的是哪個地址	付到了充值地址
6	比例與小數位是否與到帳數額相符	把正確的入帳讀成了錯的
7	是否有平台替你跑了遷移	一條從頭就不適用的鏈上路徑

順著這份清單往下走，不要橫著走。每一行排除掉一類解釋，而下面幾行只有在上面幾行落定之後才講得通。前三行不花錢。

整件事還附帶一條警告。一個看起來丟了餘額的錢包，正是冒充者盯著的狀態，而上面每一項檢查都是你自己免費就能做的公開讀取。沒有人需要你的助記詞來讀一個餘額；任何以此換取找回丟失遷移代幣的提議，都是把第二次損失包裝成對第一次損失的修復。

小結

一筆綠色的兌換交易證明的是一次調用執行過了，僅此而已。新餘額記在新合約上：入帳那一刻是一條轉移事件，之後是一個 balanceOf 讀數，這兩樣你不用問任何人就能讀到。在讀到它們之前，你並不知道這是顯示問題還是支付問題。

如果是顯示問題，流程很短：切到正確的網絡，手動添加合約地址，餘額其實早就在那裡了。如果不是，那條轉移事件指名了真正被記帳的地址，而這個欄位把付給了錯誤帳戶和根本沒有付出這兩件事分了開來。在你再往任何地方發送任何東西之前，先弄清你面對的是這兩者中的哪一個。想繼續打好這些基礎，請追蹤 Bitbase（幣貝）學院的更多內容。