Update deposit address refund logic

[ted-palmer]

No description provided.

[github-actions]

Claude finished @ted-palmer's task in 1m 45s —— View job

---

Code Review

• Read the PR diff
• Review against CLAUDE.md style guide
• Check for issues (accuracy, voice, tone, structure)
• Post review feedback

The PR tightens the non-solver-token refund story (correctly: "not currently recoverable" instead of vague "manual recovery") and surfaces relay.link/withdraw as the fallback for wrong-solver-currency deposits. Voice, callout length (§2.5), and table formatting (§2.7) all comply with the style guide. Three consistency issues to address before merge.

---

1. Contradicts existing text under "Strict Addresses" — features/deposit-addresses.mdx:896

The comparison table at line 61 now says strict-mode wrong-token (solver currency) is "Recoverable via relay.link/withdraw", but line 896 still reads:

Wrong token or wrong chain — Not supported. Strict addresses do not have automatic wrong-token or wrong-chain recovery paths.

A reader hitting both will see a contradiction. The "no automatic recovery" claim is technically still correct (withdraw is user-initiated), but the framing needs to mention the manual path to stay in sync with the new table row. Suggest:

- **Wrong token or wrong chain** — Not supported in the normal fill flow. No automatic recovery path; for wrong solver-currency deposits, users can recover funds at [relay.link/withdraw](https://relay.link/withdraw).

Fix this →

---

2. Conflicts with "Different Token (Solver Currency)" prose for open addresses — features/deposit-addresses.mdx:879

For the open + wrong-solver-currency case, the new table row points readers to relay.link/withdraw as the fallback. But line 879 (the prose explanation of the same scenario) still points to the reindex endpoint:

If a different supported token was sent and nothing happens immediately, use the reindex endpoint as a fallback.

These describe two different fallback mechanisms for the same situation. If both exist, the page should clarify when each applies (reindex looks operator-facing; relay.link/withdraw looks end-user-facing). Otherwise, an integrator reading top-down will be confused which to use. Recommend updating §"Different Token (Solver Currency)" to mention both and clarify roles.

Fix this →

---

3. "Refund Flows" enumeration says "two" but now covers three — features/deposit-addresses.mdx:908-915

The numbered list opens with:

There are two distinct refund scenarios:

1. Correct currency, fill failed …
2. Wrong currency (non-solver token) — Not supported and not currently recoverable.

…then the new <Info> callout immediately introduces a third scenario (wrong solver currency → relay.link/withdraw). The numbered list and the callout are now out of sync. Two options:

• Make it a three-item list: (1) correct currency / fill failed, (2) wrong currency (solver token) → withdraw, (3) wrong currency (non-solver) → not recoverable.
• Or keep the list at two but drop "distinct" and reframe as "The two automatic refund paths are…" so the Info callout reads as a manual-recovery footnote rather than a missing third bullet.

The three-item structure reads cleaner and matches the column structure of the comparison table above.

Fix this →

---

Smaller notes

• Asymmetric framing in the comparison table. The Open cell explains when withdraw applies ("the fallback if the auto-flow doesn't complete"), but the Strict cell just says "Recoverable via [relay.link/withdraw]" without indicating whether this is automatic or user-initiated. Consider matching the wording, e.g. "Manual recovery at relay.link/withdraw" — makes the action model clear without padding the cell.
• Style guide compliance. Voice, callout length (§2.5, well under 15 lines), and link formatting (§2.6, root-relative for internal / plain external link) all check out. The "users" subject in the Info callout (line 914) is correct usage per §2.3 since it refers to end-users distinct from the reader.
  • Branch

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	May 13, 2026, 7:20 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.