從代理、實作合約與升級管理者三個角色，建立檢查 DeFi 合約升級權限的閱讀順序。
代理模式解決什麼問題
許多合約把使用者互動導向代理地址，再由代理以 delegatecall 執行另一個實作地址的程式碼。這樣可以在保留代理地址和儲存資料的情況下更新邏輯，但也代表使用者信任的不是單一不可變程式，而是一套權限與流程。區塊瀏覽器上看到的「合約已驗證」不等於升級權限安全。
先找出誰能升級
閱讀官方文件和鏈上儲存槽，確認目前實作地址、管理者或升級者角色。管理者可能是多簽、治理合約或時間鎖，也可能仍是單一外部帳戶。若文件沒有說明撤換管理者的條件，便不能假設升級需要社群同意。檢查權限時記錄區塊高度，因為管理者和實作地址會變更。
storage layout 是關鍵
新實作若更改變數順序或型別，可能覆蓋代理原有儲存槽，造成餘額、授權或角色資料異常。專案若提供 storage layout、升級腳本和測試，應把它們與鏈上 bytecode 對照。不要僅依賴介面按鈕或社交平台截圖，先確認合約地址、網路和編譯版本一致。
升級事件與時間鎖
成熟的升級流程會發出實作變更事件，並可能設有延遲，讓監控者在執行前查看差異。看到升級事件後，核對新實作的原始碼、權限和初始化函式；若流程跳過時間鎖或由陌生帳戶直接更換，應暫停新增授權。事件能提供線索，不能代替權限驗證。
使用者如何降低暴露
把長期資產與高風險合約分開，定期檢查已授權的 allowance 和簽名權限。若專案發出升級通知，從官方網域取得地址，再與鏈上資料交叉核對。需要撤出時先做小額測試，並為交易預留足夠 gas；不要把助記詞貼到所謂升級表單。
核對清單
確認代理與實作地址；找升級者、管理者、多簽成員與時間鎖；閱讀 storage layout 和初始化邏輯；檢查最近的升級事件；把所有地址和區塊高度存入自己的記錄。