投入資金前，先算清淨結果

DeFi 真實收益指南

投入資金前，如何檢查智能合約審計

審計報告要看來源、範圍、版本、未解問題與合約地址，不能只看是否出現審計公司名稱。

D
DeFi 真實收益實驗室
· 16 分鐘閱讀
投入資金前，如何檢查智能合約審計

智能合約審計能幫你讀風險，但不是安全保證。真正要核對的是官方來源、合約地址、版本範圍、未解問題、管理權限與錢包交易細節；範圍不符時，審計不能支持投入。

Uniswap v3-core 官方 GitHub 儲存庫截圖，顯示 Uniswap V3 的 ABDK 審計 PDF 檔案。

這篇適合誰

這篇適合在 pool、farm、vault 或新協議投入資金前，看到「audited」字樣卻不知道如何確認的人。你不必讀完整 Solidity，但要能打開官方文件、GitHub、審計 PDF、合約地址頁與錢包交易明細。本文不替任何審計背書；它提供一套可重複的檢查流程。若要把合約風險與收益放在同一張表，可使用 DeFi 真實收益實驗室。

目錄

決策速覽

你找到的資訊 意義 動作
審計在官方 repo 或文件中 來源可追溯 繼續核對版本與範圍。
只有行銷頁顯示審計商標誌 證據不足 找完整報告，找不到就暫停。
官方合約地址可查 可和錢包交易比對 核對 chain、spender、to/互動合約。
你要用的合約不在範圍 審計不直接覆蓋 當成紅旗處理。
管理權限不清楚 參數或升級風險未知 先找官方說明。

用白話理解機制

審計是外部或獨立團隊對合約邏輯與實作的檢查。它可能找出錯誤、權限問題或假設漏洞，但它永遠有範圍：哪些合約、哪個 commit、哪條鏈、哪一天、哪些問題已修復。若協議在審計後換了合約，舊審計不會自動覆蓋新資金路徑。

Uniswap v3 Core 官方 GitHub repository 說明它包含 Uniswap v3 協議的 core smart contracts Uniswap v3 Core GitHub。該 repo 內也有 ABDK 審計 PDF 檔案 Uniswap v3 ABDK audit file。從官方 repo 找到報告，比從匿名截圖或社群連結更可驗證。

對其他協議也用同一方法：官方文件、官方 repo、官方合約地址與可打開的審計報告。PancakeSwap Developer 提供 v3 官方合約地址頁，列出 Factory、SwapRouter、NonfungiblePositionManager 等地址 PancakeSwap v3 Addresses。

檢查審計時，最重要的是不要被「有沒有」這個問題限制。更有用的問題是：這份報告從哪裡來，檢查了哪些合約，是否對應我即將互動的鏈與地址，哪些問題仍未解，管理權限會不會繞過審計假設。只要其中一項無法回答，審計就只能算部分證據，不能變成安全結論。

還要把前端和合約分開看。官方前端可能只是引導你交易，真正授權的是 token approval 的 spender，真正互動的是交易的 to 或合約地址。若錢包顯示的 chain、spender 或互動合約與官方文件不一致，先停止。這一步不需要你審 Solidity，但需要你願意逐字核對地址來源。

PancakeSwap 開發者文件截圖，顯示官方 v3 合約地址清單。

技術細節與檢查順序

不要把審計看成是/否分數。它只有在文件、合約與你實際交易的路徑一致時，才有參考價值。請逐項核對：

  • 來源：報告是否來自官方 repo、官方文件或審計公司可驗證頁面。
  • 範圍：是否涵蓋存放資金、處理 reward、router、wrapper 或 farm 的合約。
  • 版本：commit、tag、部署地址是否和當前 UI 使用的合約相符。
  • 殘留問題：critical、high 或影響資金的 medium 是否仍未解決。
  • 管理權限：upgrade、pause、fee change、ownership 是否公開。
  • 錢包交易：簽署前核對 chain、token approval 的 spender、交易 to 或互動合約，以及訊息內容。

PancakeSwap Developer 也列出官方 GitHub 入口，包含 smart contracts 與 periphery 相關 repo PancakeSwap Developer: Github。若協議無法提供 repo 或地址來源，你就沒有足夠基礎核對審計。

假設示例：有審計但範圍不完整

假設示例：某 farm 聲稱已審計。你從官方文件找到報告，但發現新 reward 合約不在範圍內。

檢查 發現 對決策的影響
來源 報告來自官方 repo 來源可追溯。
範圍 主池合約涵蓋，新 reward 合約未涵蓋 審計不能證明完整資金路徑。
版本 部分 commit 相符 要逐一核對現行合約。
殘留問題 有未關閉問題 讀它是否影響資金或獎勵。
管理權限 upgrade admin 存在但延遲不明 暫停投入，找官方說明。

這組是假設，不是對某個協議的評價。它說明「有審計」只能支持被審計且版本相符的部分，不能自動覆蓋所有新合約。

費用與失敗情景

