BONK 歷史分配與今日流動性：從文件標籤到逐池證據

BONK Paper 的歷史頁面把 5% 標成「Initial Liquidity Distribution」，今日一筆 DEX 資料則可能回報某個池的儲備。兩處都碰到流動性，卻不是同一數量，也沒有相同時間與範圍。前者是文件中的原始配置類別，後者是特定鏈、交易機制、成對帳戶與觀察時刻下的局部狀態。

若把兩者直接接成一條敘事，就會把「曾預留作某用途」誤寫成「現在仍在某池」，再把單一池誤稱為整個市場。BONK 特別需要反向操作：先保留歷史文字的矛盾，再逐層辨認鑄幣帳戶、代幣帳戶、供應商分類與池儲備，最後才判斷兩筆同刻證據能否並列。

一個百分比標籤不是一筆今日池儲備

歷史分配標籤回答的是文件當時如何命名一部分原始供應。它沒有列出今天仍存在的池清單、每個池的完整地址、報價資產、機制、儲備或取得時間。即使分類名稱寫著「初始流動性分配」，也不能用它替代今日池資料，更不能把名目比例套到任何一列即時欄位。

反過來，一個 DEX 池的資料列只回答該 pair 在某次觀察下呈現甚麼。它不會倒推出該池最初的資金來自哪個歷史分類，也不會證明提供資金的帳戶至今由同一受益人控制。兩邊若沒有地址、轉移事件及時間鏈接，最誠實的關係欄是「尚未建立」，不是用名稱相似補上一條連線。

這個區分也避免把池建立時間當成資料時間。`pairCreatedAt` 可以標示一個 pair 何時建立，卻不代表目前頁面何時讀到價格或儲備；後者必須另存實際 `observedAt`。少了觀察時間，池列只能標示時間未知。

從核准鑄幣帳戶鎖定研究主體

本網站只核准 BONK 的 Solana mint `DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263`。Solscan 在這個精確入口顯示 `Token Bonk` 標籤，CoinGecko 的資產 ID 是 `bonk`，並在資產頁映射 Solana 表示。這些資料共同固定本研究要追蹤的對象，但標籤本身不是所有權、完整性或安全保證。

Solana 文件把 mint account 與 token account 分開。前者保存代幣類型層的精度、供應與權限等狀態；後者保存特定持有關係下的餘額。資金池還會使用自己的帳戶組合與程式機制。研究若只寫 BONK 名稱，便無法分辨讀到的是鑄幣層、某個持有帳戶，還是一個 pair 的儲備。

本次 Solscan 靜態頁沒有露出 decimals、`mintAuthority`、`freezeAuthority`、供應或持有人餘額，因此這些欄位全部保持未知。協議文件能說明這些欄位各自存在及可能執行的操作，卻不能替指定 mint 填入現值。CoinGecko 頁另列其他鏈表示，也只代表供應商頁的映射；它不建立核准橋接、不證明去重，更不擴張本站的 Solana 身分。

把 Paper 留在歷史版本

BONK Paper 第 6 至 8 頁適合作為歷史設計紀錄，而不是今日帳本。文件稱 BONK 為 Solana 的 SPL token，並描述原始供應的一部分如何按類別配置；其中早期貢獻者的 21% 被寫成自 2023-01-01 起三年線性歸屬。這些都是「文件在該版本如此陳述」，不是「目前餘額已依名目時程完成某種變化」。

名目歸屬日程與實際鏈上餘額之間仍缺少執行證據。要判斷某時刻的狀態，至少要有對應帳戶、控制關係、轉移或解鎖機制與同時點讀數。只按日曆推算，會忽略地址是否更換、資產是否轉移、供應商如何分類，以及文件所述安排是否按原樣執行。

文件本身亦警告內容可能不完整或過時，第三方資料未經獨立驗證，也不承諾準確完整。BONK 專案網站可提供當前品牌入口與非建議、非招攬的免責脈絡，但頁面上的整合、產品、數字與行銷說法不應拿來修正歷史 PDF。版本衝突要並列保存，不能讓較新的網站替舊文件重寫數字。

可見標籤的兩道未調和算術

Paper 的敘事說四個社群分配群組合計 50%，但第 7 頁可見標籤是 21%、16%、10% 與 5%。按畫面上的整數做編輯算術，`21 + 16 + 10 + 5 = 52`。因此紀錄必須同時保留「文字寫 50」與「可見標籤加總 52」，狀態標為未調和。

第 8 頁另見早期貢獻者 21%、BONK DAO 16%、初始流動性分配 5% 與行銷 5%。若把前頁四個可見標籤的 52 再加上這四個可見標籤，則 `52 + 21 + 16 + 5 + 5 = 99`。這個 99 同樣只是對畫面標籤的算術，不是當前供應量，也不證明有一個可被作者指認去向的 1%。

研究紀錄不應把 52 改成 50、不應擅自將任何 5 改成 3，也不應假定隱藏小數會使總數閉合。它應保存原始措辭、頁碼、存取日、顯示值、算式與「未調和」狀態。差異可能來自文件錯誤、版本排版或其他未披露原因；現有證據無法選定其中一種。

六種看似相近卻不同的欄位

第一種是歷史類別標籤，描述文件如何分組。第二種是名目歸屬時程，描述文件預計如何隨時間安排某類額度。第三種是某時刻 token account 的鏈上餘額；它回答帳戶持有多少，未必回答背後有多少實益持有人。單一持有人可以使用多個帳戶，一個帳戶也可能由程式、多簽或受託關係控制。

