FLOKI 雙鏈身分：合約關係、供應口徑與資料邊界

FLOKI 專案頁同時列出 Ethereum 與 BNB Smart Chain 的合約，卻不能因兩端共用品牌，就先把它們壓成一列資料。合併之前至少要回答五件事：觀察的是哪條鏈、哪個合約、兩合約有甚麼關係、數字屬於哪個範圍，以及供應商用甚麼方法處理重複表示。

如果關係尚未獲得直接證明，最準確的結果不是猜一個總量，而是保留兩筆鏈別局部觀察與一個未解的關係欄。這篇研究把「同一品牌」留在名稱層，把供應與市場數據放回可核對的鏈、合約、來源及時間。

一個品牌不能先合成一列

代號與圖像適合讓人辨認品牌，不適合當跨鏈資料主鍵。兩個 FLOKI 合約可能由某種正式關係連接，也可能需要不同的供應處理；在文件、事件與儲備證據到位前，作者不能從名稱相同推定兩端應相加、應去重或必然一比一。

「multichain」也是專案層敘述，不是完整會計式。它可以支持專案承認兩條鏈上的合約入口，卻沒有回答哪一端是來源、是否存在基準端、單位如何跨鏈、哪些地址扮演儲備，以及某個供應商是否把目的鏈表示排除於全域欄位。

因此，研究表不以 `FLOKI` 一欄收納所有觀察，而先拆成 `chain + contract + field + observedAt + source`。關係證據另成一層，只有在能連回同一對合約與相容時點時，才有資格影響聚合規則。

這種分列也能保留衝突。假如專案清單、供應商映射與鏈上回傳在某日沒有同步，紀錄應逐項標出差異及取得時間，而不是挑一個來源覆蓋其他來源。名稱層的一致性不能抹去狀態層的缺口。

兩條鏈上的精確身分

FLOKI 專案頁在存取日列出 Ethereum 合約 `0xcf0c122c6b73ff809c693db761e7baebe62b6a2e`，以及 BNB Smart Chain 合約 `0xfb5b838b6cfeedc2873ab27866079ac55363d37e`。CoinGecko 使用 API ID `floki`，並在同一資產頁映射 Ethereum 與 BNB Smart Chain。

這兩項來源可互相核對品牌與合約清單，但證據角色不同。專案頁是第一方身分陳述，CoinGecko 頁是第三方供應商映射；兩者都不是跨鏈事件日誌、儲備證明或供應去重稽核。完整地址不可由頭尾縮寫替代，鏈名也不能從頁面配色或圖像推斷。

Ethereum 一端可用 ERC-20 介面的 `totalSupply`、`balanceOf` 與事件建立鏈別局部狀態。這只描述指定 Ethereum 合約；不能把 ERC-20 相容性延伸成 BNB Smart Chain 合約的身分證書，更不能因此作安全或跨鏈關係結論。

兩個地址也各自需要來源歷史。若專案日後替換合約、增加表示或修改文件，舊觀察仍屬當時那組 `chain + contract`；新地址只能另開版本，不能把先前數據無痕搬到新合約。這能避免遷移、映射更新與供應變化被混成同一件事。

四層數據各答一題

第一層是鏈別局部合約數據：某鏈的某合約在指定區塊回傳的供應、地址餘額與事件。它最適合回答「這個合約此刻記了甚麼」，卻不會自帶跨鏈去重規則。

第二層是專案所述的 multichain 用語。它能指出專案如何列名兩個合約；若專案進一步發布關係文件，仍要保存文件版本、方向與適用合約，不能把行銷頁的一句話當成每筆狀態證明。

第三層是 CoinGecko 供應商全域觀察。本站即時模組中的全域價格、市值、FDV、成交量與供應欄位，代表 CoinGecko 在其方法與時間下對 `floki` 的呈現。它不是任一條鏈的原始 `totalSupply`，也不是兩個合約畫面的簡單相加。

第四層是 DEX 池局部數據。每列只描述某條鏈、某個 DEX、精確 `pair`、base／quote token 及取得時間。池價格、流動性、活動與可能缺少的欄位都留在該 `pair` 範圍；一個池不會因代號相同就替另一條鏈發言。

四層可以同頁並存，但不能互相填空。專案說「雙鏈」不會替供應商解釋聚合；供應商全域供應不會揭示某個儲備地址；池流動性也不能反推合約總供應。每層若缺來源或時間，就只關閉該層的結論。

跨鏈關係只能由證據分類

可能的第一類是多鏈原生發行：兩端各有原生供應規則，供應商可能按其方法加總鏈上供應並扣除各鏈排除項。第二類是 lock-and-mint：來源鏈單位被鎖定，目的鏈鑄造表示；若關係與儲備成立，供應商可按來源端基礎供應處理，避免把表示重複加入。

第三類是 burn-and-mint：來源端發生可驗證的減量，目的端依對應事件增量。這時供應計算需要事件前後與兩端觀察時間，不能把舊來源快照和新目的快照拼在一起。第四類是另一種被明確文件化的映射，例如不同儲備或轉換規則；它必須按自身合約與會計證據建模。

這些是待檢驗的關係類別，不是 FLOKI 現況標籤。FLOKI 白皮書的 multichain 章節在 2026-08-08 可讀，專案自述 token 位於 Ethereum 與 BSC，並稱集中式交易所提供兩鏈間的 1:1 swap。這能支持「專案如何描述兩個部署」；它沒有提供足以關閉分類的基準端、儲備及逐事件證據，不能代替鏈上審計。

