Token Analysis：Solana 迷因幣的即時籌碼監控與交易系統

在 Solana 鏈上交易過迷因幣（那種純靠情緒和資金驅動的投機代幣）的人都熟悉這種場面：價格在漲，圖很漂亮，但你不知道這根 K 線背後是誰在買。是一群真實的人陸續進場，還是同一個人用十個錢包左手倒右手？大戶在加碼，還是一邊拉價一邊悄悄出貨？K 線只告訴你結果，不告訴你結構。等你從結果看出不對勁，你通常是最後一個知道的人。這篇要拆的 Token Analysis，就是我為此寫的系統。

---

問題：帳本全公開，為什麼還是看不清？

弔詭的是，這一切明明都攤在陽光下，鏈上帳本全公開，誰買誰賣都查得到。問題出在兩件事，量太大，帳不能斷。在 Solana 最大的迷因幣發射台 Pump.fun 上，交易以肉眼追不上的速度湧出來，偏偏「每個錢包的持倉成本」這種結構性資訊，得從第一筆交易開始連續記帳，中間漏掉一段，後面的成本全是錯的。

時間也不站在你這邊。新發射的池子約八成在十分鐘內死亡，留給你判斷的時間是用分鐘在算的，開著區塊瀏覽器手動翻紀錄等於放棄。市面上的看盤工具大多停在價格和成交量，因為把交易流連續還原成籌碼結構這件事，工程上又髒又重。帳本是公開的，只是沒有人替你記帳。

---

持有者名冊：分析與交易的共同根據

所以我自己來記。Token Analysis 是一套監控 Solana 迷因幣的即時鏈上分析與交易系統，它不回答「價格會不會漲」，它維護的是一份名冊：這個幣此刻的持有者是誰，各拿多少，成本多少，是什麼來歷。名冊在手，「早期低成本錢包正在出貨」「歷史勝率高的錢包開始進場」這類判斷才有根據。這些判斷系統自己也拿來用，先丟進模擬倉驗證，再接上真金白銀的自動下單。

但在談任何分析之前，整個系統先被一個很土的問題定了形：哪些部分允許死機？

---

程序切分：收數不能停，分析隨時重啟

答案是一半允許，一半永遠不允許。分析和交易邏輯需要天天改天天重啟；收數據卻一秒都不能斷，因為鏈上事件漏過就是永久漏過，事後只能回補鏈上還查得到的近期紀錄。這兩種性格塞在同一個程序裡，每次改策略都在漏數據。所以我沿著這條線把系統切成獨立程序。下面這張圖講的是一筆鏈上交易從發生到變成買賣決策，中間經過誰。

 Helius WS ×2       TxSwap WS      TxTransfer WS    PumpPortal WS
 (獨立帳號監聽 swap)  (swap 程式)    (SPL 轉帳)       (官方源, fallback)
      │                │               │                │
      └────────────────┴───────┬───────┴────────────────┘
                               ▼                Alchemy RPC 補漏輪詢
      ┌── Pipeline: 收數據程序, 永久運行 ──┐    (每 5 分鐘核對追蹤中代幣)
      │  解析交易 → 去重 → 排序           │◄────────────┘
      │  → 更新記憶體狀態 + 即時算指標     │
      └──────┬──────────────┬────────────┘
             │ 批次寫入      │ 本地 WS 廣播即時事件
             ▼              ▼
      SQLite (本機檔案)   Server: 分析程序, 隨時可重啟
             ▲            策略評分 / 模擬倉 / API 推送
             └─重啟時灌回狀態─┘         │
                        ┌──────────────┴────────┐
                        ▼                       ▼
                  Web 與 TUI 前端        實盤引擎: 獨立資料庫,
                                        全系統唯一能簽名下單的模組

最上排是四路即時連線加一路事後核對，全部匯進永久運行的收數據程序（Pipeline），它把整理好的事件寫進本機資料庫，同時用本地廣播餵給隨時可重啟的分析程序（Server）。最下面，唯一有權簽名下單的實盤引擎被隔在自己的角落。依賴是嚴格單向的：前端只碰 API，分析層不碰收數層的內部，「能碰錢的程式碼」全部鎖在單一目錄裡。這條線切下去之後，每一塊有了各自要偏執的事。

---

多源冗餘：對同一筆交易聽四遍

Pipeline 要偏執的事只有一件：不能漏。名冊是逐筆累積出來的，漏一段就整本作廢，備援一條線遠遠不夠，所以四路即時連線同時聽：兩條掛在各自獨立帳號下的 swap 監聽（獨立帳號是為了不共享限流額度，避免被一起掐死），一條聽 swap 程式，一條聽代幣轉帳，接住不走標準路徑的持倉變化，官方事件源留著當整組失效時的 fallback。另外還留了一路事後輪詢，每五分鐘拿另一家供應商的 RPC 核對追蹤中代幣的近期簽名。刻意用不同家，是為了補漏這件事不去搶即時連線的限流額度。拿鏈上完整紀錄實測對照，落地覆蓋率在 99.8% 以上，名冊的誤差已經小到不影響結構判斷。