第四種是供應商的 circulating supply 分類。CoinGecko Supply Methodology 將最大、總量、流通及其他供應分類分開，並可能依限制或用途排除某些帳戶。這是供應商方法，不是 BONK Paper 分類的自動延續，也不是看到某地址後便能自行套用的普遍規則。

第五種是某個池的代幣儲備，它屬於指定 pair 與觀察時間。第六種是 LP 位置或其控制關係；即使能看到份額，也不能只靠份額名稱判斷最終受益人。把六者放在同一張表時，每欄都要保留來源與時間，而不是用一個「分配」欄把它們摺疊。

持有人統計還有一層常被省略的實體關係。鏈上可以數 token account，卻不能只憑地址數量判斷獨立受益人數：同一人能分散使用多個帳戶，託管或程式帳戶也可能代表許多人的權益。反過來，一個標成 DAO 或儲備的名稱，也未必揭示簽署門檻、委派與最終控制者。若研究問題是「誰實際受益」，便需要超過餘額快照的控制證據。

所以可稽核表不應只有「地址、餘額」兩欄。它還要分開帳戶類型、標籤來源、標籤是否第一方、控制關係證據、最後觀察時間與不確定狀態。歷史類別可以作為待核對標籤，不能先指定給某個今日地址；供應商把某地址排除於流通分類，也不會自動證明該地址就是 Paper 中同名類別。

初始流動性分配不能代替池清單

Paper 的 5% 標籤最多支持歷史文件曾以初始流動性分配命名一個類別。它沒有證明今日有多少池、哪些 pair 延續當時資金、池餘額多少、LP 由誰控制、深度如何、週轉如何，或流動性是否永久留在原處。資金可能分散、遷移、退出、換成不同報價資產，亦可能停留在尚未投入池的保留帳戶。

因此研究今日流動性要從池身份往回建立，而不是從 5% 往前投射。每一列至少要有 Solana、完整 pair、核准 BONK mint 位於 base 或 quote 的位置、另一側代幣、DEX、池機制、來源與實際觀察時間。沒有這些座標，兩列看似同名的池也不能安全合併。

今日流動性必須逐池記錄

同一核准 mint 可以出現在不同 DEX、不同 pair 與不同報價代幣之中，池機制也可能不同。每個池的儲備、價格、交易量及流動性欄位只對該列有效。即使若干池都寫 BONK，也不能把其中最大的一列稱為全域流動性，或把多列在不同時間的值直接相加。

逐池紀錄也要避免把「有多少列」誤作深度品質。同一經濟位置可能被不同介面重複展示，而兩個真正獨立的 pair 也可能因報價代幣、費率或機制不同而無法直接合計。去重需要完整 pair 身分與來源規則；深度則需要特定方法與當刻資料。僅有池數、場所名稱或某個歷史分配比例，三者都無法代替這些觀察。

若要描述一段時間的變化，應保存多個帶時間的版本，而不是讓新值覆蓋舊值。每次觀察都附取得結果與欄位缺口，才能分辨真正變動、來源延遲及擷取失敗。慢速正文只解釋這套範圍，當前數值交由即時模組呈現。

池資料的缺失同樣有語意。`null` 或 `missing` 表示來源沒有提供可用值；`stale` 要保留最後成功時間；`failed` 要保留錯誤與來源。這四種狀態都不是零。換一個池補值會改變研究對象，拿供應商全域欄位補池值則會改變範圍。

CoinGecko 的全域價格由供應商方法與其市場輸入形成，DEX 池價則來自單一局部 pair。本站將不同範圍的資料分區展示，不計算彼此差值，也不讓它們互相充當流動性、供應或市值的替代欄。範圍標籤要跟著每一個數值走。

BONK 市場資料的展示邊界

CoinGecko 全域欄位保留供應商、範圍與更新時間；每個 DEX 池則保留核准 Solana mint、完整 pair、DEX、報價資產、來源與觀察時間。缺少地址、時間或欄位時，該筆資料標示未知或不可用，不用另一來源補齊。

全域 `marketCap` 或 `fdv` 不與池級同名欄位相比。本站也不生成池對池比較結果；不同 Solana mint、其他鏈表示或缺少 pair 身分的池不會併入核准 BONK 資料。

版本化的分配至流動性證據帳

一份可延續的 BONK 紀錄應讓歷史文件與當前觀察各有版本。文件列保存檔名、頁碼、原句角色、可見比例、存取日與未調和狀態；身分列保存鏈、完整 mint、供應商 ID 及映射限制；帳戶列保存帳戶類型、來源、控制關係是否已證明與實際觀察時間。

池列則保存 DEX、完整 pair、base、quote、機制、欄位來源、`observedAt` 與缺失狀態。任何把歷史分類連到今日帳戶的關係，都另存證據文件或事件，不由名稱自動生成。當來源互相衝突時，帳頁新增差異列，而不是覆蓋舊值。

版本之間還需要「為何改變」欄。若只是來源更正標籤，就不應改寫先前的鏈上餘額；若某帳戶真的轉移，則要保存事件與前後觀察；若供應商改變分類方法，應把方法版本與資產數值分開。如此才能避免把文件修訂、鏈上移動及供應商重分類誤當成同一事件。

這種版本化設計讓 50、52 與 99 保持它們本來的文件層身份，也讓一個今日池始終只代表自己的現場。研究成果不是把所有數字壓成一個答案，而是讓讀者看得出每項主張從哪個版本、哪個帳戶、哪種方法與哪個時刻而來。