Update wrong-chain (different VM) copy to 'Not supported'

[pedromcunha]

No description provided.

[github-actions]

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

---

Code Review — PR #349

• Read PR diff and surrounding context
• Check against repo style guide (AGENTS.md / §3.1 feature guide)
• Review for correctness and consistency

---

This is a clean one-line copy change in features/deposit-addresses.mdx:64, updating the Wrong chain (different VM) row in the Open/Strict comparison table from:

Not possible — address formats differ

to:

Not supported

Assessment: looks good. ✅

Correctness — The change is accurate. A different-VM deposit (e.g., an EVM-format address used for a Solana deposit) isn't a recoverable flow, so "Not supported" is a reasonable framing and aligns the column wording with the rest of the table.

Consistency — Not supported now matches the phrasing already used in the adjacent rows (e.g., Wrong token (non-solver) → "Not supported…", Wrong chain (same VM) Strict → "Not supported — no automatic wrong-chain recovery"). The table reads more uniformly than before.

Style guide — No issues. The change respects §2.7 (tables) and the §3.1 feature-guide profile. No frontmatter, heading, or link changes involved.

One minor consideration (non-blocking): the previous copy carried a small "why" — address formats differ — which explained that the deposit is physically impossible across VMs, not merely unsupported. "Not supported" drops that nuance. If the intent is purely to standardize wording, this is fine; if readers benefit from knowing it's a hard technical impossibility (vs. a policy/roadmap gap), a slightly fuller phrase like Not supported — address formats differ across VMs would preserve both. Your call.

Nothing here blocks merge.
· worktree-pedro+update-wrong-chain-vm-copy

[github-actions]

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

---

Code Review — PR #349

Change: In features/deposit-addresses.mdx, the "Wrong chain (different VM)" row of the Open/Strict comparison table changes from Not possible — address formats differ to Not supported in both columns.

Assessment ✅

This is a clean, low-risk copy tweak and it reads well:

• Consistency — Not supported now matches the vocabulary used elsewhere in the same table. The "Wrong token (non-solver)" row already says "Not supported and not currently recoverable" and the Strict "Wrong chain (same VM)" cell says "Not supported — no automatic wrong-chain recovery". Standardizing on "Not supported" makes the table scan more consistently as the user's mental model ("can Relay recover this?") rather than mixing in a technical "why."
• Style guide (AGENTS.md §3.1 / §2.7) — no violations. Table structure, Open/Strict columns, and prose conventions are all preserved.
• Markdown — table alignment and pipe count are intact.

One minor consideration (non-blocking)

The previous copy carried a reason ("address formats differ") that the new copy drops. For most cells in this table, the right-hand value describes the recovery outcome, so "Not supported" fits the pattern. But because a cross-VM deposit is genuinely impossible at the address-format level (not merely an unsupported recovery path), a reader skimming might infer it's a policy choice that could change, rather than a structural impossibility. If you want to preserve that nuance while staying concise, something like Not supported — incompatible address formats would keep both the consistent lead-in and the "why." Entirely optional — the current wording is fine and was already approved.

No correctness, link, or frontmatter issues. LGTM. ✅

• Gather context (diff, changed file)
• Review against AGENTS.md style guide
• Post review feedback

[mintlify]

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

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	Jun 30, 2026, 12:54 PM

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