一個 SHIB 代號，四種供應證據：合約、地址、橋與供應商

同一個 SHIB 代號，同時出現在 Ethereum 合約、Shibarium 橋接表示、專案的銷毀敘述與供應商的供應卡。四個畫面都可能有數字，卻未必回答同一個問題：合約回傳的是哪個欄位、地址為何被分類、跨鏈表示是否已去重，以及供應商依哪一版方法呈現結果。

若先抄數字再找定義，研究表很容易把鎖在橋保管合約的單位當作已銷毀，把無法判定的地址當作不可存取，或把目的鏈表示再加進來源鏈供應。這篇文章改採證據帳本：每個主張都附鏈、合約、來源、時間與分類依據；沒有證據的欄位保留未知。

先鎖定 Ethereum 合約

本站 SHIB 身分清單限定 Ethereum 合約 `0x95ad61b0a150d79219dcf64e1e6cc01f0b64c4ce`，CoinGecko 供應商 ID 為 `shiba-inu`。CoinGecko 的合約欄把 `shiba-inu` 對應到 Ethereum，並以完整合約地址連向鏈上瀏覽器；這可核對供應商正在描述的資產身分，但不能替代指定區塊高度的鏈上狀態證明。

Shib.io 的 SHIB 專頁是動態專案來源。本次直接讀取只取得 token 導覽，能看到 SHIB、BONE、LEASH 與 TREAT 分列，沒有在可讀正文展開完整合約或跨鏈清單。因此，文章不把未呈現的動態行銷內容補回證據，也不因同一 ticker 出現在另一條鏈便擴充本站 manifest。

這個起點與同名代幣的網路身分調查互相銜接：鏈別加完整合約先固定研究對象，之後的 `totalSupply`、餘額、橋鎖定與供應商欄位才有共同座標。少了這一步，任何供應數字都可能屬於另一個同名合約。

totalSupply 只能回答合約欄位

ethereum.org 說明 ERC-20 介面包含 `totalSupply`、`balanceOf`、轉移與核准等方法。對已確認的合約及指定區塊，`totalSupply` 回傳一個鏈上欄位；`balanceOf` 則回傳某地址在同一狀態下的餘額。兩者可重現，但不會自帶地址用途的自然語言解釋。

一筆轉移到外界稱為 burn 的地址，可能只改變兩個地址餘額，而沒有呼叫會降低 `totalSupply` 的機制。反過來，合約若執行真正減少總供應的操作，鏈上欄位才會反映該規則。研究者要記的是事件和狀態變化，不是先接受社群標籤再倒推合約做過甚麼。

ERC-20 相容也不證明專案身分、合法性、擁有人、橋接關係或安全。標準回答介面可以做哪些事；精確合約回答正在查哪個物件；供應分類仍要靠其他證據。

鏈上欄位也需要重現座標。只抄 `totalSupply` 數字而不記區塊高度，後續便無法判斷差異是合約狀態改變，還是兩次查詢落在不同時間。若聲稱某事件造成減量，還要把事件交易、執行結果與事件前後的狀態連起來；單看最終餘額，無法證明中間原因。

五種地址類別不能互換

第一類是有鏈上減供應證據的 burn。第二類是收到單位、但私鑰是否不存在或不可用仍待證的地址；「多年未動」不足以把它升格為 burn。第三類是橋保管或鎖定帳戶，若橋機制允許返程解鎖，它與永久移除的經濟含義不同。

第四類是專案國庫、生態或其他指定用途持有。用途標籤需要專案文件、控制關係和日期，不能從大額餘額猜出。第五類是供應商排除：CoinGecko 方法會依其規則排除某些鎖定、歸屬期、國庫或核心持有人地址；這是供應商分類結果，不是鏈上憑空多出的一種代幣狀態。

同一地址可能同時被不同來源描述，但每個標籤都要有自己的證據欄。例如專案把地址稱為國庫，不表示供應商必然排除；供應商排除某餘額，也不證明它永久不可取回。分類衝突應保留來源與方法日期，不由作者選一個較好看的名稱覆蓋其他紀錄。

