docs(drift): draft from internal source

[pedromcunha]

Drafted from an internal source repo, requested by @arcticfloyd1984.

This PR was auto-generated by the reusable-docs-draft-pr workflow from a Claude-drafted update in the source repo. It is opened as a draft — please review, edit as needed, and mark ready for review before merging.

Review checklist

• Content matches the behavior shipped in the source PR
• No internal-only details (service names, file paths, unreleased names, security internals) leaked into the draft
• Conforms to CLAUDE.md style rules
• Cross-references and internal links resolve
• Any Needs human input items from the source comment are addressed

---

Generated by reusable-docs-draft-pr.yml in relayprotocol/agents-config.

[mintlify]

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

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	May 7, 2026, 9:58 AM

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

[github-actions]

Claude finished @pedromcunha's task in 1m 44s —— View job

---

Code review

This PR documents an auto-refund-to-depositor opt-in: passing refundTo as the origin chain's "zero/sentinel" address (EVM 0x000…, Bitcoin bc1q…mql8k8, Solana 11111…) routes refunds to the original depositor. It touches three places: the Key Parameters table, the refundTo Configuration table, the CEX <Note>, and adds a new <Info> callout plus a Recommended Setup bullet. Content is accurate and internally consistent. Below are style-guide and clarity observations.

Issues

1. Same address triplet repeated three times — high duplication

The literal (EVM \0x0000…`, Bitcoin `bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmql8k8`, Solana `11111111111111111111111111111111`)appears verbatim on lines 26, 918, and 934. Once the row is added to therefundTo` Configuration table, the parameter table (line 26) and the Recommended Setup bullet (line 934) can refer back to it instead of restating it.

Suggested rewrite for line 26 (Key Parameters):

Address to send refunds if the transfer fails. Required for strict deposit addresses and for routes that include a destination-side swap. Pass the origin chain's zero/sentinel address (see Refund Behavior) to opt into automatic refunds to the original depositor. Omitting this on open addresses disables automatic refund.

Suggested rewrite for line 934 (Recommended Setup):

• Auto-refund to depositor: When users deposit from wallets they control, pass refundTo as the origin chain's zero/sentinel address (see the refundTo table) to auto-refund the original depositor. Track the first of the two resulting outTxs for refund delivery. Avoid this when deposits may originate from a centralized exchange.

This keeps a single source of truth in the table and avoids drift if a fourth chain family is added later.

Fix this →

2. "Native-currency address" framing is misleading on Bitcoin and Solana (§2.3, terminology clarity)

On EVM, 0x000… is a well-established convention for "native currency." On Bitcoin, bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmql8k8 is a Bech32 sentinel (all-zero witness program), and Solana 11111… is the System Program address. Neither is a "native-currency address" in any community sense — they're Relay-recognized sentinels. The doc currently presents all three under one label, which may lead an integrator to wonder which official source defines "the Bitcoin native-currency address."

Consider renaming to "zero/sentinel address" or "Relay's native-currency sentinel for the chain" on first mention, and keeping the literal values colocated in the table only.

3. Wide first column in the refundTo Configuration table (§2.7)

The new row on line 918 puts a long prose label plus three backticked addresses into the refundTo value column, which now visually dominates the table. CLAUDE.md §2.7 says "Keep cell descriptions concise; move long explanations into prose below the table."

Option: shorten the first cell to e.g. Origin chain's zero/sentinel address and move the three concrete values into a one-line sentence immediately below the table (or into the existing <Info> callout that already discusses this case). The behavior cell can keep the full chain-support detail.

4. New <Info> callout could be tighter and active-voice (§2.3)

Current (lines 926–928):

When auto-refund to the original depositor is triggered, the request's outTxs will contain two refund transactions. The first transaction is the solver-to-depositor transfer that actually returns funds to the depositor — this is the one to track from your integration. The second is an internal protocol-settlement transaction that does not move user funds and can be ignored by integrators.

• Opener is passive ("is triggered") — flip to active.
• "actually returns funds" — drop "actually," it's filler.
• "can be ignored by integrators" — flip to active ("integrators can ignore").

Suggested:

When auto-refund to the depositor fires, outTxs contains two transactions. The first is the solver-to-depositor transfer — track that one for refund delivery. The second is an internal protocol-settlement transaction that does not move user funds; integrators can ignore it.

5. Minor: <Info> vs <Note> choice (§2.5)

The new callout is a short cross-cutting reminder about how to interpret an API response shape — this is closer to <Note> per §2.5 ("short cross-cutting reminders"). <Info> is also defensible, just calling out the option. Not a blocker either way.

Nits

• Line 923: the parenthetical inside the <Note> ("an explicit user address you don't control, or the native-currency-address auto-refund opt-in") is dense. Consider splitting: "do not use 'refund to sender' (the auto-refund opt-in described below, or any explicit user address you don't control)".
• Line 934 already says "the first of the two resulting outTxs" — once issue Add execute bridge api + update docs #4 is applied, this phrasing in the bullet can rely on the <Info> callout for the explanation rather than restating "two resulting outTxs".

What's good

• Information is correctly placed: parameter table → configuration table → <Info> callout → recommended setup mirrors the existing structure of the §Refund Behavior section.
• The CEX <Note> update (line 923) correctly extends the existing warning to cover the new opt-in — that's exactly the kind of cross-section follow-up §4.1 expects.
• Voice and terminology are otherwise consistent with the rest of the page (lowercase cross-chain, capitalized chain names, backticked addresses in lowercase hex per §5).
• Callouts stay well under the 15-line cap (§2.5).
• No internal/private details appear to have leaked from the source PR.

Review checklist

• Read the diff
• Read the modified file in full
• Check style-guide conformance per CLAUDE.md
• Post review

--- · branch docs-drift/src-c6bd60f6fe-e8947fb