アーキテクチャ

概要

FlareWatchはFlare Networkのポジション（ステーキング、デリゲーション、報酬、利回り）を監視・追跡するNext.jsアプリケーションです。アーキテクチャの特徴は読み取り専用であることです。ユーザーの財務状態を保持するバックエンドデータベース、トランザクション署名パス、ユーザーキーへのプログラムによるアクセスはありません。すべてのポジションデータはリクエスト時にFlareのオンチェーンインフラストラクチャから取得されます。

ウォレット接続（Sign-In-With-Ethereum）は、クエリする対象のオンチェーンアドレスを特定するためにのみ存在します。このアプリケーションには認可するオンチェーンアクション自体がないため、オンチェーンアクションを認可するものではありません。

FlareWatchが読み取るデータとその取得元

FlareWatchで使用されるすべてのコントラクトアドレスは、実行時にFlareの正式なオンチェーンアドレスレジストリであるFlareContractRegistry（0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019）から解決されます。Flareガバナンスがコントラクトを移動すると、FlareWatchはコード変更なしに次のセッションで新しいアドレスを取得します。

データソース（優先度順）：

• オンチェーン（FlareContractRegistry、P-Chain RPC、C-Chain RPC、FTSOv2 Oracle） — 残高、ステーク、請求可能な報酬、価格の信頼できるソース。
• Flaremetrics API — クライアント側での計算にはコストが高すぎるバリデーターおよびFTSOプロバイダーのメタデータ。
• CoinGecko — 多通貨価格データおよび時価総額。
• Flare Block Explorer — 税務記録と報酬分類のための履歴トランザクション検索。

階層化されたデータフロー

アプリケーションは厳格な一方向レイヤリングルールを適用します:

services → stores → hooks → components → pages

実際の効果は、フェッチング、派生、レンダリングがそれぞれ単一の場所を持つことです。バリデーターデータが必要なコンポーネントはバリデーターステートをサブスクライブします — Flaremetrics API を直接呼び出すことはありません。

報酬ストリーム

FlareWatchは4つの独立したリワードストリームを追跡します。これらのいずれかを単一プールとして扱うと、大幅な利回り計算の誤りが生じるため、それぞれが個別にソースおよび計算されています。

P-Chainステーク元本はロック解除時に返却され、アカウント残高に表示されても報酬ストリームではありません。

利回り推定

FlareWatchは3段階の利回りモデルを使用しています。各段階はUIで表示され、ユーザーが推定値の精度を理解できるようになっています。

• 段階1 — 確定情報。RewardManagerコントラクト経由のオンチェーン請求可能報酬です。これはオンチェーンに存在する実際の価値であり、請求されるのを待っています。
• ティア 2 — データ駆動型。請求可能額がゼロの場合、FlareWatch はウォレットのトランザクション履歴からの過去 5 回の請求の中央値を次エポックの推定値として使用します。
• ティア 3 — フォーミュラフォールバック。請求履歴が存在しない場合、wflrBalance × FTSO_DELEGATION_APR / epochsPerYear は現在のネットワーク状態から数学的な利率を投影します。

FlareWatch は、ネイティブ Flare ステーキングおよび FTSO デリゲーションに対して単一のAPYを表示します。最新報酬エポックのFLR当たりのペイアウト（手数料控除後）を年率化（× 365 / 3.5日）したもの。複利ではありません。Flare 報酬がクレーム前に収益を生むことはできず、他の Flare エクスプローラーが公表する数値と一致するためです。自動複利するDeFiポジション（Sceptre sFLR など）はそれ自体のプロトコルAPYを表示。

セキュリティモデル — 概要

セキュリティについては セキュリティ機能 ページで詳細に説明されています。重要なポイントは以下の通りです:

• ウォレットベースのアイデンティティ、アカウントではありません。パスワードなし、メールリンクのアイデンティティなし。ウォレット接続により、クエリするアドレスが識別されます。
• 設計上読み取り専用。アプリはキーを保有せず、トランザクションに署名せず、ユーザーに代わってスマートコントラクトと相互作用することはありません。
• サーバーサイドセッション取り消し。サインアウトはサーバーで強制されるため、盗まれたセッションクッキーはユーザーがサインアウトするとすぐに機能を停止します — 24 時間の有効期限での失効ではありません。
• ウォレット単位の所有権ゲーティング。ウォレット単位の状態を読み取りまたは書き込みするすべての API ルートは、認証されたウォレットがターゲットウォレットと一致することを検証します。ユーザーデータに対する管理者オーバーライドパスはありません。
• 多層防御 HTTP ヘッダー。Strict-Transport-Security、制限的な Content-Security-Policy、X-Frame-Options DENY、および厳格な Permissions-Policy がすべてのレスポンスに付属しています。

テスト

アプリケーションは、すべてのリグレッションが発生することを想定して テストされています — FlareWatch が懸念するリグレッションの種類 (財務計算がわずかに間違っている) は出荷時にはサイレントだからです。テストカバレッジ領域:

• ステーキング・および FTSO デリゲーション APY の計算。
• 複数の地域における通貨フォーマット。
• FLR 金額、パーセンテージ、日付フォーマット。
• 閾値の色分けロジック（「緑」のデリバリーが静かに琥珀色に変わることがないようにする）。
• 複数の管轄区域にわたる税務期限の計算。

テストスイートは毎回のプッシュ時にCI内で実行されます。

インフラストラクチャ

FlareWatchはVercel上で実行されます。フロントエンド、キャッシュをウォームアップするcronジョブ、およびそれらのキャッシュを保持するRedisバックアップのキー値ストアがすべてプラットフォームを共有しています。この選択は意図的です。スケールでのゼロ運用コストと、デプロイメント全体が1つのプロバイダーを通じて監査可能です。

services/レイヤーは意図的にフレームワークに依存しません。FlareWatchがVercelから移行する場合、ビジネスロジックサービスは純粋な非同期関数であり、それとともに移行します。

詳細情報

• セキュリティ機能 — 認証、認可、レート制限、ヘッダー、監査履歴。
• セーフガード概要 — FlareWatchが自身に強制するアーキテクチャルルールと、その理由。