追查同名代幣：從網路身分建立證據鏈

一份調查卷宗從異常通報開始：搜尋結果裡同時出現三個同名代幣，代號完全相同，其中一頁掛著熟悉圖像，另一頁帶有瀏覽器驗證標籤，第三頁的合約曾建立很久。社群貼文把三者混稱為同一資產，卻沒有交代鏈、完整地址或跨鏈關係。此時任何價格與供應數字都應暫停抄錄，因為卷宗連「正在查誰」都還沒有答案。

假合約常借用名字、代號與圖像；跨鏈表示則可能在不同帳本上保留相同品牌。兩種情況表面相似，證據問題並不相同。前者要找出專案所指向的精確資產，後者還要判斷是原生多鏈部署、鎖定後鑄造的表示、包裝資產，或互不相干的同名發行。

這篇文章採用現場調查結構：先建立證據階梯，再把四類網路身分拆開，接著重建兩宗短案，最後保存一份可續查的身分紀錄。它不提供合約複製或錢包操作，也不把任何單一欄位轉成安全認證。

五層證據階梯：每一層回答不同問題

第一層是官方專案或協議來源。它回答「專案公開指向哪條網路、哪種資產與哪些地址」，也提供聲明日期。第一方來源仍可能過時、行銷化或缺少鏈上細節，因此只能建立待核對的主張，不能一頁結案。若官方頁沒有列出完整地址，紀錄就應明寫尚缺，不從搜尋摘要或圖像猜補。

第二層是鏈、合約或 mint。原生資產以自己的網路規則識別；智能合約代幣要連同鏈別保存完整合約；Solana token 則以 mint 為核心鍵。名稱與代號可被重複，地址才把調查對象落在一個具體帳本位置。地址格式相似也不表示兩條鏈上的部署具有同一經濟關係。

第三層是區塊鏈瀏覽器狀態。研究者在指定日期查看代幣標籤、精度、供應、權限與相關帳戶，但每個欄位要分開記。瀏覽器將名稱標為 verified，只能證明其標籤流程達到該站條件；它不代替專案控制證據。頁面沒展開的欄位維持未知，不能用另一個網站的值填上。

第四層是資料供應商 mapping。供應商 ID 決定它把哪些鏈別合約、橋接表示和市場資料歸入同一資產。即使鏈上地址都正確，mapping 若採不同聚合規則，供應與市值範圍仍可能不同。CoinGecko 的跨鏈供應 FAQ 是其自身方法，不能直接冠在其他供應商頭上。

第五層才是 pool identity：指定鏈、指定 token、報價資產、pair address 與協議池。池建立很久只說明該 pair 的歷史起點，不會反向證明代幣來自官方專案。到這一層仍須把池資料限定在本池；多池深度與活動另有自己的證據方法。

這五層不是五張相同效力的證書。官方來源可能指向地址，瀏覽器觀察地址狀態，供應商決定資料歸類，池則承載局部市場。只有讓每層回答自己的問題，矛盾才會顯露；若把 verified label 當成官方來源，調查反而會跳過最重要的缺口。

四種身分不能共用一張證件

DOGE：先找原生網路，不找 token 合約

Dogecoin Dogepedia 描述礦工在 Dogecoin 網路以工作量證明建立區塊、取得區塊獎勵，並把新單位帶入流通。這組協議關係使 DOGE 的核心身分是 Dogecoin 原生鏈資產。身分紀錄應寫原生資產與網路規則，不應為原生 DOGE 填上一個 ERC-20 合約或 Solana mint。

其他鏈當然可能有人建立名稱含 DOGE 的 token，也可能出現包裝表示；那些物件要以自己的鏈、地址與橋接證據另立紀錄。它們共享代號，不會因此繼承原生 DOGE 的區塊獎勵歷史、供應規則或官方身分。看到「DOGE 合約地址」時，第一個問題應是它描述原生資產、包裝表示，還是獨立同名代幣。

SHIB 與 PEPE：ERC-20 只說明介面，合約才定位物件

ethereum.org 將 ERC-20 說明為 Ethereum 上同質代幣的智能合約介面，包含總供應、餘額、轉移與核准等方法。這些共同方法提高互通性，卻也意味著許多完全不同的合約可以顯示相同 `name` 或 `symbol`。符合標準只證明介面層，不證明品牌歸屬。

