什麼是 DYOR？

DYOR 是「Do Your Own Research」的縮寫，中文常譯為「自行研究」。在加密資產語境中，它指不直接把宣傳、貼文或他人的結論當成事實，而是自己尋找原始資料、交叉核對證據，並把已經確認的資訊與仍然未知的部分分開。

DYOR 不是一種統一認證，也不是保證專案可靠或避免損失的方法。它更像一套資訊核對過程：先明確某項說法具體宣稱什麼，再判斷哪些資料能夠佐證它、資料是否仍適用於目前版本，以及哪些結論只是推測。研究結果也不是簡單的「可以買」或「不能買」標籤。

自行研究從一條可以核對的主張開始

「這個專案很好」「社群很強」或「技術領先」都很難直接驗證。更具體的主張才知道去哪裡找證據，例如：

• 某個地址是不是專案目前使用的代幣合約；
• 代幣總量能否增加，誰有增發權限；
• 合約能否暫停、升級或凍結某些操作；
• 頁面顯示的交易量來自哪些市場和時間範圍；
• 某份稽核報告檢查的是哪個程式碼版本；
• 某項合作、整合或產品功能是否得到相關各方確認；
• 宣稱已經上線的功能是否能在程式碼、介面或鏈上活動中找到對應紀錄。

先寫清主張還能避免把不同問題混在一起。合約原始碼已經公開，不等於程式碼沒有缺陷；團隊身分已經公開，不等於產品能夠兌現全部計畫；鏈上有人交易，也不等於這些交易來自獨立使用者或具有持續需求。

不同主張需要不同種類的證據

沒有一種來源能夠回答所有問題。研究時常見的證據可以分成幾類：

「官方來源」適合確認專案自己宣稱什麼，但它仍然是專案方發布的資料。獨立來源可以提供不同視角，也可能引用錯誤或過時資訊。可靠結論通常來自多個來源對同一具體主張的相互印證，而不是給某個網站貼上「可信」標籤後接受它的全部內容。

先核對網路和合約地址，再看名稱與圖示

鏈上代幣可以重名，也可以使用相同的圖示和交易代碼。識別一項數位資產時，網路名稱和合約地址通常比顯示名稱更有區分力；對於非同質化代幣，還可能需要核對代幣編號。

專案網站或文件可以提供合約地址，區塊瀏覽器則可以顯示這個地址的部署交易、餘額、代幣轉移和合約呼叫。Ethereum.org 對區塊瀏覽器的介紹列出了區塊、交易、帳戶、合約和代幣等常見鏈上資料。

地址仍要交叉核對。仿冒網站也可以展示一個真實存在的合約，搜尋結果和社群媒體貼文也可能指向同名假代幣。頁面上的「已驗證」標記具體表示什麼，要看該服務的驗證規則，不能只憑圖示或標籤下結論。

鏈上記錄能證明發生了什麼，不能自動解釋為什麼

區塊鏈可以記錄某個地址在何時發起交易、資產怎樣轉移，以及合約狀態怎樣變化。這類紀錄適合核對供應量變化、資金流向、治理投票和特定功能是否被呼叫。

鏈上記錄通常不會直接告訴讀者地址背後的真實身分，也不能單獨解釋一筆交易的目的。一個人可以控制多個地址，多個人也可以透過同一個託管平台地址操作。地址數量不能直接等同於使用者數量，代幣轉移次數也不能直接等同於實際採用程度。

鏈上資料還可能經過索引、標籤和計算後再展示。鏈上可獨立核對的交易欄位屬於協議紀錄，服務提供的地址標籤、持有人分類和統計圖表則包含額外判斷。使用這類結果時，需要查看計算口徑、涵蓋網路和更新時間。

已驗證原始碼只說明程式碼與部署版本相符

智能合約是部署在區塊鏈上、按程式碼執行操作的程式。在 Ethereum 等使用以太坊虛擬機（Ethereum Virtual Machine，EVM）的網路中，原始碼驗證通常會按相同設定重新編譯公開程式碼，再與合約地址上實際執行的機器碼進行比較。機器碼是供網路直接執行的編譯結果。Ethereum.org 的合約驗證說明把這種比對檢查與形式驗證分開；形式驗證是用數學方法檢查程式是否滿足預先指定的性質。其他網路需要按各自的部署和版本機制核對程式碼。