關係也可能具有生效區間，而非永遠固定。一次遷移前後可能採不同規則，某座橋停用後仍留下歷史表示；所以文件日期、事件範圍與觀察區塊同樣重要。只保存「橋接」標籤而沒有有效期間，無法審計舊資料。

CoinGecko 方法是決策樹，不是結論

CoinGecko Supply Update FAQ 分開說明 native issuance on multiple chains、lock-and-mint、burn-and-mint，以及 bridged／wrapped representation 的處理。這能解釋供應商為何在不同證據條件下可能加總或去重，也說明供應商全域數字背後有分類決策。

FAQ 沒有在本次可讀內容中判定 FLOKI 屬哪一類。共享 `floki` ID 只表示供應商把相關映射放在一個產品實體下，不能反推每項供應處理正確，也不能證明其掌握所有儲備地址。方法文件屬 CoinGecko 口徑，不是所有供應商、專案或鏈的普遍法律。

若 CoinGecko 日後調整資產分類，研究紀錄要保存方法版本、觀察時間與差異來源。不能用新的供應商輸出回填舊區塊，也不能拿某條鏈的 `totalSupply` 去聲稱供應商全域欄位計算錯誤；兩者可能原本就在回答不同問題。

供應商的去重目的也不會使目的鏈觀察消失。表示合約仍可有自己的供應、餘額與池；只是特定全域統計可能依方法排除重複經濟單位。研究介面應同時容納局部可見與全域不重算，而不是刪除其中一端。

關係尚未解決時需要哪些紀錄

第一組證據是兩端的完整 `chain + contract`，加上各自區塊高度、鏈上時間與本地取得時間。第二組是關係文件：來源端與目的端、基準端、適用版本、轉換比例及例外情形，都要精確對到這一對合約。

第三組是會計證據。lock-and-mint 需要鎖定地址、控制模型、來源事件、目的鑄造事件及同一筆關係的數量；burn-and-mint 需要可驗證的減量機制、兩端事件順序與完成狀態。若聲稱另一種映射，則保存其儲備、銷毀／鑄造或發行規則，而不是硬塞進熟悉分類。

儲備證據至少要說清地址由哪個合約或角色控制、餘額對應哪個區塊、是否可被其他用途動用，以及它與目的端發行量如何逐筆或整體閉合。只看一個大額地址、長期未動或名稱標籤，不能證明它專門支持另一條鏈。

第四組是供應商納入規則：`floki` 頁採哪一版方法、哪些表示被追蹤、哪些被排除於全域聚合，以及變更何時生效。任一組缺漏，都應在關係欄留下未取得原因，不讓代號或專案口號替空格作答。

FLOKI 市場資料的展示邊界

CoinGecko 全域市場欄與 DEX 局部池欄分開呈現來源、範圍與時間，本站不計算兩區差值。Ethereum FLOKI 池與 BNB Smart Chain FLOKI 池也不會被寫成等價報價；共享品牌不會消除鏈、機制與場所差異。

每列池資料只描述自己的鏈、合約、pair、報價資產與觀察時間。全域 market cap 或 FDV 不與池層級同名欄位相比，缺少的欄位維持未知，不從另一條鏈或另一個池補入。

缺少池資料不是零

某個已核對的 Ethereum pair 回傳部分欄位，而 BNB Smart Chain 本次沒有取得合資格 pair 時，兩筆狀態要分開記錄；後者不能被改寫成流動性為零。

缺少一條鏈的池資料列，可能來自來源暫時失聯、`pair` 未納入、合約錯配、欄位為 `null` 或查詢範圍不同。它不證明該鏈沒有任何池，更不證明全球 FLOKI 流動性消失。`stale` 值則保留最後成功時間，不能偽裝成當下觀察。

同理，一個池的 `liquidity` 可用而 `marketCap` 缺失時，後者保持未知；另一個池或 CoinGecko 的全域欄位不能補洞。每個狀態要綁定自己的來源時間、`retrievedAt` 與範圍。

若來源恢復後才取得新值，也要新增一筆觀察，不把新值倒填到先前缺失的時間。這項時間紀律讓「當時未知」與「後來可得」同時成立，避免事後資料製造不存在的同步快照。

未來觀察的身分與範圍紀錄

未來一次 FLOKI 稽核可保存下列紀錄。它不是跨鏈操作說明，也不輸出價格比較、評分或單一總量結論。

| 紀錄區 | 必留內容 | 未解時的寫法 | | --- | --- | --- | | Ethereum 身分 | 完整合約、區塊、鏈上時間、欄位、來源 | `unverified` 或 `unavailable` | | BNB Smart Chain 身分 | 完整合約、區塊、鏈上時間、欄位、來源 | 不借用 Ethereum 結果 | | 關係證據 | 合約對、方向、基準端文件、儲備或事件、版本 | `relationship unknown` | | 專案陳述 | 精確 URL、發布者、存取日、原始範圍 | 標為專案說法 | | 供應商全域層 | `floki` ID、方法版本、納入／排除規則、來源時間 | 不倒推鏈別局部供應 | | 池局部層 | chain、DEX、`pair`、兩端 token、欄位狀態、觀察時間 | `missing`／`null` 不轉為零 | | 顯示邊界 | 全域欄與各鏈池欄分區、各自來源與時間 | 不做額外對照 |

這份紀錄的價值在於讓兩端合約即使共享品牌，仍保有各自可重查的座標。等到直接證據真正解決關係，更新的是關係分類與供應商規則；原始鏈別局部觀察不應被覆寫成一個失去來源的合併值。

每次更新還應保留前一版的合約清單、關係狀態與方法日期。如此才看得出差異源自鏈上事件、專案文件、供應商分類或資料缺漏，而不是讓「最新」一詞遮蔽整段證據歷史。