Summary
Users need to know when a stuck order can be refunded. Add a read-only refund eligibility endpoint/helper that transaction history can consume without sending transactions.
High UX/safety value, manageable read-only implementation.
Scope
- Add a helper that computes refund eligibility from order status, timelock, direction, and current time.
- Optionally expose it through an existing order detail/history response.
- Include reason codes: not expired, already claimed, already refunded, eligible, unknown order.
- Add tests for ETH->XLM and XLM->ETH orders across statuses.
Guardrails
- Do not auto-submit refunds.
- Do not change contract calls.
- Do not mark an order refunded until on-chain evidence exists.
Acceptance criteria
- Frontend/API can show refund eligibility and reason.
- Tests cover status/time combinations.
- Existing history behavior remains compatible.
Wave complexity (maintainer)
High - 200 points
Summary
Users need to know when a stuck order can be refunded. Add a read-only refund eligibility endpoint/helper that transaction history can consume without sending transactions.
High UX/safety value, manageable read-only implementation.
Scope
Guardrails
Acceptance criteria
Wave complexity (maintainer)
High - 200 points