項目方換到新合約，你打開遷移頁面，一枚代幣都還沒動，錢包就先要你給舊代幣授權。這個彈窗看上去像是誰多加的一步。它不是。在 ERC-20 裡，把餘額交到你自己以外的任何對象手上，只有這一條路徑；能不能讀懂它，是一次遷移與一個被掏空的錢包之間的分界。
這份授權到底給出了什麼
授權是往舊代幣合約內部的一張帳上寫一個數。它針對一對地址記錄一件事：某個具名的支出方可以從你的帳戶裡轉走多少這種代幣。簽下它不轉移任何東西，不向項目方發送任何東西，也不構成任何兌換承諾。
在 ERC-20 代幣標準裡，這張帳透過兩個函數存取。`approve` 允許支出方從你的帳戶裡反覆提取，直至一個設定的額度；`transferFrom` 才是真正把代幣從一個地址移到另一個地址的呼叫。標準把這一對呈現為一套提取流程，讓合約代表你轉移代幣，而遷移合約只是這類合約中的一個，沒有任何特殊地位。
這條記錄存在哪裡，比聽上去更要緊。額度記在舊代幣裡，不在遷移合約裡，所以它比遷移頁面、比這次兌換、也比項目本身活得久。關掉分頁不會清掉它。
兌換合約為什麼必須問
兌換必須先接管舊單位，才能給你記上新單位。合約無法自行伸手進你的帳戶，而關於你的餘額，代幣合約只聽持有它的那個帳戶。
看起來的替代做法，是你自己用一次普通轉帳把舊代幣發給合約。那確實轉移了代幣，也確實會失敗：普通轉帳到帳時不帶任何呼叫，合約根本不知道這筆轉帳發生過，也就沒有可以據以入帳的東西。ERC-223 標準正是圍繞這個失敗寫的。改用 `transferFrom` 拉取，合約就有了一次呼叫：在這一次呼叫裡收下舊單位、付出新單位，而這次呼叫需要先有額度。
兩筆交易，只有第二筆在兌換
授權與兌換是兩筆獨立的交易，各付各的 gas。ERC-2612 把這個形狀講得很直白：用戶要與智能合約互動，就得發 2 筆交易，`approve` 與那次內部會呼叫 `transferFrom` 的合約呼叫。
正因為彼此獨立，第一筆可以成功而第二筆照樣失敗。已經關閉的兌換窗口、已經被清空的兌付儲備、被暫停的合約，這些授權一概看不見，它只寫一個數然後返回。授權確認了，不等於它背後的遷移能跑通。
反向的坑在下一步。一次預演通過的兌換上鏈後照樣可能回滾，預演回答的是某一刻的狀態，而不是你的交易真正落進去的那一刻。兌換回滾時，你給出的額度分毫未動，仍然掛在那裡。
有些遷移根本沒有理由問
不是每種遷移都跑在額度上。你被告知的形態，應當與你收到的彈窗對得上。
| 遷移怎麼跑 | 你要發出什麼 | 這裡該不該出現授權 |
|---|---|---|
| 兌換合約拉取你的舊單位 | 一次授權，再加一次兌換呼叫 | 該 |
| 你把舊代幣轉到公布的地址 | 一次普通轉帳 | 不該 |
| 按快照給在冊持有人記帳 | 什麼都不發 | 不該 |
| 平台轉換它自己的池內餘額 | 什麼都不發 | 不該 |
該讓你停下的是第三行。宣布為自動發放的分發，沒有任何環節需要你的額度，所以一個索取額度的頁面，要的是這套遷移用不上的東西。注意到這處不匹配不花任何成本，也不依賴任何人對這個網站的判斷。
彈窗裡決定一切的三個欄位
不管錢包怎麼稱呼，每個授權彈窗都帶著同樣三個欄位。
| 欄位 | 它授出什麼 | 拿什麼核對 |
|---|---|---|
| 代幣 | 這條記錄寫進哪個合約的帳 | 項目方自己公告裡的舊合約地址 |
| 支出方 | 哪個地址可以從你帳戶裡拉取 | 同一份公告裡的遷移合約地址 |
| 數量 | 那個地址最多能拿走多少 | 你這一次打算兌換的份額 |
地址要整串比對。仿冒地址可以和真地址共享開頭與結尾的若干字元，差異恰恰落在中間。
支出方這個欄位承擔著損失，這也是錢包抽乾器不需要攻破任何東西的原因。它把自己的地址填進這個欄位，讓你簽下一份有效且格式正確的授權。交易完全按寫下的樣子成功，餘額稍後才離開，時點由攻擊者定，不由你定。
當它要的是簽名而不是交易
額度不總是以交易的形式到來。ERC-2612 在 ERC-20 標準上擴展出一個 `permit` 函數，允許用戶用一條簽名訊息修改 allowance 映射，而不必經由 `msg.sender`；一條有效的 permit 會把該支出方的額度設為所述數值，把 nonce 加一，並發出一個授權事件。
由此而來的後果是：一個只讓你簽一條訊息、沒有 gas、沒有待確認交易的介面，能授出的東西與一筆授權交易完全一致。它在你簽下的那一刻也不會在你自己的交易記錄裡留下任何東西，因為這條簽名訊息是由別人提交的。
所以對簽名請求要讀同樣三個欄位。permit 裡寫著支出方與它要設定的數值，還有一個 deadline，規範要求當前區塊時間不得晚於它。如果頁面把這次簽名說成登入或確認，而結構化資料裡寫著支出方與數量，那麼會被執行的是結構化資料。
精確額度還是無限額度，以及留下的那條記錄
舉個例子。一個錢包持有 10,000 個舊單位，項目方已經開放兌換。先授權 2,500、兌換這一份、再拿到手的數量與公告比例核對一遍，就把這次遷移變成了你觀察過的事，而不是你假定的事。剩下的 7,500 隨後需要第二次授權，代價是多付一次 gas，這就是這套做法的全部成本。
無限授權省掉了第二次付費，換來的是對這種代幣的長期許可，只要那條記錄還在就一直有效。遷移合約保有拉取此後進入你帳戶的任何舊單位的權利，包括你多年後從一個舊錢包裡找回的舊代幣餘額。
收尾要把剩下的清掉。精確額度會被它所服務的那次兌換消耗掉，超出的部分則留下一條活著的記錄，而一份已經失去用途的代幣授權，是一項沒人再盯著的權限。把額度設回零本身也是一筆交易，同樣要付 gas，所以在遷移結束之後專門去做這一步。
小結
遷移之所以索取授權，是因為 ERC-20 沒有給它第二條拿走舊代幣的路。授權本身是寫進舊代幣合約的一個數，指名一個地址和一個上限：它不轉移任何東西，不證明它背後的遷移可用，也不會因為你關掉頁面而失效。
於是整件事收斂成三項核對。這種遷移形態到底需不需要額度，支出方是不是項目方公布的那個地址，數量是不是你打算兌換的那一份。簽名請求同樣要過這三項；而一份已授出的額度比它周圍的一切都活得久，所以兌換結束就把它清掉。想繼續打好這些基礎，請追蹤 Bitbase（幣貝）學院的更多內容。
相關閱讀
幣貝上與本主題相關的其他文章：
- 如何撤回治理委託
- 代幣供應機制
- 布林帶詳解
風險披露：本文為 Bitbase（幣貝）學院的科普內容，僅供教育與資訊參考，不構成任何投資、交易、稅務或財務建議。加密資產波動劇烈，請自行評估風險。本文撰寫於 2026 年 9 月，請以官方最新資訊為準。
參考資料
[1] 以太坊改進提案，ERC-20: Token Standard，approve 與 transferFrom 方法（狀態：Final） eips.ethereum.org
[2] 以太坊改進提案，ERC-2612: Permit Extension for EIP-20 Signed Approvals，Abstract 與 Specification（狀態：Final） eips.ethereum.org
[3] 以太坊改進提案，ERC-223: Token with transaction handling model，Motivation 一節（狀態：Final） eips.ethereum.org
