Архитектура

Обзор

FlareWatch — это приложение Next.js, которое отслеживает позиции на сети Flare — стейкинг, делегирование, вознаграждения и доходность. Определяющим архитектурным фактом является то, что это приложение только для чтения: нет бэкенд-базы данных, хранящей финансовое состояние пользователя, нет пути подписания транзакций и нет программного доступа к ключам пользователя. Все данные о позициях получаются из инфраструктуры Flare в блокчейне во время запроса.

Подключение кошелька (Sign-In-With-Ethereum) существует только для определения того, какой адрес в блокчейне запрашивать. Оно не авторизует действия в блокчейне, потому что приложение не имеет действий в блокчейне для авторизации.

Что читает FlareWatch и откуда

Каждый адрес контракта, используемый FlareWatch, разрешается во время выполнения из FlareContractRegistry, канонического реестра адресов в цепи от Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Когда управление Flare перемещает контракт, FlareWatch подхватывает новый адрес при следующей сессии без изменения кода.

Источники данных в порядке приоритета:

• On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — источник истины для балансов, ставок, требуемых вознаграждений и цен.
• Flaremetrics API — метаданные валидаторов и поставщиков FTSO, слишком дорогостоящие для вычисления на стороне клиента.
• CoinGecko — данные о ценах в нескольких валютах и рыночная капитализация.
• Flare Block Explorer — исторический поиск транзакций для налоговых записей и классификации вознаграждений.

Многоуровневый поток данных

Приложение соблюдает строгое одностороннее правило слоистости:

services → stores → hooks → components → pages

Практический результат в том, что получение данных, производная и рендеринг имеют единую точку ответственности. Компонент, которому нужны данные валидатора, подписывается на состояние валидатора — он никогда не обращается к API Flaremetrics напрямую.

Потоки вознаграждений

FlareWatch отслеживает четыре независимых потока вознаграждений. Если рассматривать любой из них как единый пул, это приводит к значительному неправильному подсчёту доходности, поэтому каждый рассчитывается отдельно.

Основной капитал P-Chain возвращается при разблокировке и не является потоком вознаграждения, хотя он отображается в балансе счета.

Оценка доходности

FlareWatch использует трёхуровневую модель доходности. Каждый уровень помечен в интерфейсе, чтобы пользователь понимал точность оценки.

• Уровень 1 — источник истины. Требуемые награды на цепи через контракт RewardManager. Это реальная стоимость, находящаяся в цепи и ожидающая получения.
• Уровень 2 — на основе данных. Когда требуемое значение равно нулю, FlareWatch использует медиану последних пяти получений из истории транзакций кошелька как оценку для следующей эпохи.
• Уровень 3 — резерв формулы. Если история получений отсутствует, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear рассчитывает математическую ставку на основе текущего состояния сети.

FlareWatch показывает один APY для нативного стейкинга Flare и делегирования FTSO: выплата последнего эпоха вознаграждения на один 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 (финансовые расчёты, которые работают неправильно), молчаливо проходят в продакшене. Области тестирования:

• Математика APY стейкинга и делегирования FTSO.
• Форматирование валют в разных юрисдикциях.
• Форматирование размеров FLR, процентов и дат.
• Логика цветовых полос порогов (чтобы "зелёный" статус никогда молча не переключался на жёлтый).
• Вычисления налоговых сроков по юрисдикциям.

Набор тестов запускается в CI при каждом пуше.

Инфраструктура

FlareWatch работает на Vercel. Фронтенд, крон-задачи, которые прогревают кэши, и хранилище ключ-значение на основе Redis, которое хранит эти кэши, всё работает на одной платформе. Это сделано намеренно: нулевые операционные расходы при масштабировании и вся поверхность развёртывания проверяется через одного провайдера.

Слой services/ намеренно не зависит от фреймворка. Если FlareWatch когда-либо мигрирует с Vercel, сервисы бизнес-логики — это чистые асинхронные функции, которые мигрируют вместе с ним.

Дополнительное чтение

• Функции безопасности — аутентификация, авторизация, ограничение частоты запросов, заголовки, история аудита.
• Обзор защит — архитектурные правила, которые FlareWatch применяет к себе, и почему.