合約地址怎麼核對：把鏈、完整地址與證據範圍綁在一起

某個代號出現在官方頁、區塊瀏覽器和資料供應商時，三處的圖示可能一樣，縮短地址也看來相似。這些線索適合幫人找頁面，卻不足以回答「我看到的是哪一條鏈上的哪一個物件」。真正能重現的答案，不是一張標誌頁，而是一組有範圍的身分證據。

這組證據有五欄：鏈、完整地址、地址類型、來源、觀察時間。任一欄空白都應保留未確認，不用熟悉的名稱、熱門圖示或另一條鏈的同串字元補滿。核對的目標是進一步讀取公開資料時不會把不同物件靜默併在一起，不是替代獨立的安全或專案背景審查。

地址核對不是找到一串長字元

完整地址只有和鏈、類型綁在一起才有意義。EVM 的合約地址要附網路；Solana 的一串公開鍵還要分清是 mint account、token account 或另一種帳戶。光是格式合法，只能說明字串像地址，不說明它對應哪個專案、由誰控制或是否具有特定性質。

拉取身分時，先從專案自己的公開頁面取得地址候選，再把它與第三方映射和區塊瀏覽器的精確入口分別記錄。這是三筆證據，不是三張必然背書彼此的證書。如果三者對鏈或地址給出不同答案，記錄衝突比選一個看來最像的答案更可靠。

衝突紀錄還需要版本欄。公開頁可能改版，探索器標籤也可能在不同日期更新；後一次觀察不能無聲覆蓋前一次結果。每個版本應保存來源 URL、擷取時間、當時完整地址與差異欄位，再把「來源已更新」和「哪個地址正確」分成兩個命題。版本先後能證明頁面內容改變，不能單獨證明改變原因或其中一版必然有效。

地址類型也不應由頁面標題猜測。某個探索器頁面可能同時顯示地址、代幣名稱、持有人數與互動紀錄，但這些鄰近欄位沒有把地址自動變成已核准的合約或 mint。紀錄者要保存實際讀到的物件類型、該判斷來自哪個欄位，以及尚未確認的部分。若只能確認完整字串與鏈，就只寫這兩項，不替缺少的類型補答案。

EVM 頁面同時放了四種不同證據

EVM 區塊瀏覽器上，合約地址、verified source code、address ownership 或 name tag、專案身分與安全結論是四件事。合約地址定位部署物件；可讀來源碼提供程式檢視材料；帳戶與地址的連結說明某個簽署者可以進入特定更新流程。至於專案是否官方、實際控制關係為何、程式是否安全，都需要另外的證據與分析。

這種分欄能避免常見的跳躍：看到「Contract Source Code Verified」就改寫成「專案已官方認證」，或看到 name tag 就改寫成「地址由品牌實益擁有」。資料頁會把資訊放在相近位置，但相近不會改變每個欄位能支持的命題。

四欄還可能來自不同時間：部署物件本身已存在一段時間，來源碼稍後才提交，平台帳戶再於另一日完成地址連結，標籤也可能之後更新。若把頁面目前狀態寫成一個沒有日期的「已驗證」，就會抹去這些事件的先後。較穩健的紀錄會為合約、來源碼狀態、平台更新控制與顯示標籤各留觀察時間。

verified source code 只回答程式碼是否匹配

Etherscan 的公開說明將 source-code verification 描述為來源碼與已部署程式碼的 matching process。當這個流程完成，讀者可以閱讀提交的程式、檢查函式和觀察可讀邏輯。這是「可查閱性」與「匹配關係」的證據，不會自動對每條路徑做安全審計。

因此，身分紀錄應寫「在某日觀察到該地址有 verified source code」，而不是「這個代幣無風險」。就算來源碼公開，其管理權限、可升級路徑、外部依賴與實際使用情境仍然是其他問題。「可以讀」是審查的起點，不是審查已結束。

address ownership 與 name tag 是更新控制線索