SHIB 與 PEPE 可作為 Ethereum token 的範圍例子。調查表要保存 Ethereum、完整合約、專案來源日期與瀏覽器觀察，再連到供應商 ID；不能只寫 SHIB 或 PEPE。PEPE 專案頁在存取日提供 ETH 語境與專案供應自述，但行銷頁本身不等於鏈上狀態或供應商流通分類。

SHIB 文件在這裡只提醒一件事：跨鏈同名表示可能由橋接關係連結，目的鏈 token 不能只按名稱視為獨立發行。身分卷宗只標示來源鏈、目的鏈與表示關係；供應去重、鑄造與鎖定的證據判讀交由供應量如何改變市值與 FDV一文處理。

BONK 與 WIF：mint、精度、權限、帳戶要分欄

Solana 文件把 token mint、decimals、mint authority、freeze authority 及 token accounts 列成分離概念。Mint 指向代幣類別；token account 記某個 owner 對該 mint 的持有狀態；精度決定原始整數如何顯示；鑄造權與凍結權又是不同控制欄位。把這些資料壓成一個「SPL 已驗證」會丟失可查問題。

BONK Paper 把 BONK 描述為 Solana 生態的 SPL token，這是初始專案文件對網路身分的陳述，不是今日供應或權限快照。WIF 的指定 Solscan URL 固定了一個 mint 觀察入口，靜態頁面可見 dogwifhat 標籤；本次直接回應沒有展開即時供應與 authority 值，所以卷宗只記入口與觀察限制，不補猜現況。

即使某個 mint authority 或 freeze authority 顯示 revoked，也只代表該欄位在該觀察時點的狀態。它沒有回答 metadata 來源、其他程式權限、流動池身分、持有人控制、供應商 mapping 或專案官方歸屬。權限欄是調查材料，不是安全分數。

FLOKI：兩個鏈別部署仍需要關係證據

Floki 專案網站在存取日稱 FLOKI 是 Ethereum 與 BSC 的 multichain token，並分列兩個合約。這足以要求調查表建立兩列鏈別身分，卻不足以把兩列視為同一鏈上物件、同一資料範圍或同一市場。兩個完整地址都要保留，且每一列都附專案來源日期。

供應商 mapping 也要另記。CoinGecko FAQ 顯示供應商會依資產的跨鏈關係界定彙整範圍；這只能解釋 CoinGecko 的分類框架，不能證明 FLOKI 當下已被某個 ID 完整收錄。若另一頁採不同 ID、地址集合或方法日期，就要為那個來源重新建立 mapping 紀錄。

身分矩陣：欄位並排而不作名次

下表只壓縮身分類型，沒有優劣順序，也不對任何資產評分。

| 範圍例子 | 原生或 token | 核心識別鍵 | 仍須分開保存的證據 | | --- | --- | --- | --- | | DOGE | Dogecoin 原生資產 | 原生網路與協議規則 | 協議來源日期、瀏覽器、供應商 ID、任何包裝關係 | | SHIB／PEPE | Ethereum 合約 token | 鏈別加完整合約 | 專案來源、瀏覽器狀態、provider mapping、指定 pool | | BONK／WIF | Solana token | 完整 mint | decimals、mint／freeze authority、token accounts、來源日期 | | FLOKI | 專案聲稱的多鏈 token | 每條鏈各自的完整合約 | 專案來源日期、provider ID 與收錄範圍、每鏈瀏覽器與 pool |

矩陣刻意沒有「verified」「holder count」或「老池」一欄作結論。這些欄位可被記錄，卻不能單獨證明所有權、真實性或安全。熟悉的 token standard 也只是技術介面；把多個弱線索堆在一起，不會自動變成一份官方地址聲明。

PEPE：從核准地址反查每一列資料

本站核准的 PEPE Ethereum 合約是 `0x6982508145454ce325ddbe47a25d4ec3d2311933`。研究表先保存提供這個地址的直接來源，再逐字核對 explorer、provider mapping 與每個 DEX pair；verified label、holder count、圖像或建池時間都不能替代完整合約。

