개요
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
| 계층 | 책임 |
|---|---|
| 서비스 | 비즈니스 로직 및 데이터 페칭. 순수 비동기 함수. 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는 3단계 수익률 모델을 사용합니다. 각 단계는 UI에 레이블이 표시되어 사용자가 예측의 정확도를 이해할 수 있도록 합니다.
- Tier 1 — 확실한 정보. RewardManager 계약을 통한 온체인 청구 가능 보상입니다. 이는 청구를 기다리고 있는 온체인의 실제 가치입니다.
- Tier 2 — 데이터 기반. 청구 가능이 0일 때, FlareWatch는 지갑의 트랜잭션 기록에서 최근 5개 청구의 중앙값을 다음 에포크 예측으로 사용합니다.
- Tier 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에서 실행됩니다. 프론트엔드, 캐시를 워밍하는 크론 작업, 그리고 그러한 캐시를 보유하는 Redis 기반 키-값 저장소 모두가 동일한 플랫폼을 공유합니다. 이 선택은 의도적입니다: 규모에 따른 운영 비용 제로, 그리고 전체 배포 표면은 하나의 제공자를 통해 감사 가능합니다.
services/ 레이어는 의도적으로 프레임워크 독립적입니다. FlareWatch가 언젠가 Vercel에서 마이그레이션하더라도, 비즈니스 로직 서비스는 순수 비동기 함수이며 함께 이동합니다.