研究方法
自建代幣解鎖追蹤表，該設哪些欄位？
把代幣解鎖追蹤表分成專案檔案、解鎖事件與查核紀錄三層，逐層列出該設的欄位、取數來源與複查節奏，避免不同口徑的供給量被混在一起。
為什麼要自己建表，而不是信任單一一個數字
同一個代幣，在兩個數據站查到的供給量常常對不起來。多數情況不是哪一邊算錯，而是各家對「供給量」的涵蓋範圍定義不同。
2026 年 9 月 22 日擷取的 Etherscan ARB 合約頁。同一個畫面上，兩個市值數字相差將近 29 倍。
仔細看這張圖。以每顆 0.217006 美元計算，「Onchain Market Cap」欄位的 50,160,397.91 美元，正好對應上方「Max Total Supply」的 231,147,516 顆 ARB。但「Circulating Supply Market Cap」卻是 1,471,708,406 美元，換算下來約 67.8 億顆。
兩者並不矛盾：前者算的是這個以太坊合約位址上的代幣數量，後者算的是整個網路的流通量，包含在 Arbitrum One 上的部分。如果你隨手把其中一個抄進筆記，卻沒有記下它是哪一種數字，一個月後你不會記得自己用的是什麼口徑，而所有以它為基礎的稀釋計算也就失去意義。
自建追蹤表要解決的正是這件事：它強迫你在同一時間記下數字本身、數字的涵蓋範圍、從哪裡取得、以及取得日期。
一張能用很久的追蹤表分三層
不要把所有東西塞進一張扁平的工作表。分成三層，你才能單獨更新其中一塊而不破壞其他部分。
第一層 — 專案檔案（每個代幣一列）。 幾乎不會變動的資訊：名稱、代號、發行鏈、合約位址、最大供給量、官方文件連結。
第二層 — 解鎖事件（每一批解鎖一列）。 真正產生供給壓力的就是這一層，一個代幣可能有數十列。
第三層 — 查核紀錄（每做一次複查一列）。 這層最少人做，卻決定了你的表半年後還算不算可信。
第一層：專案檔案要有哪些欄位
| 欄位 | 填什麼 | 到哪裡取 |
|---|---|---|
| 代幣 | 名稱與代號 | 官方文件 |
| 發行鏈 | 合約所在的原生鏈 | 區塊瀏覽器 |
| 合約位址 | 完整貼上，不要縮寫 | 區塊瀏覽器 |
| 最大供給量 | 絕對顆數 | 專案文件 |
| 該合約上的供給量 | 就是該位址上的數量 | 區塊瀏覽器 |
| 流通量 | 註明由誰公布 | 具名來源 |
| 增發權限 | 有／無／已鎖定 | 合約原始碼 |
| 文件連結 | 代幣經濟文件網址 | 官方頁面 |
「該合約上的供給量」與「流通量」必須分成兩欄，理由就是上面的 ARB 例子。跨鏈發行的代幣如果把兩者併成一欄，就是最大誤差的來源。
「增發權限」這欄不要憑感覺填。如果你還沒打開合約原始碼確認，請寫「尚未查核」而不是「無」。一個誠實的空格比一個錯誤的答案有用得多。
第二層：解鎖事件要有哪些欄位
| 欄位 | 填什麼 |
|---|---|
| 配置族群 | 團隊、投資人、基金會、社群等 |
| 歸屬起算日 | 具體日期，不要寫「TGE 之後」 |
| 鎖倉期長度 | 以月為單位 |
| 歸屬期長度 | 以月為單位 |
| 解鎖型態 | 一次性解鎖、線性、或混合 |
| 解鎖日期 | 這一批的日期 |
| 本批代幣數 | 絕對顆數，不要用百分比 |
| 佔總供給比例 | 註明分母是總供給 |
| 來源 | 網址或歸屬合約位址 |
| 可信度 | 官方文件／合約／推算 |
這一層有兩個重點。
第一，一律以絕對顆數為原始單位，百分比只能當成衍生欄位。以總供給為分母的百分比，和以流通量為分母的百分比不能相加；保留絕對數字，你什麼時候加總都不會出錯。
第二，「歸屬起算日」要填真實日期，不是「TGE 日」。同一個專案裡，不同配置族群的起算日完全可能不一樣。如果你還不清楚鎖倉期、線性歸屬與混合型態之間的差別，建議先回頭看TGE、初始解鎖與 Cliff 的判讀方式，再來填這一層。
「可信度」是成本最低、卻最有用的一欄。當你面對兩個互相衝突的數字時，你需要立刻知道哪一個來自正在運行的合約，哪一個只是來自某篇整理文章。
第三層：查核紀錄
每一列只要四欄：查核日期、查核了哪一列、有沒有變動、由誰或哪個來源確認。
解鎖排程並非永遠固定。專案可能透過治理投票延長歸屬期、在不同基金會錢包之間移轉代幣，或是修訂自己原本的文件。你的表若沒有查核紀錄，就不會察覺某個數字是在哪一刻悄悄過期的。
實際能長期維持的複查節奏：
- 每月： 流通量與該合約上的供給量。
- 每次大額解鎖之前： 拿該批的代幣數量回頭核對歸屬合約。
- 每季： 重讀官方文件，確認條款有沒有被修改。
數字互相打架時的比對流程，在如何查證官方代幣解鎖資料來源一文中有更完整的說明。
三個最常被漏掉的欄位
取數日期。 沒有日期的供給量數字毫無意義。這一欄要緊貼在每個會變動的數字旁邊，不要擺到表格最後。
數字的涵蓋範圍。 「2.31 億」到底是什麼：單一合約上的供給、全網總供給，還是流通量？直接寫進格子裡，不要靠記憶。
衝突註記。 當文件與合約說法不同，不要把落選的那個數字刪掉。兩個都留著，並寫下你採用另一個的理由；下次再遇到時，你就不必從頭查起。
用四個問題檢查你的表
- 隨便挑一個數字：你能在一分鐘內重新打開它的來源嗎？
- 有沒有哪一格只寫了百分比，卻沒有附上絕對顆數？
- 表裡最舊的那個流通量數字，是什麼時候取的？
- 有沒有哪一格其實是你在猜，卻沒有標記為推測？
如果第 1 題答「不能」，或第 4 題答「有」，這張表還不足以拿來做決策——它目前只是一堆看起來很確定的數字。
熟悉這個三層結構之後，下一步是用它推導出隨時間變化的供給曲線；相關基礎可以參考從總供給量讀到解鎖排程的代幣經濟判讀法。
查證來源
- etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1 — 以太坊上的 ARB 合約頁：Max Total Supply、Onchain Market Cap 與 Circulating Supply Market Cap，2026 年 9 月 22 日擷取
- docs.arbitrum.foundation/token-supply — ARB 供給量與配置排程的官方文件
每個來源只支持上文引用的那個範圍。截圖中的市場數字持續變動，也不構成任何對價格的判斷。
資料查核時間：2026-09-22T18:50:00+08:00