審計錯讀的代價常在投入後才出現。若 reward 合約有問題，獎勵可能無法領取；若 pool 合約有問題，資產可能被鎖住；若 UI 指向的地址不同於官方地址，你可能把 approval 授權給錯誤 spender。這些風險不會反映在 APY。

另一個常見失敗是 scope mismatch。審計可能只涵蓋 core contract，卻未涵蓋 wrapper、farm、router 或新活動合約。簽署前要把錢包顯示的 chain、spender、to/互動合約和官方地址頁核對；PancakeSwap v3 地址頁就是官方部署地址範例之一 PancakeSwap v3 Addresses。

還要看管理權限。可升級、可暫停或可改費率的合約不一定錯，但你必須知道誰能操作、是否有 timelock、使用者是否能退出。若文件沒有說明，風險尚未消除。

審計時間也很重要。舊報告仍有歷史價值，但若產品後來新增 wrapper、reward、router 或跨鏈部署，舊報告不會自動覆蓋。閱讀報告時至少看 scope、summary、severity、unresolved issues。Scope 告訴你檢查範圍；severity 告訴你問題嚴重性；unresolved issues 告訴你是否仍有未處理風險。

如果你看不懂完整報告，可以先建立一張紅旗表，而不是放棄檢查。表中列出官方來源、報告日期、合約地址、未解問題與管理權限。只要能把未知項清楚寫出，就能避免把未知風險誤當成低風險。

如何自行驗證

  1. 從協議官方網站或文件進入，不從群組截圖進入。
  2. 找官方 repo；例如 Uniswap v3 Core GitHub。
  3. 找審計資料夾或官方報告；例如 Uniswap v3 ABDK audit file。
  4. 找官方地址頁；例如 PancakeSwap v3 Addresses。
  5. 在錢包簽署前核對 chain、spender、to/互動合約與訊息內容。
  6. 檢查審計範圍、commit、日期與未解問題。
  7. 把仍未回答的紅旗寫下來，不要用 APY 把它掩蓋。

完成後保存來源連結與檢查日期。這不是形式工作；DeFi 產品可能更新合約、遷移前端或改變 reward 合約。保留紀錄能讓你下次檢查時知道哪些項目需要重新核對，也能避免只憑記憶判斷「之前看過，應該沒事」。

若你正在比較多個協議，請用同一張表檢查，不要因品牌知名度改變標準。成熟協議也可能有新合約，新協議也可能提供完整文件；判斷應落在可核對證據上。對一般使用者而言，最重要的不是成為審計專家，而是在簽署前知道自己把 token 授權給誰、和哪個合約互動、以及審計是否真的覆蓋這條路徑。

若任一欄只能填「不知道」，先把它當成未通過，而不是把未知留到投入後再查。

未知越多，越應降低行動速度，直到來源能被重新核對。

投入資金前檢查清單

  • 審計報告是否來自官方來源？
  • 存放資金或管理 reward 的合約是否在審計範圍內？
  • 合約地址是否可和官方文件核對？
  • 版本、commit 或部署地址是否相符？
  • high、critical 或影響資金的問題是否已關閉？
  • upgrade、pause、fee change 等管理權限是否清楚？
  • 你是否知道錢包中的 chain、spender、to/互動合約？
  • 若紅旗未解，預期收益是否值得等待確認？

延伸判讀：audit 筆記應該長什麼樣

審計筆記不應只有「已審計」三個字。建議建立五欄：合約或模組、官方地址或 repo、審計報告來源、重要發現與狀態、你的決策。若報告只覆蓋 AMM 核心，卻沒有覆蓋 reward gauge、vault、router 或新部署合約，請把未覆蓋的模組列出來。這不是否定審計，而是避免把審計範圍說得比實際更大。

若合約可升級，還要記錄 proxy、implementation、admin role、timelock 與 pause 權限。OpenZeppelin 的 access control 文件可以幫助理解角色權限，但你仍要看協議實際如何配置。若只知道「團隊可以調整」，分數不應太低。若 role、地址、延遲與可改參數都公開，才有比較好的證據。

假設示例：某 pool 的 swap 合約有 audit，但 reward 合約是新部署。你可以把 swap 層評分較低風險，把 reward 層評分較高風險，然後在 /defi-real-yield-lab 中降低 reward 承認值或等待新報告。不要因為一個 logo 就把整個策略寫成安全。審計是證據的一部分，不是保證。

補充：變更後要重新核對

合約審計不是永久標籤。若 proxy implementation、reward contract、router 或部署 chain 變更，舊報告可能不再覆蓋全部風險。請保存檢查日期與地址。下次加倉前，先核對 live 合約是否仍與報告範圍一致。若不一致，分數要上調，直到官方提供新證據。

下一步

把合約與管理權限紅旗填入 DeFi 真實收益實驗室 的非量化風險檢查表。若淨結果只略為正值，而審計又不覆蓋實際合約，最保守的做法是暫停。

主要資料

DeFi 真實收益指南 智能合約審計官方倉庫合約地址DeFi 安全審計報告

相關閱讀