Spike: Define backend-integration retry strategy and wallet-connection reliability model

[meshackyaro]

Description

Two compounding reliability gaps:

1. Silent mock fallback with no retry. pages/api/profile.ts and pages/api/usdc-price.ts fall back to hardcoded mock data on any fetch failure (network error, non-2xx, bad JSON), with no retry/backoff, and the source: 'mock' | 'backend' field they already compute is never surfaced in the UI — so users can't tell if they're looking at real or fake data. There's no evidence a real PROFILE_API_BASE_URL backend is deployed yet.

2. Fragile, single-wallet connection model. hooks/useAccount.ts polls Freighter via an un-backed-off setInterval(syncAccount, 2000) that never pauses on tab blur and never surfaces errors to the UI. components/atoms/wallet-button/index.tsx's "Switch account" just re-invokes setAllowed() without verifying the address actually changed. Freighter is the only supported wallet.

Component

Frontend

Difficulty

🟣 Spike — investigation required, scope not yet defined

Tasks

• Confirm the real backend API contract for /profile and /usdc-price (or equivalent) against the actual trustflow-backend endpoints
• Design a retry/backoff policy and a UI treatment for mock-vs-real/stale data
• Evaluate multi-wallet abstractions (e.g. Stellar Wallets Kit) against the current Freighter-only useAccount.ts
• Prototype a sounder connection lifecycle (backoff, tab-blur pause, verified account-switch, surfaced errors)

Acceptance Criteria

• A written recommendation for the backend-integration contract and retry/error strategy
• A written recommendation on multi-wallet support (adopt, defer, or reject, with rationale)
• A working prototype of the improved wallet-connection lifecycle
• Follow-up implementation issue(s) filed
• Any blocking unknowns flagged

Estimated Time

1-2 days (time-boxed spike)