概述
FlareWatch 是一個 Next.js 應用程式，用於監控和追蹤 Flare Network 的部位——質押、委託、獎勵和收益。其定義性的架構事實是它是唯讀的：沒有存儲用戶財務狀態的後端數據庫、沒有交易簽署路徑，也沒有對用戶密鑰的程式化訪問。所有部位數據都是在請求時從 Flare 的鏈上基礎設施中獲得的。
錢包連接（Sign-In-With-Ethereum）僅用於識別要查詢的鏈上地址。它不授權鏈上操作，因為該應用程式沒有要授權的鏈上操作。
FlareWatch 讀取的內容及其來源
FlareWatch 使用的每個合約地址都在運行時從 FlareContractRegistry 解析，這是 Flare 的規範鏈上地址註冊表（0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019）。當 Flare 治理遷移合約時，FlareWatch 在下一個會話中無需代碼變更即可選擇新地址。
數據來源，按優先順序：
- 鏈上（FlareContractRegistry、P-Chain RPC、C-Chain RPC、FTSOv2 Oracle）——餘額、質押、可認領獎勵和價格的絕對真實來源。
- Flaremetrics API——驗證者和 FTSO 提供者的元數據，在客戶端計算成本太高。
- CoinGecko——多幣種價格數據和市值。
- Flare 區塊瀏覽器——用於稅務記錄和獎勵分類的歷史交易查詢。
分層數據流
該應用程式強制執行嚴格的單向分層規則：
services → stores → hooks → components → pages
| 層級 | 責任 |
|---|---|
| 服務 | 業務邏輯與數據抓取。純非同步函式。無 React。 |
| 儲存 | 反應式狀態 (Zustand)。保存數據，不抓取。 |
| Hook | 連接層。呼叫服務、寫入儲存。無業務邏輯。 |
| 元件 | 經由選擇器讀取儲存。渲染 UI。不抓取。 |
| 頁面 | 組成。排列功能元件。 |
實際效果是抓取、衍生與渲染各有單一歸屬。需要驗證者數據的元件訂閱驗證者狀態——它永遠不會直接呼叫 Flaremetrics API。
獎勵流
FlareWatch 追蹤四個獨立的獎勵流。將其中任何一個視為單一資金池會導致收益嚴重計算錯誤，因此每個都分別來源和計算。
| 流 | 節奏 | 到期 |
|---|---|---|
| FTSO委託獎勵 | 每個獎勵周期（~3.5天） | ~87.5 days |
| 驗證獎勵管理器（VRM） | 每4個獎勵周期（~14天） | 永不 |
| 鏡像質押（P-Chain → FSP） | 每個獎勵周期（~3.5天） | ~87.5 days |
| FlareDrop | 已結束 | — |
P-Chain質押本金在解鎖時返還，不是獎勵流，儘管它出現在帳戶餘額中。
收益估算
FlareWatch使用三層收益模型。每層在UI中都有標籤，以便用戶了解估計的精確度。
- 第1層——事實依據。通過RewardManager合約的鏈上可領取獎勵。這是真實的價值存放在鏈上，等待被領取。
- 第2層——數據驅動。當可領取為零時，FlareWatch使用錢包交易歷史中最近五次領取的中位數作為下一周期的估計。
- 第3層——公式備選。當不存在領取歷史時，
wflrBalance × FTSO_DELEGATION_APR / epochsPerYear從當前網絡狀態推算數學利率。
FlareWatch 為本機 Flare 質押和 FTSO 委託顯示單一 APY：最新獎勵紀元的每 FLR 支付額（扣除手續費）年化計算（× 365 / 3.5 天）。未複利計算，因為 Flare 獎勵必須先領取才能產生收益，並與其他 Flare 瀏覽器發布的數字一致。自動複利的 DeFi 部位（例如 Sceptre sFLR）顯示自己的協議 APY。
安全模型——一覽
安全性在 Security Features 頁面有詳細說明。重點是：
- 基於錢包的身分識別，而非帳戶。無密碼，無電子郵件關聯身分。錢包連線識別要查詢的地址。
- 設計上為唯讀。應用程式不持有金鑰、不簽署交易，也不代表使用者與智能合約互動。
- 伺服器端工作階段撤銷。登出在伺服器上執行，因此被盜用的工作階段 Cookie 在使用者登出後立即停止運作——而非在 24 小時後過期。
- 按錢包所有權控制存取。每條讀取或寫入錢包特定狀態的 API 路由都會驗證經過身分驗證的錢包是否與目標錢包相符。使用者資料沒有管理員覆蓋路徑。
- 縱深防禦 HTTP 標頭。Strict-Transport-Security、限制性 Content-Security-Policy、X-Frame-Options DENY 和嚴格 Permissions-Policy 隨每個回應一起發送。
測試
應用程式的測試方式假設每個回歸都會發生——因為 FlareWatch 關心的回歸類型（財務計算有細微錯誤）在發佈時是無聲的。覆蓋範圍：
- 質押和 FTSO 委託 APY 數學。
- 跨多個司法管轄區的貨幣格式。
- FLR 金額、百分比和日期格式。
- 閾值色帶邏輯（確保「綠色」交付永遠不會無聲地轉換為琥珀色）。
- 跨司法管轄區的稅務截止日期計算。
測試套件在每次推送時在 CI 中運行。
基礎設施
FlareWatch 運行在 Vercel 上。前端、預熱快取的 cron 任務，以及存放快取的 Redis 支援的鍵值存儲都共享該平台。這個選擇是刻意的：在規模上零運營成本，整個部署表面可通過一個提供商進行審計。
services/ 層刻意獨立於框架。如果 FlareWatch 曾從 Vercel 遷移，業務邏輯服務是純非同步函數，可隨之遷移。