PEPE 的三本帳：代幣供應、LP 份額與資金池儲備

PEPE 專案頁列出一個代幣供應數，也寫有 LP token 已被銷毀的說法；市場上許多池合約又各自持有 PEPE 儲備。這三者看似都在談「有多少」，實際上分屬代幣合約、池份額合約與地址餘額三本帳。若把其中一項直接當成另一項，供應與流動性的結論就會在第一步錯位。

本文只研究本站核准的 Ethereum PEPE。專案文字保留發布者與日期，供應商數據保留口徑與取得時間，池資料保留精確交易對；任何缺少的狀態都維持未知。這不是替某個控制標籤背書，而是說明證據要如何對準它所描述的物件。

三種物件先分帳

第一本是 PEPE 代幣帳，核心欄位來自指定 Ethereum 合約。第二本是單一池的儲備帳：池合約地址像其他地址一樣，可以持有 PEPE，也同時持有報價資產。第三本是該池的份額帳；在 v2 型機制中，流動性供應者收到另一種代表其池內比例的 LP token。

三本帳可以互相影響，卻不共享單位。把 PEPE 轉入池，只是 PEPE 從一個地址移到另一個地址；鑄造 LP 份額，是池機制記錄對該池的相對權利；處置 LP 份額，也不等於呼叫 PEPE 合約的減供應機制。研究紀錄若只寫「token burned」，甚至沒有說是哪個合約，就無法判斷它改動了哪一本帳。

這個區分也說明為何專案所稱供應、LP burn 與多池儲備不能做一道加減題。供應是全合約欄位，儲備是供應內部的地址配置，LP 份額則是另一份合約狀態。只有先標明鏈、合約、地址、欄位及觀察時點，數字才有可比的語法。

合約身分是第一個座標

本站核准的 PEPE 身分是 Ethereum 合約 `0x6982508145454ce325ddbe47a25d4ec3d2311933`，CoinGecko 供應商 ID 為 `pepe`。CoinGecko 頁把該 ID 映射至這個 Ethereum 地址，能支持供應商身分對齊；它不是指定區塊的鏈上讀值，也不會驗證合約控制者或池的正當性。

CoinGecko 同頁可能列出其他鏈的表示。那些映射不會自動擴張本站核准身分，也不能把另一條鏈的供應、池或價格接到本研究。相同圖像、代號及供應商頁面都只是線索；本研究的每一列仍須以 `Ethereum + 完整合約` 作主鍵。

地址大小寫可因校驗格式不同而變化，但核對不能只看縮寫。若來源只展示頭尾字元，還需要能展開完整地址的直接來源；若池的 base token 不是上述完整合約，即使畫面顯示 PEPE，也不屬於本文的核准觀察。

身分紀錄還要和狀態紀錄分離。完整合約可以多年不變，供應、地址餘額與池儲備卻會隨區塊前進；研究者若只保存地址而沒有區塊，日後便無法重現當時讀值。反過來，只有數字而沒有完整合約，則連觀察的資產都不能確定。

ERC-20 欄位能證明甚麼

ethereum.org 的 ERC-20 文件列出 `totalSupply`、`balanceOf`、`transfer` 等介面。對已確認合約和指定區塊，`totalSupply` 回答合約在該狀態回傳的總量，`balanceOf` 回答某地址持有多少，轉移事件則能顯示單位從哪個地址移向哪個地址。

這些欄位不能自行解釋地址用途。池合約餘額不等於額外發行，外界稱為銷毀地址的餘額也不必然使 `totalSupply` 下降。要主張鏈上總供應減少，必須看到 PEPE 合約的相關機制、成功事件，以及前後狀態在相容的區塊邊界內發生變化；只見一次轉移不足以完成因果鏈。

ERC-20 相容性也只說明介面，不證明代幣身分、專案所有權、地址不可存取、合約安全或供應商流通分類。CoinGecko 的 total、circulating 與 max supply 依其方法呈現；這些供應商欄位不能倒過來當成 PEPE 合約在某個區塊的原始讀值。

地址餘額之和也要先界定集合。若只加幾個已知池、保管地址或大額地址，所得小計只能描述選取樣本，不能宣稱已覆蓋全部供應。差額應標為未涵蓋地址，而不是擅自命名成流通、鎖定或銷毀。

代幣單位、池內儲備與 LP 份額

Uniswap v2 的官方 Pools 文件說明，每個池是兩種 ERC-20 的交易場所；供應者存入兩端資產時會收到代表貢獻比例的 liquidity token。於是，同一個 v2 型池至少有三個需分開記錄的量：池地址的 PEPE 餘額、池地址的報價資產餘額，以及 LP token 的總量與持有人分布。

池內 PEPE 儲備是 PEPE 總供應的一部分，正如其他合約或一般地址的餘額。LP token 則是池份額的計量單位，並不是把池內 PEPE 再複製一次。即使兩種 token 都可由 ERC-20 介面觀察，合約地址、單位與權利對象仍完全不同。

「銷毀 LP」還可能指兩種不同動作。協議在取回底層資產時可以銷毀交回的 LP token；另一種說法則是把 LP token 送往被認為不可使用的地址，以限制某些份額的控制。研究必須辨認實際函式、收件地址、事件與後續狀態，不能只靠兩個字選定機制。

份額比例本身也依同一池的 LP token 總量計算，不能拿某池的份額除以 PEPE `totalSupply`。前者回答對局部儲備的相對權利，後者回答 PEPE 合約的總量欄位；兩個分母不同，產生的百分比沒有可替換關係。

