概述
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,业务逻辑服务是纯异步函数,可随之迁移。