FlareWatch

架构

FlareWatch 的构建方式。一个只读应用,直接从 Flare 的链上注册表读取数据,从不托管资金,也从不代表用户签署交易。

上次更新于 May 2026

概述

FlareWatch 是一个 Next.js 应用,用于监控和追踪 Flare Network 的头寸——质押、委托、奖励和收益。其架构的决定性特征是它是只读的:没有后端数据库持有用户财务状态,没有交易签署路径,也没有对用户密钥的编程访问权限。所有头寸数据都在请求时从 Flare 的链上基础设施获取。

钱包连接(以太坊登录)仅用于识别要查询的链上地址。它不授权链上操作,因为该应用没有链上操作需要授权。

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)。保存数据,不进行获取。
钩子连接层。调用服务,写入存储。不包含业务逻辑。
组件通过选择器从存储读取。渲染 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 使用钱包交易历史中最近五次领取的中位数作为下一个 epoch 的估计值。
  • 第 3 层 — 公式回退。当不存在领取历史时,wflrBalance × FTSO_DELEGATION_APR / epochsPerYear 根据当前网络状态推算数学收益率。

FlareWatch为原生Flare质押和FTSO委托显示单一APY:最新奖励周期的每FLR支付(扣除费用后),年化(× 365 / 3.5天)。它未复利,因为Flare奖励必须先领取才能获利,并匹配其他Flare浏览器发布的数字。自动复利的DeFi头寸(如Sceptre sFLR)显示其自身的协议APY。

安全模型 — 快速概览

有关安全性的详细信息请见 安全功能 页面。主要要点如下:

  • 基于钱包的身份认证,非账户制。无密码,无邮箱绑定身份。钱包连接确定要查询的地址。
  • 只读设计。该应用不持有密钥,不签署交易,不代表用户与智能合约交互。
  • 服务端会话撤销。登出在服务器端强制执行,因此被盗会话 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,业务逻辑服务是纯异步函数,可随之迁移。

延伸阅读

  • 安全功能 — 身份验证、授权、速率限制、请求头、审计历史。
  • 保障概述 — FlareWatch对自身实施的架构规则及其原因。
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.