Summary
Add frontend order recovery from the coordinator API so pending/refundable swaps survive page reloads instead of relying only on local UI state.
Context
- The frontend has refund UI and transaction history components, but recovery across reloads depends on what the browser still knows.
- The coordinator persists order state and is the right source for reconstructing pending/refundable swaps.
- This improves the core safety promise: users can return later and still see how to claim or refund.
Scope
- Add a small frontend service/hook to fetch orders for the connected Ethereum/Stellar addresses from the coordinator.
- Merge recovered orders into
TransactionHistory without duplicating locally created orders.
- Surface refundable status into
RefundDialog when the recovered order has enough on-chain metadata.
- Add tests for reload/recovery and duplicate suppression.
Acceptance criteria
Pointers
frontend/src/components/TransactionHistory.tsx
frontend/src/features/refund/RefundDialog.tsx
frontend/src/lib/sdk-context.ts
frontend/src/lib/useNetworkMode.ts
coordinator/src/server/routes/orders.ts
packages/sdk/src/types/index.ts
Complexity
Medium (frontend state + API integration)
Summary
Add frontend order recovery from the coordinator API so pending/refundable swaps survive page reloads instead of relying only on local UI state.
Context
Scope
TransactionHistorywithout duplicating locally created orders.RefundDialogwhen the recovered order has enough on-chain metadata.Acceptance criteria
Pointers
frontend/src/components/TransactionHistory.tsxfrontend/src/features/refund/RefundDialog.tsxfrontend/src/lib/sdk-context.tsfrontend/src/lib/useNetworkMode.tscoordinator/src/server/routes/orders.tspackages/sdk/src/types/index.tsComplexity
Medium (frontend state + API integration)