Etherscan 另一份文件說明，address-ownership verification 透過 creator address 簽署訊息，將地址與 Etherscan account 連結，然後可更新 token info、sales info 或 name tag。這筆證據的範圍是「誰能在這個平台進行特定更新」，不是「誰是所有經濟利益的最終所有人」。

記錄時可以把 ownership 狀態放入「探索器更新控制」欄，同時把專案官方身分、合約安全、實益控制與代幣真偽留在獨立欄位。如果沒有另外的公開證據，後四欄依然是未確認。

Solana 要先分辨 mint 與 token account

Solana 文件把 mint account 與 token account 分成不同物件。mint 定義一種代幣的全域資訊；token account 記錄某帳戶對該 mint 的餘額與所有關係。如果把持有帳戶的公開鍵當成 mint，之後的供應、權限與幣對核對都會從錯誤物件開始。

一筆 Solana 身分包應另存 program owner、decimals、mint authority 與 freeze authority。program owner 說明哪個程式解釋帳戶狀態；decimals 說明原始整數如何顯示成人類可讀單位；兩種 authority 則是不同權限欄位。它們不應被濃縮成一個「權限正常」標籤。

這些欄位之間也沒有自動推導關係。讀到 decimals 只能解釋單位，不會證明 mint authority 已撤銷；讀到 program owner 只能指向解釋帳戶資料的程式，不會證明顯示名稱屬於某個專案。若權限欄位沒有成功取得，應保留 missing 或 failed，不能根據其他欄位看來合理就填成無權限。

精度與權限每欄各有時間

就算 mint 已確認，既有擷取也只是某時點的記錄。decimals 通常用於解釋單位，mint authority 和 freeze authority 則可能有指定值、改變或無值狀態。未讀到不代表權限已撤銷，也不代表欄位為零。證據表要同時寫來源與 observedAt，方能在未來重新查證。

名稱、代號與圖示也常來自 metadata 或平台標籤，可被更新、重用或依供應商規則顯示。它們適合放在「顯示資訊」欄，不是索引帳戶的主鍵。要把池、供應或權限資料歸到某代幣，仍要使用完整 mint。

同代號、同地址或同標籤都不足以跨鏈

同一代號可以在多條鏈被不同人重用；即使兩條 EVM 鏈顯示形式相同的地址，它們也是不同狀態空間中的部署物件。要說明兩個表示屬於同一資產，需要官方公開說明、可追溯的橋接或發行機制，以及供應商映射範圍。字串相同不是關係證明。

官方頁可以支持專案自述的地址，provider mapping 可以支持供應商如何分類，explorer record 可以支持特定鏈上某個物件的可觀察資料。這三者合併仍應保留各自發布者、網址與時間，不寫成沒有來源差異的「已驗證」單欄。

兩張文件圖只證明文件存在

本文使用的兩張圖都來自公開概念文件，用途是保存 2026-08-02 所見的文件上下文。圖中沒有特定代幣合約欄、沒有權限現值，也不試圖以探索器標籤當作專案背書。日期化圖像能作為文件版本線索，卻不會擴張文件原本能支持的主張。

負面證據也要限制範圍。截圖中沒有出現某個地址或權限現值，只能說明這兩張文件圖沒有展示該資料，不能推導鏈上不存在該欄位、權限已撤銷，或專案沒有其他公開地址。若查詢因頁面載入、權限或網路狀態失敗，紀錄應寫取得失敗，而不是把「沒有成功讀到」改成「已確認沒有」。

地址變更要留下版本邊界

專案若宣布遷移至新合約，舊與新地址要分列保存，並記錄官方公告、轉換機制、生效區塊與最後核對日期。代號不變也不能把舊池、舊價格史與新供應自動接起來。遷移關係未完整證實時，兩個合約仍是獨立資產物件。

Proxy 地址與實作地址要成對

代理合約中，使用者交互的 proxy 位址保存狀態，implementation 位址則提供目前邏輯。驗證記錄同時保存 proxy、實作槽、admin 槽、讀取區塊與最近升級事件。只複製 implementation 位址，會遺失使用者實際持有資產的狀態上下文。

