Overview

FlareWatch is a Next.js application that monitors and tracks Flare Network positions — staking, delegation, rewards, and yield. The defining architectural fact is that it is read-only: there is no backend database holding user financial state, no transaction-signing path, and no programmatic access to user keys. All position data is sourced from Flare's on-chain infrastructure at request time.

Wallet connection (Sign-In-With-Ethereum) exists solely to identify which on-chain address to query. It does not authorize on-chain actions because the application has no on-chain actions to authorize.

What FlareWatch reads, and where from

Every contract address used by FlareWatch is resolved at runtime from FlareContractRegistry, Flare's canonical on-chain address registry (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). When Flare governance moves a contract, FlareWatch picks up the new address on the next session without a code change.

Data sources, in priority order:

On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — ground truth for balances, stakes, claimable rewards, and prices.
Flaremetrics API — validator and FTSO provider metadata that is too expensive to compute client-side.
CoinGecko — multi-currency price data and market cap.
Flare Block Explorer — historical transaction lookups for tax records and reward classification.

Layered data flow

The application enforces a strict one-direction layering rule:

services → stores → hooks → components → pages

Layer	Responsibility
Services	Business logic and data fetching. Pure async functions. No React.
Stores	Reactive state (Zustand). Hold data, no fetching.
Hooks	Wiring layer. Call services, write to stores. No business logic.
Components	Read from stores via selectors. Render UI. Never fetch.
Pages	Composition. Arrange feature components.

The practical effect is that fetching, derivation, and rendering each have a single home. A component that needs validator data subscribes to validator state — it never calls the Flaremetrics API itself.

Reward streams

FlareWatch tracks four independent reward streams. Treating any of these as a single pool causes significant yield miscount, which is why each is sourced and computed separately.

Stream	Cadence	Expiry
FTSO delegation rewards	Every reward epoch (~3.5 days)	~87.5 days
Validation Reward Manager (VRM)	Every 4 reward epochs (~14 days)	Never
Mirrored-stake (P-Chain → FSP)	Every reward epoch (~3.5 days)	~87.5 days
FlareDrop	Concluded	—

P-Chain stake principal is returned at unlock and is not a reward stream, even though it appears in account balances.

Yield estimation

FlareWatch uses a three-tier yield model. Each tier is labeled in the UI so the user understands the precision of the estimate.

Tier 1 — Ground truth. On-chain claimable rewards via the RewardManager contract. This is real value sitting on-chain, waiting to be claimed.
Tier 2 — Data-driven. When claimable is zero, FlareWatch uses the median of the last five claims from the wallet's transaction history as the next-epoch estimate.
Tier 3 — Formula fallback. When no claim history exists, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear projects a mathematical rate from the current network state.

FlareWatch displays APR, not APY, for native Flare staking and FTSO delegation. Flare requires manual claiming, so rewards do not auto-compound. DeFi positions that auto-compound (such as Sceptre sFLR) are labeled APY.

Security model — at a glance

Security is covered in detail on the Security Features page. The headline points are:

Wallet-based identity, not accounts. No passwords, no email-linked identity. The wallet connection identifies which address to query.
Read-only by design. The app never holds keys, never signs transactions, and never interacts with smart contracts on behalf of the user.
Server-side session revocation. Sign-out is enforced on the server, so a stolen session cookie stops working as soon as the user signs out — not at its 24-hour expiry.
Per-wallet ownership gating. Every API route that reads or writes per-wallet state verifies that the authenticated wallet matches the target wallet. There is no admin override path for user data.
Defence-in-depth HTTP headers. Strict-Transport-Security, a restrictive Content-Security-Policy, X-Frame-Options DENY, and a tight Permissions-Policy ship on every response.

Testing

The application is tested as if every regression is going to happen — because the kinds of regressions FlareWatch cares about (financial calculations being subtly wrong) are silent when they ship. Coverage areas:

Staking and FTSO delegation APR math.
Currency formatting across multiple jurisdictions.
FLR amount, percentage, and date formatting.
Threshold colour-band logic (so a "green" delivery never silently flips to amber).
Tax deadline computations across jurisdictions.

The test suite runs in CI on every push.

Infrastructure

FlareWatch runs on Vercel. The frontend, the cron jobs that warm caches, and the Redis-backed key-value store that holds those caches all share the platform. The choice is deliberate: zero operational cost at scale, and the entire deployment surface is auditable through one provider.

The services/ layer is intentionally framework-independent. If FlareWatch ever migrates off Vercel, the business-logic services are pure async functions and move with it.

Architecture