因此，「合約程式碼已驗證」通常說明讀者看到的程式碼能夠對應鏈上程式，不表示程式碼已經過安全稽核，也不表示程式沒有邏輯缺陷。公開程式碼中的註解和變數名稱也可能帶有誤導性，實際行為要看可執行邏輯。

還要確認入口合約是否會把請求轉發給另一份實作程式碼。這類入口常稱為代理合約。可升級代理允許具有相應權限的帳戶更換實作程式碼；OpenZeppelin 的代理合約文件說明了代理、實作合約和升級管理員怎樣配合。只閱讀代理地址本身的短程式碼，可能漏掉真正執行功能的合約和升級權限。

程式碼儲存庫展示開發紀錄，不等於線上功能

公開程式碼儲存庫可以顯示檔案、提交紀錄、版本標籤、議題討論和貢獻者。提交是一次被記錄的程式碼變更，版本標籤則常用來標記某次發布。它們可以幫助核對專案是否持續修改程式碼、某項功能何時加入，以及不同版本之間改了什麼。

GitHub 的儲存庫活動說明展示了推送、合併、強制推送和分支變化等紀錄。活動多不等於程式碼品質高，提交少也不一定表示專案停止；自動更新、複製程式碼和不在公開儲存庫進行的開發都會影響表面資料。

儲存庫程式碼還要與實際部署版本對應。研究某個鏈上應用時，應查看發布標籤、部署紀錄或合約驗證資訊是否能把儲存庫中的版本與鏈上地址連接起來，否則只能確認「儲存庫裡存在這份程式碼」，不能確認線上正在執行它。

稽核報告要看範圍、版本、日期和處理結果

安全稽核是專業人員在一定範圍和時間內檢查程式碼、設計或運作假設，並記錄發現的問題。閱讀報告時，重要的不只是「做過稽核」，還包括：

• 受檢檔案、合約地址或程式碼提交是否寫清；
• 稽核完成後程式碼是否又發生重大變化；
• 哪些元件、外部依賴和運作條件不在檢查範圍內；
• 報告發現了哪些問題，專案如何回應；
• 修復是否經過覆核，未修復問題是否仍然存在；
• 報告是否由稽核方公開，連結是否指向完整檔案。

稽核不能證明不存在未知缺陷。OpenZeppelin 的上線準備文件也說明稽核不能保證程式碼沒有錯誤。把舊版本、局部模組或尚未覆核的報告當作整個系統的安全證明，會超出報告本身能夠涵蓋的範圍。

白皮書說明計畫，不等於完成紀錄

白皮書通常介紹專案要解決的問題、設計思路、代幣安排或發展計畫。它適合用來確認專案方公開提出了什麼目標，卻不能單獨證明目標已經實現。

研究時可以把白皮書中的可驗證主張分別與目前文件、程式碼發布、鏈上部署和實際功能核對。路線圖日期已經過去但沒有對應發布紀錄、代幣規則與已部署合約不一致，或文件長期沒有更新，都是需要繼續確認的差異；它們本身不必然證明專案存在欺騙。

文件還可能描述舊版本。頁面發布日期、最後一次修改、適用網路和版本號，決定一段說明能否用於目前系統。沒有日期或版本資訊時，應把結論標為不確定，而不是自行補全缺失背景。

社群媒體熱度不是事實證明

按讚、轉發、群組人數和搜尋熱度描述內容傳播情況，不能直接證明技術功能、使用者身分、資金安全或市場需求。帳號可能被仿冒、盜用，互動也可能來自自動化程式或協同推廣。

社群媒體更適合用來發現需要核對的主張，而不是作為主張的唯一證據。涉及合約地址、版本更新、安全事件或外部關係時，可以回到專案文件、程式碼儲存庫、鏈上紀錄和相關各方原始聲明進行確認。

來源是否揭露利害關係也很重要。內容作者可能持有相關代幣、接受報酬、參與專案或透過推薦連結獲益。沒有揭露不一定證明內容錯誤，但讀者無法據此判斷潛在利益衝突，證據權重需要與可獨立核對的資料分開。

一個完整核對過程會保留未解決的問題

DYOR 的結果不應只有一串連結，還應說明每條證據回答了什麼。一個通用的資訊核對過程可以這樣記錄：