任何沒有對到核准地址的市場列都留在隔離清單，不因代號相同而併入 PEPE 檔案。這是一個可重做的停止條件，不是自動判定真假或安全的工具。

案件重建二：FLOKI 雙鏈身分如何對齊供應商範圍

第二宗案件從 FLOKI 專案頁開始。存取日的頁面把 Ethereum 與 BSC 分成兩個鏈別項目，並各列完整合約；因此第一步是建立兩筆身分紀錄，逐字保存鏈標籤、地址、來源 URL 與日期。這一步不抄動態供應，也不因共用名稱與圖像就把兩個合約合成一筆。

第二步才檢查資料供應商。研究表要另列 provider ID、頁面實際收錄的鏈別地址、方法文件日期與尚未回答的範圍問題。CoinGecko FAQ 可以支持「供應商須按跨鏈關係決定收錄範圍」這個方法層主張，卻不能替 FLOKI 的當下 mapping 補值；如果頁面沒有明列其中一個地址，案件狀態就是待確認，而不是自行假設已合併或排除。

最後才把每條鏈的 pool identity 接回各自合約。即使兩邊共用品牌、provider ID 或 ticker，pool 仍按鏈、token 與 pair address 分列。這宗案件只完成專案聲明到供應商範圍的身分對齊，不從共同標籤推導真偽、安全或市場品質。

標籤和欄位不是認證書

調查常被一個醒目的正面欄位提前結束。Verified explorer label 受限於該瀏覽器的標註流程；renounced 或 revoked authority 只描述指定控制欄；熟悉的 ERC-20／SPL 介面說明相容方法；老 pair 只提供建立歷史；大量 holder 只是一組地址或帳戶計數。任何一項都沒有完整涵蓋專案歸屬、私鑰控制、跨鏈會計、合約行為與市場風險。

反方向也一樣：某欄未知不等於必然有問題。若 Solscan 靜態回應沒有展開 WIF authority，誠實紀錄是「本次直接讀取未取得」，而不是自行標成存在、撤銷或可疑。未知是下一次查核的入口，不是負面評語。

兩個來源衝突時，先看它們位於階梯哪一層。專案頁與 explorer 可能一個陳述歸屬、一個顯示鏈上欄位；供應商可能把多個地址放進同一 ID；池頁只列局部 pair。把衝突改寫成「哪一層、哪個日期、哪個欄位不同」，案件才有可驗證的後續。

身分紀錄卷宗：讓下一次查核可以接續

一份來源優先的身分紀錄，首行保存名稱與 ticker，但立即補上鏈、native／token 類型，以及完整 contract 或 mint。原生資產在地址欄寫明「不適用：原生鏈資產」，避免後來的人誤以為漏抄。每項官方陳述都附 URL 與來源日期，不用無日期的「官方」二字取代版本資訊。

第二組欄位保存 explorer URL、觀察時間、decimals、supply、mint authority、freeze authority 或合約 owner 等分離欄位。只有直接看到的值才寫入；verified label 另成一欄，不和 ownership 合併。若欄位不適用或未展開，分別記成不適用與未取得。

第三組欄位描述 bridge relationship：來源鏈、目的鏈、lock／mint 或 burn／mint 類型、對應合約、事件證據與仍未解的擔保問題。接著記 provider ID、供應商納入的鏈別地址、其去重方法與查閱日期。最後才列 pool identity，逐池保存 pair address、quote 與來源範圍。

卷宗末尾必須有 unresolved questions。它可能包括官方地址頁尚未找到、動態權限未展開、provider mapping 日期不明、橋會計與鏈上狀態尚未對上，或同名 pool 尚未確認代幣地址。這些問題不需要被勉強清空；清楚保留缺口，才使下一位研究者知道應直接打開哪一層證據，而不是重新被相同 ticker 帶偏。

同名代幣案件的可靠收尾不是一枚綠色勾號，而是一條可追溯的身分鏈。當名稱、網路、完整地址、日期、瀏覽器欄位、供應商 mapping 與 pool 各在自己的位置，研究者才能說明哪些物件確實相連、哪些只是外觀相似，以及哪些關係仍沒有足夠證據。