explorer 的「Read as proxy」只是便利界面。若要解釋過去交易，必須回到當時區塊的 implementation，不能拿今日程式碼追溯過去邏輯。升級權限另列為控制證據，不與 token owner 混在同一欄。

CREATE2 預計位址不是已部署證明

CREATE2 可以由 deployer、salt 與 init code hash 預先計算位址，但預計結果不代表該位址已有正確程式。驗證時要查部署交易、factory、salt、init code、runtime bytecode 與 chain ID。

同一位址在不同鏈上可能由不同部署過程得來，狀態與控制者也不同。「跨鏈同位址」不能代替每條鏈的官方 mapping。位址還沒有 code 時，記錄必須寫成未部署，不以預告當成現況。

Bytecode 核對要說明編譯差異

來源碼驗證通常會保存 compiler 版本、optimizer、library link、constructor arguments 與 metadata。這些設定不同時，程式語意看來相近，最終 bytecode 仍可能不同。只比對閱讀介面中的原始碼不夠。

對於 immutable 參數、linked library 與最後 metadata 段，可重建區段與 runtime 區段要分開說明。有多個相同模板的合約時，核心碼相同也不會證明 owner、參數與專案關係相同。

官方發布訊息要綁定完整地址

官方文件、網站與已驗證社群訊息可以建立專案與位址的關係。可是訊息必須顯示完整位址、鏈名與發布日期；圖片中的頭尾縮寫無法排除相似位址。

若專案使用簽名訊息公開位址，記錄簽名方式、原始訊息、簽章、簽名位址與驗證結果。簽名只能證明當時密鑰對訊息的控制，不會自動證明公司身分或合約安全。

管理員變更要追過去事件

目前 owner 為零位址，不代表合約從部署起就無管理員。OwnershipTransferred、role grant/revoke、proxy upgrade 與 multisig 設定要依區塊排列，才能解釋某筆歷史交易當時的控制權。

事件本身也要與最後 state 核對。若使用 AccessControl，光看 owner 不會列出所有 mint、pause 或 admin role。若使用 proxy，邏輯升級權可能來自另一合約。所有權限都保存區塊與來源，不用「已放棄」一個標籤收尾。

外部 library 與模組不能遺漏

合約可以透過 library、delegatecall、hook 或可設定模組擴展行為。主合約來源碼中沒有某項功能，不代表外部模組不能實作。可變的模組位址、設定者與當前 code hash 要列入身分檔案。

第三方 router 或 bridge 與 token 本體是不同信任邊界。它們支援某代幣，不代表成為該代幣的官方合約。每一個外部依賴都以完整位址與關係證據列出。

核對日期不是無限期保證

位址本身可能不變，但 proxy implementation、admin、角色、官方網域與專案對應關係都可能更新。所以每筆身分證據都帶最後核對日期與觸發重查的事件。來源無法存取時，舊結果保留原日期，不改成今日已確認。

把身分核對紀錄存成可複核的一列

一筆可存檔的紀錄可以依次留下：

1. 鏈的精確名稱與網路，不只寫「鏈上」。
2. 完整地址，不以截短字串或圖示當主鍵。
3. address type：EVM contract、Solana mint account、token account 或其他已確認類型。
4. 每個來源的發布者、精確 URL，以及該來源支持和不支持的主張。
5. observedAt 與缺失狀態；未讀到、已過時或取得失敗均不填零。
6. 衝突欄：不同來源若不一致，保存差異與待查問題，不自行抹平。

這列記錄不會替代專案、程式或控制關係的審查。它的價值是把「名字看來對」改寫為「這個來源在這個時間，對這條鏈的這種地址支持什麼」。下次資料更新時，可以沿著同一五欄主鍵重新觀察，而不必依靠舊截圖的視覺印象。

存檔時還可將每個結論分成 observed、inferred 與 unresolved 三種狀態。observed 只收來源直接顯示的內容；inferred 要附推理所依賴的欄位；unresolved 則保存衝突、缺值與下一步查證問題。這種分層不會讓地址更「可信」，但能防止日後引用者把當時尚未確認的推測誤讀為原始來源已發布的事實。