銷毀 LP 份額不等於銷毀 PEPE

若持有人把某個池的 LP 份額送入經證實不可控制的機制，最直接的結論是那些特定份額的支配或取回能力受到限制。這項結論必須限定池、LP 合約、數量、收件地址、事件與時間；不能把一個池的狀態推廣到所有 PEPE 流動性。

份額控制受限也不保證池深永久不變。池儲備會隨協議機制與其他參與者的存取而改變；協議升級、費用設計、集中持有、錯誤合約、報價資產與市場活動仍是獨立問題。LP 份額去向更不等於稽核結果、價格穩定、合約安全或永遠可用。

最重要的是，LP token 的事件發生在份額帳，不會自動呼叫 PEPE 合約減少 `totalSupply`。除非另有 PEPE 本身的減供應證據，作者不得把「LP burnt」改寫成「PEPE 供應已銷毀」，也不得從控制標籤推導整個市場的永久性。

專案說法如何降格保存

PEPE 專案頁在存取日列出 `420,690,000,000,000` 的代幣供應，並使用無預售、零稅、LP token 已銷毀及合約所有權已放棄等措辭。這些可準確記成「專案於 2026-08-01 可讀頁面如此聲稱」，不可省略發布者後改成無條件事實。

驗證目前供應需要核准合約在指定區塊的 `totalSupply`、小數位及相關供應變化事件。驗證 LP 說法需要精確池與 LP 合約、份額總量、相關地址、轉移或銷毀事件及觀察時間。驗證所有權說法則需辨認合約的實際控制模型、角色或權限欄位及其當前狀態，不能只靠頁面標籤。

「零稅」也只能先記為專案在該頁的措辭。若要描述目前轉移行為，需要直接檢查核准合約的程式、可變參數與指定區塊狀態；即使一次觀察沒有額外扣減，也不足以證明所有路徑、所有時間或外部場所都具有相同結果。

即使某種放棄所有權的證據成立，也不會消除持有人集中、託管、池碎片化、錯誤合約、供應商分類、報價資產、協議或市場風險。專案頁的娛樂及不期待回報免責同樣只是其公開陳述，不構成其他技術主張的驗證。

流動性為何分散成多個局部觀察

DEX Screener 文件把 `chainId`、`dexId`、`pairAddress`、base／quote token、`priceUsd`、活動、成交量、`liquidity`、`fdv`、`marketCap` 與 `pairCreatedAt` 放在交易對資料結構。這正好說明一列池資料的自然範圍：某條鏈、某個 DEX、某個 pair、某種報價資產及某次取得。

PEPE 流動性可以沿上述維度碎片化。兩池即使 base token 都是核准合約，只要報價資產、手續費或機制不同，深度與局部價格便回答不同場所；若鏈或合約不同，更不能併入同一身分。單一回傳 pair 不代表全部池，加總可見池也不保證涵蓋全市場。

觀察範圍還要寫清資料選取方式。按代幣搜尋得到的 `pair`、預先核准的配對池與作者人工挑選的池，可能形成不同集合；若不保存選取規則，下次少一列時就無法判斷是池消失、資料源改變，還是查詢集合不同。

本節只把欄位接到 PEPE 的身分問題；資金池深度、滑價與成交量的通用讀法另見DEX 的流動性深度，此處不重複常數乘積的推導。`pairCreatedAt` 只表示建池時間，絕不能充當行情觀察時間。

全域資料與池資料分區呈現

CoinGecko 全域價格與核准 Ethereum PEPE 合約的 DEX 池價格分區顯示。本站不計算兩區差值；每筆池資料保留鏈、DEX、完整 `pair`、報價資產、來源與觀察時間。

全域 market cap 或 FDV 不與池層級同名欄位比較。任何 `null`、`missing` 或 `stale` 欄位都維持未知或不可用，不補成零，也不拿另一池代填。

未來觀察的證據帳頁

未來一次 PEPE 供應與流動性觀察，可用下列欄位形成緊湊帳頁；它保存證據座標，不輸出評分或判斷口號。

| 層次 | 必留欄位 | 不能由此推出 | | --- | --- | --- | | 代幣身分 | Ethereum、完整 PEPE 合約、區塊高度、鏈上時間、取得時間 | 官方性、安全或其他鏈表示 | | 供應狀態 | `totalSupply`、小數位、變化事件、前後區塊 | 供應商的 circulating 分類 | | 地址配置 | 完整地址、餘額、用途證據、證據日期 | 未分類地址等於銷毀 | | LP 份額 | 池與 LP 合約、份額總量、持有人、事件、機制 | PEPE 供應減少或永久深度 | | 池觀察 | chain、DEX、pair、兩端 token、報價資產、欄位狀態、觀察時間 | 全球 PEPE 流動性 | | 供應商觀察 | `pepe` ID、全域欄位、方法版本、來源時間與本站取得時間 | 指定池儲備或鏈上共識 | | 顯示邊界 | 全域與池資料各自的範圍、來源、觀察時間 | 額外差值 |

帳頁容許「未取得」「關係未知」與 `stale` 留在結果中。這些狀態不是瑕疵修辭，而是提醒下一次觀察缺哪一層證據；只有新來源真正對上相同合約、欄位與時間，該空格才可被更新。

更新時應保留舊列並新增觀察，而不是覆寫成沒有歷史的最新值。如此才能分辨供應變化、地址重新分類、池欄位缺漏與供應商方法修訂，也能讓任何比較回到當時實際可用的兩個時間戳。