冗餘的帳單馬上寄到：同一筆交易會從好幾個來源各到一次，到達順序還不保證等於鏈上順序。去重和排序統一收在單一入口做，每一路來源都得先把自己翻譯成同一種事件形狀（SwapEvent）：

export interface SwapEvent {
  token: string
  wallet: string
  direction: 'buy' | 'sell'
  tokenAmount: number
  solAmount: number
  priceUsd: number
  priceSol: number
  blockTime: number
  signature?: string
  phase?: 'bonding' | 'migrated'
  source?: 'helius' | 'transfer-ws' | 'pumpportal' | 'backfill'
  slot?: number
  txIndex?: number
}

這個形狀裡有兩個欄位是被事故逼出來的。source 讓每一路數據源的貢獻和健康度可以分開計數，哪路斷了看指標就知道；至於 slot 加 txIndex，是因為到達順序不可信，批次寫入前要按鏈上順序重排。持倉成本是逐筆累加的，先買後賣的順序一錯，整本成本名冊就是錯的。

---

儲存層：指標在記憶體裡即時算

事件流乾淨了，下一個問題是算得夠不夠快。舊版指標走定時排程，每次推送要回頭查十幾次資料庫，對一個以分鐘定生死的市場來說太慢。改版後整個翻過來，每筆交易一到，當下就在記憶體裡同步更新持有者狀態、重算指標；資料庫退居二線，只負責持久化和跨程序讀取。代價也很實在，常駐約 400MB 記憶體，重啟時還要花約十秒把全部持有者狀態從資料庫灌回來，所以這套狀態只能住在永不重啟的 Pipeline 側。

更隱蔽的成本是記憶體裡只有「現在」，沒有歷史軌跡。回測需要的是「當時」，所以指標計算的入口（computeIndicators）保留了一條繞回資料庫的路：

export interface ComputeOpts {
  atTime?: number   // 回測模式: 以此時間點重建狀態, 強制走 DB 路徑
  layers?: Array<'fast' | 'mid' | 'slow'>
  prev?: IndicatorValues  // 部分重算時與上次結果合併
}

export function computeIndicators(token: string, opts?: ComputeOpts): IndicatorValues | null {
  if (opts?.atTime) return computeIndicatorsFromDb(token, opts)
  return computeIndicatorsFromMemory(token, opts)
}

同一支函式同時服務實盤與回測，是刻意的契約：兩邊共用同一份指標程式碼，而不是各寫一份再祈禱它們保持同步。layers 和 prev 這兩個欄位，承認的是指標有快慢之分：逐筆重算的只有快層，慢層拿上一次的結果直接合併，不必每筆交易全量重來。

---

實盤引擎：不信任任何回覆

指標和訊號到這裡都還是紙上作業；真正把錢送上鏈的實盤引擎，用的是完全相反的哲學：不信任任何回覆。

第一個不信任對象是自家資料庫。收數據程序高頻寫入，實盤開倉平倉也要寫，問題是這顆嵌入式資料庫同一時間只容一個寫入者，兩邊搶同一個檔案，下場就是鎖死。所以實盤紀錄搬進了完全獨立的資料庫檔案，用隔離換確定性；副作用是重置和關機邏輯從此要照顧兩個檔案，漏改其中一個就是隱患。

交易回覆本身也不可信。下單後遲遲等不到確認，是成交了還是失敗了？曾經有個版本把逾時當作成功，實測這個假設的準確率是 0%：每一筆「逾時即成功」的持倉都是幽靈倉。現在的契約反過來：逾時一律記為失敗，另外跑一個對帳程序（reconciler），每三十秒拿鏈上的實際紀錄，核對那些「宣告失敗但留有簽名」的交易，真的上鏈了就補建持倉。帳本可以短暫悲觀三十秒，不可以和鏈上事實漸行漸遠。

---

未解問題：回測與實盤的落差

這套不信任哲學救得了帳本，救不了一道更大的裂縫：回測和實盤之間的落差。同一套模型策略，回測帳面報酬 +6115%，實盤走完全程是 +1.3%。

不是程式寫錯。

是模型挑中的好幣人人都在搶，八筆進場有五筆根本買不進去；回測假設你出價就成交，於是它的獲利大多來自你實際買不到的那些幣。調參數修不了這個，它是回測框架看不見「搶不搶得到」這個維度的結構性盲區。

回測看到的勝率，不等於你拿得到的勝率。

盲區不全來自市場，也有我自己埋的。「記憶體只存現在」那個決定留下一道回聲：二十七個指標裡有十三個吃的是持有者狀態的當前快照，回測用資料庫重建的「當時」，和實盤上連續累積演化出來的狀態未必等價。修法想好了，定期落快照，但到現在還沒動手，這塊我一直不滿意。

系統本身仍在我自己的機器上長期運行，從監控、模擬到實盤下單的迴圈是通的。但兩道裂縫提醒的是同一件事：這種系統最危險的時刻不是它壞掉，而是它看起來運作良好。做這套東西是為了不再當那個最後知道的人，走到現在才發現，連自己的帳本也得防，它給你看 +6115% 的時候尤其要防。