[DRAFT] PROTOTYPE ONLY: add support for Bitcoin and Solana chains

[fairlighteth]

Non‑EVM (BTC/SOL) swap+bridge prototype

Screen.Recording.2026-01-29.at.14.27.02.mov

What’s added

• BTC & SOL as buy‑only destination chains in the network picker and swap flow (sell side disabled, flip disabled).
• Prototype chain & token stubs for BTC/SOL with deterministic synthetic 0x… addresses and allowlisted SOL tokens.
• Non‑EVM recipient UX (inline input, validation, QR scan, non‑EVM explorer links, confirm banner).
• Prototype bridge quotes for BTC/SOL so the UI flow can be exercised end‑to‑end.

Feature flag

• REACT_APP_NON_EVM_PROTOTYPE (default enabled) gates non‑EVM data/quotes.
• Prototype quotes do not execute; posting throws Non‑EVM prototype mode: execution is disabled.

———

User flow (happy path)

1. Select destination chain → BTC or SOL appears in the chain picker.
2. Pick destination token
   • BTC: only BTC available
   • SOL: SOL + allowlisted tokens (via prototype allowlist)
3. Recipient field appears inline (cannot be toggled off for non‑EVM destinations).
4. Enter a valid BTC/SOL address (or scan QR).
5. Quote updates & CTA enables → user can proceed to confirm (bridge details shown).

———

Buy‑only enforcement

• Sell‑side BTC/SOL disabled with tooltip:
  Swap from Bitcoin/Solana not supported.
• Flip disabled if output is BTC/SOL:
  BTC/SOL is buy‑only
• Safety reset: if a non‑EVM ends up on sell side, swap state is reset to wallet chain defaults.

———

Recipient behavior (non‑EVM destinations)

• Required (toggle disabled; inline field shown).
• Reset rules on destination change
  • Non‑EVM → EVM: keep only if recipient is a valid EVM address
  • BTC ↔ SOL: always clear
  • EVM → Non‑EVM: clear
• Displayed everywhere: quote details, confirm modal, activity summary (as “Destination address” for non‑EVM).

———

Validation + exact messages

Field‑level validation (inline error under input)

• Bitcoin invalid: Enter a valid Bitcoin address
• Solana invalid: Enter a valid Solana address
• EVM address on BTC: That's an EVM address; Bitcoin requires a BTC address.
• EVM address on SOL: That's an EVM address; Solana requires a SOL address.
• SOL entered on BTC: Solana address detected. Enter a valid Bitcoin address.
• BTC entered on SOL: Bitcoin address detected. Enter a valid Solana address.

CTA (trade button) validation

• Missing recipient: Recipient required for Bitcoin/Solana
  (or Recipient required for {Bitcoin|Solana})
• Invalid recipient: Enter a valid recipient

Prototype note: quotes can still be fetched without a recipient, but the CTA remains disabled until a valid address is provided.

———

QR scan + paste

• Scan button appears until a valid non‑EVM recipient is set.
• Scanner normalizes: trims, strips whitespace, URL schemes, and chain suffixes.
• Scan errors:
  • Bitcoin address detected. Scan a valid Solana address.
  • Solana address detected. Scan a valid Bitcoin address.
  • Invalid {Bitcoin|Solana} address scanned, please try again.
• Camera errors:
  • Camera access is not available in this browser.
  • Camera access requires a secure context.
  • Camera access was denied or is unavailable.

———

Quotes & failure paths

• Prototype quote builder returns a stubbed bridge+swap quote and fills all UI fields used by the widget.
• Common bridge errors already mapped to spec texts:
  • No route available for this pair/amount
  • Quote unavailable for this recipient/route

———

Spec alignment (prototype)

• ✅ Buy‑only BTC/SOL + flip disable + sell‑side disabled reason
• ✅ Recipient required + inline + validation + mismatch detection
• ✅ Recipient shown in quote/confirm/activity (labelled “Destination address” for non‑EVM)
• ✅ QR scan + paste normalization + chain‑aware errors
• ✅ Quote errors mapped to spec copy
• ✅ BTC only; SOL allowlist in prototype

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
cowfi	Ready	Preview	Jan 29, 2026 3:07pm
explorer-dev	Ready	Preview	Jan 29, 2026 3:07pm
swap-dev	Ready	Preview	Jan 29, 2026 3:07pm
widget-configurator	Ready	Preview	Jan 29, 2026 3:07pm

2 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
cosmos	Ignored		Jan 29, 2026 3:07pm
sdk-tools	Ignored	Preview	Jan 29, 2026 3:07pm

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[elena-zh]

Hey @fairlighteth , looks great!!

I have some issues/questions to report, but LMK please which ones of them can be addressed here or should be put onto this board:

1. Placeholder's font differs from the one we have in all the rest fields on the form. Is it OK?

2. If we disable this arrow, it should not show a 'hover' animation. I think/ we can even need to add a 'forbidden' icon on hower (or another placeholder saying 'Sell orders are allowed only'?)

3. I think, it would be great to add 'solana/bitcoin' addresses validation for regular swaps

same as here

4. 'View' address link is different for regular swaps. See the comparison:

• reg swap's recipient

• solana/bitcoin recipient

5. It would be nice to add 'valid address' validation message to a regular swap's recipient:

like here

6. I think, it would be great to reduce the placeholder's font size in a mobile view:

7. I noticed that Bitcoin validation on an address length (min/max) is missing here:

Might it be possible to add it?

8. I'd remove the checkbox to a not connected user: it does not make sense in this state:

Thanks

[fairlighteth]

@elena-zh thanks for reviewing.

1. Yeah... the idea was to use a distinctive mono font for wallet addresses. Perhaps for the placeholder text itself we should stick to our normal font.
2. Agreed.
3. Agreed. We can bring those same validation rules for EVM flows. Including the 'confirm' wallet layout.
4. I'm aware. "View" Just seemed more compact in this context.
5. Agreed. See point 3.
6. Yes, placeholder text looks like it should shrink. There is logic in place for the address to 'grow' in size but with min. size. We should do something similar for the placeholder text itself as well.
7. What's the full address you used? You sure it is supposed to be invalid?
8. I understand, but it also doesn't hurt IMO. And once connected, they can continue with their swap. Might be a flow where user defines their trade, checks the boxes, then finds out they're not connected yet. So they can proceed with that, without having to go back to their trade to check a box.

[elena-zh]

Hey @fairlighteth ,

What's the full address you used? You sure it is supposed to be invalid?

https://www.blockchain.com/explorer/addresses/btc/bc1qray0vz42y0sl4m0qwar58yel6lure25q8f22cn55555555555555555555555555555565655643446

I'm aware. "View" Just seemed more compact in this context.

My point here is to use a compact 'view' everywhere :)

I understand, but it also doesn't hurt IMO. And once connected, they can continue with their swap. Might be a flow where user defines their trade, checks the boxes, then finds out they're not connected yet. So they can proceed with that, without having to go back to their trade to check a box.

Unfortunately, all info can be reset right after connection, especially if a user's wallet is in another chain (how it works now on Prod).

Besides, it contradicts the logic we currently have in other wallets. See the example:

• not connected

• connected