1. 把模糊評價改寫成一條具體、可驗證的主張；
2. 找到最接近該主張的原始資料，並記錄發布者、日期和版本；
3. 使用鏈上紀錄、程式碼、完整報告或另一獨立來源交叉核對；
4. 區分直接觀察到的事實、根據事實作出的推斷和個人觀點；
5. 寫下來源之間的衝突，以及仍然缺少什麼證據；
6. 當合約、權限、版本或外部關係無法確認時，保留「不確定」，不要把空白當成肯定或否定結論。

同一研究結論會隨時間失效。合約可以升級，管理權限可以轉移，文件和稽核範圍可以改變，流動性與代幣分布也會變化。引用動態資訊時，需要保留資料時間點，不能把一次檢查寫成永久結論。

常見警示訊號需要繼續核對，而不是直接定罪

下面的情況表示現有資料不足或存在衝突，需要進一步核對：

• 合約地址只出現在無法確認身分的貼文或私訊中；
• 名稱、圖示和交易代碼相同，但所屬網路或合約地址不同；
• 頁面宣稱程式碼開源，卻沒有與部署版本對應的儲存庫或驗證紀錄；
• 宣稱經過稽核，卻不提供完整報告、檢查版本或修復狀態；
• 白皮書中的供應或權限說明與目前合約行為不一致；
• 使用「保證收益」「沒有風險」或製造緊迫感的語言；
• 宣稱獲得外部機構背書，但相關方沒有可核對的對應說明；
• 管理員能夠升級、暫停或轉移資產，但公開說明沒有提及這些權限；
• 資料截圖沒有來源、時間範圍或可覆查連結；
• 討論只引用互相轉載的文章，最終找不到原始資料。

單個警示訊號並不能自動證明專案詐欺。例如，開發團隊沒有公開全部身分、程式碼更新較少或合約具有管理員權限，都可能有不同原因。結論需要與具體承諾、技術結構和可核對紀錄對應。

DYOR 有邊界，也不應用來把責任推給受害者

一般讀者不可能獨立稽核全部程式碼、驗證所有團隊資訊或發現專業攻擊。資訊可能故意隱藏，介面和帳號可能被仿冒，稽核和公開資料也可能存在盲區。自行研究只能減少部分資訊缺口，不能把所有未知風險變成已知。

「你應該自己研究」也不能取代專案方準確揭露重要資訊，或為虛假陳述開脫。有人因誤導、仿冒或技術漏洞遭受損失時，簡單指責其「沒有 DYOR」忽略了資訊不對稱和專業門檻。

當問題需要專業技術、安全、財稅或法律判斷時，一般的資訊核對無法涵蓋同樣的證據範圍和責任。

常見問題

看過白皮書就算完成 DYOR 嗎？

不算。白皮書主要說明專案方的目標和設計。仍需核對目前程式碼、部署、權限、鏈上活動、稽核範圍和文件版本是否與這些說明一致。

合約程式碼已驗證，就代表安全嗎？

不代表。原始碼驗證主要確認公開程式碼與部署的機器碼相符，不會自動發現所有邏輯缺陷，也不會消除升級權限、外部依賴和操作風險。

鏈上資料不會造假，所以結論一定可靠嗎？

鏈上交易紀錄可以驗證，但地址標籤、身分歸屬、使用者數量和交易動機通常需要額外解釋。計算口徑錯誤或把多個地址誤當成多個使用者，也會產生錯誤結論。

匿名團隊一定不可靠嗎？

不能只憑是否匿名下結論。公開身分可以增加可核對資訊，但不能證明程式碼、安全或承諾；匿名則會減少身分和履歷方面可驗證的資料，需要明確記錄這一資訊缺口。

DYOR 能告訴我應該買哪種資產嗎？

不能。DYOR 是核對資訊、來源和未知項的過程，不會自動得出適合某個人的買賣或持有結論，也不能預測未來價格。

相關詞條

繼續了解數位資產、智能合約、加密代幣和私鑰，或返回加密貨幣術語表。

參考來源

• Ethereum.org：Block explorers——區塊瀏覽器可展示的區塊、交易、帳戶、合約和代幣資料。
• Ethereum.org：Verifying smart contracts——原始碼比對、機器碼與形式驗證之間的區別。
• OpenZeppelin Docs：Upgrades Plugins FAQ——代理、實作合約和升級管理員的關係。
• OpenZeppelin Docs：Preparing for mainnet——稽核、原始碼驗證、管理權限和稽核局限。
• GitHub Docs：Using the activity view——儲存庫變更、推送、合併與分支活動紀錄。