分類還有有效期間。地址控制者、用途或供應商規則可能改變，今日的國庫標籤不能倒填到所有歷史區塊。每次判定應保存證據發布日、首次適用日、最後核對日及撤回條件。若來源只給當下聲明而沒有歷史範圍，舊快照就保持未分類，不把新標籤當成回溯證明。

橋接會計不是第二份原生供應

Shiba Inu Documentation 把 Shibarium 描述為 Ethereum scaling network，並把網路貨幣列為 BONE。SHIB 因此不是 Shibarium 的原生 gas 資產；在目的鏈看見 SHIB 名稱時，仍要核對表示合約及橋接來源。

該專案的 Bridge Assets 文件描述 Ethereum 到 Shibarium 的一比一鎖定／鑄造流程：來源鏈單位離開一般流通範圍並受橋保管，目的鏈鑄造掛鉤表示；返程時目的鏈表示銷毀，來源鏈單位解鎖。文件稱這套設計不改變流通供應，但這句話只描述文件所指的橋機制，不是所有第三方橋或供應商的共同定義。

研究帳本應同時保存來源鏈合約、橋保管地址、目的鏈表示合約、事件方向、數量、時間與完成狀態。只有代號相同或數量相等，尚不足以證明兩端由同一橋支持；只有專案機制文件，也不能代替每筆事件或儲備狀態。

橋接途中還可能存在不同完成時點。來源鏈已鎖定而目的鏈尚未確認、目的鏈已銷毀而來源鏈仍待解鎖，都不能用一張最終流程圖掩蓋。快照若落在過渡階段，要列出兩端事件狀態及各自時間；否則暫時差額可能被誤寫成新增供應或永久短缺。

生態系名稱不能併成 SHIB

Shib.io 可讀導覽把 SHIB、BONE、LEASH 和 TREAT 分成不同項目。Shibarium 文件又把 BONE 列為網路貨幣。這兩項證據足以建立最低限度的分隔：共同品牌或同一生態系不會讓幾種代幣共用合約、供應或手續費資產身分。

SHIB 研究表只納入精確 Ethereum 合約及有證據連回它的橋接表示。BONE、LEASH、TREAT 要各自以鏈、合約、來源和用途證據另立檔案；其他鏈上出現的同名 SHIB 也保持獨立，直到正式對應關係獲得直接證明。

專案頁可能列出銷毀、產品、跨鏈部署或未來計畫。這些內容即使在另一個日期可見，也只先記為專案主張；不能從「銷毀」一詞推定供應持續下降，更不能把路線圖改寫成已完成的當下事實。

生態系角色也不能代替合約證據。某種代幣被描述為網路貨幣、治理或其他用途，只說明發布者的功能分類，不會改變 SHIB 合約的供應欄位。研究表若需要提及其他代幣，只記它們與問題的關係，不抄產品宣傳，也不把各自餘額加進 SHIB。

建立有日期的供應快照

一份可重查的快照先寫完整 Ethereum 合約、鏈識別碼或鏈名、區塊高度、鏈上時間與本地取得時間。接著分列 `totalSupply`、相關地址餘額和事件來源；任何經過換算的顯示單位都要保留小數位依據。若鏈上瀏覽器無法直接讀取，該欄記成「本次未取得」，不能用搜尋摘要補值。

地址分類表再為每一列保存地址、觀察餘額、類別名稱、類別證據 URL、證據日期及可否撤回的判斷基礎。銷毀、不可存取、橋鎖定、國庫／生態持有和供應商排除各自成欄；一個地址若只有標籤而沒有控制證據，就在可信度說明寫明限制，不把它搬到更強的類別。

橋接表至少記來源鏈、目的鏈、兩端合約、橋名稱、鎖定／鑄造或銷毀／解鎖方向、事件識別與狀態。這張表回答跨鏈表示的關係，不直接改寫來源鏈 `totalSupply`。未能對上的同名代幣留在隔離清單，不先視為正式 SHIB 表示。

最後才加入供應商層。記錄 `shiba-inu` ID、供應商頁面時間、本站取得時間、流通供應／總供應等欄位名稱、方法文件版本，以及供應商是否說明跨鏈去重。CoinGecko 的供應方法可以解釋其地址排除框架，卻不能替某個 SHIB 地址填入國庫、銷毀或不可存取。

這些欄位共同形成一份有日期的快照，而不是一個永遠有效的總數。下次更新時保留前一版，逐項比較合約狀態、地址證據、橋事件和供應商方法；若只覆寫最終數字，便無法知道差異來自鏈上變化、重新分類還是時間不同。

快照發布前可做一次閉合檢查：同一區塊下，分類表中的地址餘額是否與所聲稱的總集合相符；跨鏈表的來源鎖定與目的表示是否使用同一時間邊界；供應商值是否標出不同取得時間。閉合失敗不一定代表上游錯誤，但必須把差額和可能原因留在紀錄中。

燃燒紀錄先分辨兩種機制

合約函式可以直接減少 `totalSupply`，也有人把代幣轉入被認為無法花費的地址，但合約總供應未必改變。兩者都常被簡寫為 burn，對供應欄位的影響卻不一樣。記錄要保存交易 hash、呼叫函式、收件地址、事件與最後 state。

地址長期未移動或 explorer 標示 burn，都不能單獨證明密鑰不存在。專案與資料供應商如何分類該地址，也要分開記錄。若無法證實，只能寫成「被標示的燃燒地址」，不從循環供應自行扣除。

Shibarium 快照要同時保存兩邊

橋接敘述中的鎖定、鑑造、銷毀與釋放是四個不同動作。若要證明一筆 SHIB 橋接，來源鏈交易、目的鏈交易、兩邊合約 mapping、數量、狀態與時間都要能對上。只看目的鏈上的代幣數，不足以證明來源儲備。

專案文件所說的 1:1 是機制自述，不是每個時點的鏈上審計。若任一邊資料缺失，不把兩邊餘額加總成「全球 SHIB 供應」，也不把目的鏈銷毀當成 Ethereum SHIB 的永久減量。

資料供應商的循環數字要版本化

CoinGecko 等供應商可能因為 treasury、橋接保管、鎖定與燃燒地址分類而調整 circulating supply。鏈上沒有對應 mint 或 burn 時，數字仍可因方法改版而變動。快照因此保存 provider ID、欄位名、來源時間、擷取時間、方法版本與當時可得的分類說明。

舊值不被新值直接覆寫。變動原因若無公開說明，就留作「供應商分類變動，原因未證實」，不寫成新增發、隱藏供應或價格因果。

持幣人集中度要先辨認地址類型

大額地址可能是 DEX pool、交易所保管、橋接合約、treasury、燃燒地址或未知錢包。一個交易所地址可以代多位使用者保管，一位使用者也可以拆分多個地址。所以 address count 不是人數，top-holder 比例也不是終極控制比例。

分類要有官方文件、合約功能或可複核的保管說明。未知地址不為了完成餅圖而被硬塞入「團隊」。分布資料只描述指定區塊的可見狀態，不自動生成風險分數。

未解欄位要保留未知

供應研究最容易出錯的地方，不是算術少一位，而是把沒有分類的餘額硬塞進熟悉標籤。地址久未移動可能是長期持有、遺失、託管或其他情形；目的鏈代幣可能是官方橋表示、第三方包裝或無關同名物；供應商也可能尚未公開逐地址理由。證據不足時，這些狀態都叫未知。

未知不等於零，不等於已銷毀，不等於已鎖定，也不等於已證明無法使用。它同樣不構成合約或橋的正面保證。研究結論應列出下一次要直接查的來源與欄位，例如缺少哪個橋對應、哪個地址控制證據或哪一版供應商方法，而不是用單一形容詞把缺口藏起來。

不同來源若互相衝突，也不應用平均值消除矛盾。鏈上欄位、專案地址標籤、橋文件和供應商排除規則各自回答不同問題；紀錄要指出衝突發生在哪一層、哪個日期及哪個分類。只有新證據真正解答原問題時，未解欄位才可關閉。

SHIB 的供應快照只有在證據層彼此對齊時才有明確範圍：Ethereum 合約欄位說明鏈上狀態，地址證據說明分類，橋資料說明表示關係，供應商文件說明呈現口徑。讓四層保持可分、可追溯，才不會把同一代號底下的不同問題誤合成一個看似精確的答案。