WalletConnect handshake hangs or fails across multiple mobile wallets on production #220

New issue

Closed

opened 2026-05-20 00:47:02 +00:00 by Brouie · 6 comments

Brouie commented 2026-05-20 00:47:02 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Surfaced while walking A5 sanity check on #219. The issue is broader than Keplr — WalletConnect appears to be broken on yieldomega.com production across multiple wallets.

Summary

WalletConnect QR scan from multiple mobile wallets fails to complete the connection handshake on production https://yieldomega.com.

Observed

Wallet	Path	Result
MetaMask desktop extension Version 13.30.0	Direct connect via modal	Eventually connects but takes ~2 minutes hanging on Confirm connection in the extension
MetaMask mobile v7.76.3 (4858)	Scanned WC QR from another browser	Mobile app shows Connecting to MetaMask, stuck for 2+ minutes, never completes
Trust Wallet mobile v26.19.0	Scanned WC QR	No response — wallet does not react to the scan
Keplr mobile app v2.1.165	Scanned WC QR	please try again or contact Keplr support

Direct extension connect for non-WC wallets (Keplr desktop extension via EIP-6963) works end-to-end — see #219.

Possible causes (not verified)

1. VITE_WALLETCONNECT_PROJECT_ID may not be set on production deploy. The frontend logs in wagmi-config.ts say it falls back to injected-detection wallets only when projectId is empty — would explain the modal still rendering WC option but the handshake never completing. #89 was opened about this.
2. WalletConnect relay endpoint unreachable or slow from the user's network.
3. Something about MegaETH chainId 4326 not being recognized by mobile wallets — they might fail silently if the chain definition WC sends isn't accepted.

Repro

1. Open https://yieldomega.com in a desktop browser, disconnect any current wallet
2. Click Connect → scroll modal → click WalletConnect
3. Scan the QR code with any mobile wallet (MetaMask, Trust, Keplr)
4. Observe — most stall, some fail outright

Useful diagnostic to add

• Confirm whether VITE_WALLETCONNECT_PROJECT_ID is set in Vercel env for production build
• Inspect browser DevTools Network tab while scanning — watch for WC relay endpoints (wss://relay.walletconnect.com) and whether the WSS upgrade completes
• Console errors during the WC modal flow

Severity

Launch-day impact class — most mobile users connect via WalletConnect QR. If WC is broken across multiple wallets, the mobile flow is effectively dead.

Related

• #219 Keplr-specific QA
• #215 Connect wallet does not fire for most of the available wallets (totdking, originally marked not reproducible after refresh — could be the same root cause)
• #89 WalletConnect end-to-end mobile WC testing with real VITE_WALLETCONNECT_PROJECT_ID + mobile wallet

Asks of dev

@PlasticDigits — confirming whether VITE_WALLETCONNECT_PROJECT_ID is set on the production deploy would unblock most of the diagnostic work here.

Surfaced while walking A5 sanity check on #219. The issue is broader than Keplr — WalletConnect appears to be broken on yieldomega.com production across multiple wallets. ## Summary WalletConnect QR scan from multiple mobile wallets fails to complete the connection handshake on production https://yieldomega.com. ## Observed | Wallet | Path | Result | |--------|------|--------| | MetaMask desktop extension Version 13.30.0 | Direct connect via modal | Eventually connects but takes \~2 minutes hanging on Confirm connection in the extension | | MetaMask mobile v7.76.3 (4858) | Scanned WC QR from another browser | Mobile app shows Connecting to MetaMask, stuck for 2+ minutes, never completes | | Trust Wallet mobile v26.19.0 | Scanned WC QR | No response — wallet does not react to the scan | | Keplr mobile app v2.1.165 | Scanned WC QR | please try again or contact Keplr support | Direct extension connect for non-WC wallets (Keplr desktop extension via EIP-6963) works end-to-end — see #219. ## Possible causes (not verified) 1. VITE_WALLETCONNECT_PROJECT_ID may not be set on production deploy. The frontend logs in wagmi-config.ts say it falls back to injected-detection wallets only when projectId is empty — would explain the modal still rendering WC option but the handshake never completing. #89 was opened about this. 2. WalletConnect relay endpoint unreachable or slow from the user's network. 3. Something about MegaETH chainId 4326 not being recognized by mobile wallets — they might fail silently if the chain definition WC sends isn't accepted. ## Repro 1. Open https://yieldomega.com in a desktop browser, disconnect any current wallet 2. Click Connect → scroll modal → click WalletConnect 3. Scan the QR code with any mobile wallet (MetaMask, Trust, Keplr) 4. Observe — most stall, some fail outright ## Useful diagnostic to add - Confirm whether VITE_WALLETCONNECT_PROJECT_ID is set in Vercel env for production build - Inspect browser DevTools Network tab while scanning — watch for WC relay endpoints (wss://relay.walletconnect.com) and whether the WSS upgrade completes - Console errors during the WC modal flow ## Severity Launch-day impact class — most mobile users connect via WalletConnect QR. If WC is broken across multiple wallets, the mobile flow is effectively dead. ## Related - #219 Keplr-specific QA - #215 Connect wallet does not fire for most of the available wallets (totdking, originally marked not reproducible after refresh — could be the same root cause) - #89 WalletConnect end-to-end mobile WC testing with real VITE_WALLETCONNECT_PROJECT_ID + mobile wallet ## Asks of dev @PlasticDigits — confirming whether VITE_WALLETCONNECT_PROJECT_ID is set on the production deploy would unblock most of the diagnostic work here.

Brouie commented 2026-05-20 00:55:04 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Update — Trust Wallet does connect successfully, but only when entering through the wallet's WalletConnect-specific scan flow.

Working path on Trust Wallet:

1. Open Trust Wallet
2. Settings → WalletConnect
3. Use the in-app QR scanner inside the WalletConnect menu (NOT the main wallet camera scan)
4. Scan the yieldomega QR
5. Trust shows the Connect DApp screen — YieldOmega wants to connect to your wallet, https://yieldomega.com, Verified domain, MegaETH network, account shown
6. Tap Connect — desktop session opens, header pill shows connected MEGAETH

{width=185 height=380}

{width=188 height=385}

So WC isn't broken systemically. The handshake works when entered through the wallet's WC-specific flow. The failure mode is:

• Wallets vary in where the WC scan entry point lives
• Trust: hidden in Settings → WalletConnect
• MetaMask mobile: unclear path, my test stalled at Connecting to MetaMask
• Keplr mobile: scan returned a generic please try again error

When the user scans with the wallet's MAIN camera or some non-WC scan flow, the wallet doesn't establish the WC session and the dapp just sits at the QR screen with no error feedback.

So this is more discoverability + per-wallet quirks than a yieldomega bug. Still worth keeping the issue open because:

• VITE_WALLETCONNECT_PROJECT_ID confirmation would explain whether MetaMask mobile timing is normal or symptomatic
• MetaMask desktop extension still takes ~2 minutes to handshake which feels long
• MetaMask mobile via WC QR still doesn't work for me even from MetaMask's own WC entry

Update — Trust Wallet does connect successfully, but only when entering through the wallet's WalletConnect-specific scan flow. Working path on Trust Wallet: 1. Open Trust Wallet 2. Settings → WalletConnect 3. Use the in-app QR scanner inside the WalletConnect menu (NOT the main wallet camera scan) 4. Scan the yieldomega QR 5. Trust shows the Connect DApp screen — YieldOmega wants to connect to your wallet, https://yieldomega.com, Verified domain, MegaETH network, account shown 6. Tap Connect — desktop session opens, header pill shows connected MEGAETH {width=185 height=380} {width=188 height=385} So WC isn't broken systemically. The handshake works when entered through the wallet's WC-specific flow. The failure mode is: - Wallets vary in where the WC scan entry point lives - Trust: hidden in Settings → WalletConnect - MetaMask mobile: unclear path, my test stalled at Connecting to MetaMask - Keplr mobile: scan returned a generic please try again error When the user scans with the wallet's MAIN camera or some non-WC scan flow, the wallet doesn't establish the WC session and the dapp just sits at the QR screen with no error feedback. So this is more discoverability + per-wallet quirks than a yieldomega bug. Still worth keeping the issue open because: - VITE_WALLETCONNECT_PROJECT_ID confirmation would explain whether MetaMask mobile timing is normal or symptomatic - MetaMask desktop extension still takes \~2 minutes to handshake which feels long - MetaMask mobile via WC QR still doesn't work for me even from MetaMask's own WC entry

Brouie commented 2026-05-20 01:00:18 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

changed the description

changed the description

PlasticDigits commented 2026-05-20 04:07:50 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

WC id confirmed set correctly on VITE_WALLETCONNECT_PROJECT_ID in prod

WC id confirmed set correctly on VITE_WALLETCONNECT_PROJECT_ID in prod

PlasticDigits commented 2026-05-20 04:08:49 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Marking as low priority for now but we may need to switch to an sdk like privy

Marking as low priority for now but we may need to switch to an sdk like privy

PlasticDigits commented 2026-05-20 04:41:02 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Investigation note (codebase + docs + external WC/RainbowKit guidance)

Scope: Read-only review of frontend/src/wagmi-config.ts, docs/frontend/wallet-connection.md, deployment guide, related issues (#89, #203, #215), and Reown/RainbowKit/MetaMask public issue threads. No code changes in this pass.

---

Bottom line

This does not look like a single “WC is off in the bundle” regression. Maintainer confirmed VITE_WALLETCONNECT_PROJECT_ID is set on production (2026-05-20). Brouie’s follow-up that Trust Wallet connects successfully via Settings → WalletConnect → in-app scanner (with Verified domain + MegaETH network) is strong evidence the relay + projectId + chain 4326 path can work.

Remaining pain is a mix of wallet-specific entry points, silent failures when users scan with the wrong in-wallet flow, relay/network latency, and optional Reown dashboard / metadata hygiene — not necessarily a YieldOmega-only bug. MetaMask desktop ~2 min and MetaMask mobile stuck at “Connecting…” may still warrant infra checks.

---

Code paths (what production should be doing)

Condition	Behavior (wagmi-config.ts)
VITE_WALLETCONNECT_PROJECT_ID set (prod)	getDefaultConfig + walletConnectWallet in Popular group (with SafePal, MetaMask, etc.)
Project id empty (default local QA)	getDefaultConfig without walletConnectWallet; console: "VITE_WALLETCONNECT_PROJECT_ID is empty — using injected-detection wallets only" (#203)
VITE_E2E_MOCK_WALLET=1	wagmi mock connector only

Implication: If users see a WalletConnect QR in RainbowKit, the production build almost certainly took the projectId-set branch. An empty project id would omit the WC wallet option entirely (not “QR that never completes”). Initial hypothesis #1 in the issue description is therefore unlikely for prod given maintainer confirmation + QR visibility.

Wiring is minimal: AppProviders.tsx → WagmiProvider + RainbowKitProvider; no custom WC relay URL. Stack: RainbowKit ^2.2.4, wagmi ^2.14.15, WalletConnect/Reown 2.21.0 (via lockfile; several WC packages carry upstream “reliability improvements” deprecation notices).

Chain: configuredChain() → 4326 with RPC from VITE_RPC_URL (default https://mainnet.megaeth.com/rpc). Display name is VITE_CHAIN_NAME or fallback Chain 4326 — Trust’s UI showed “MegaETH network”, so wallets can still present a friendly label via their own chain DB / Verify.

---

Likely causes (ranked)

1. Wallet entry-point / UX (high confidence — matches Brouie update)

Many wallets do not treat the main camera / generic QR as WalletConnect v2 URI handling. Failures look like “nothing happens” or generic errors (Keplr “try again”, Trust silent on main camera) even when the WC-specific scanner works.

Not a dapp bug, but launch-impacting: users lack guidance at the QR step.

Mitigations (product, no protocol change): Short copy under the QR: “Open your wallet → WalletConnect → scan here (not the main camera).” Link to wallet-specific paths. Reown docs explicitly recommend QR-from-wallet-app when deep links fail (in-app browsers, Android WebViews).

2. Reown Cloud domain allowlist / Verify metadata (medium — verify in dashboard)

Reown APKT002 / “origin isn’t in your allowlist” and Verify API compare the running origin to configured domains. Misconfiguration can cause warnings, slow paths, or blocked sessions on some wallets.

Checks:

• dashboard.reown.com → project → Domains: allowlist https://yieldomega.com (and www if used).
• Ensure WC session app.metadata.url matches the live origin (RainbowKit getDefaultConfig uses appName: "YieldOmega"; consider setting appUrl / ensuring build uses VITE_SITE_URL=https://yieldomega.com for consistent metadata — optional env exists in .env.example / vite.config.ts OG injection but is not wired into getDefaultConfig today).

3. Relay / network / VPN (medium — explains stalls, multi-wallet)

Common production failures: WSS to relay.walletconnect.com / relay.walletconnect.org stalled, VPN/firewall/corporate Wi‑Fi, regional blocking. RainbowKit GitHub has multiple “works on localhost, stalls in prod” reports; Reown FAQ lists relay unreachable as primary cause of greyed-out connect.

Checks during repro: DevTools → Network → WS to relay; console for transportOpen has stalled / socket errors. Try different network, disable VPN, ping relay host.

4. MetaMask-specific slowness / mobile bugs (medium — matches MM desktop ~2 min + mobile stuck)

Public MetaMask Mobile issues: WC handshake instability on iOS, delayed approval UI, QR misreads, background timeout. 2+ minute desktop extension confirm may be relay + extension backlog or pending -32002 request (MetaMask Connect troubleshooting: don’t double-call connect).

Less likely YieldOmega-specific if Trust completes on same site/session.

5. MegaETH chain 4326 at session time (lower — partial)

Custom chains often fail after pairing on wallet_switchEthereumChain / wallet_addEthereumChain, not always at QR scan. Trust success with MegaETH shown suggests chain is not universally rejected at handshake.

If issues appear after Connect: ensure wallets have MegaETH; session namespaces must include eip155:4326. Optional: set VITE_CHAIN_NAME=MegaETH in prod build for clearer WC chain labels (cosmetic).

6. Missing production E2E for WC path (process gap — #89)

Local QA stack historically runs without project id; #89 tracks real mobile WC matrix. No automated Playwright coverage for WC (Anvil E2E uses mock wallet). Doesn’t explain prod failure but explains late discovery.

---

Ruled out or deprioritized

Hypothesis	Status
Empty VITE_WALLETCONNECT_PROJECT_ID on prod	Ruled out (maintainer comment) + inconsistent with WC option in modal
Wrong branch (#203 blank modal)	Different symptom (empty wallet list), fixed by dual getDefaultConfig branches
Single-wallet Keplr-only bug	Superseded by multi-wallet report + Trust WC-path success (#219)

---

Recommended fixes / next steps

Ops / dashboard (no deploy needed):

1. Reown dashboard: confirm domain allowlist for production host(s).
2. On failed repro, capture: WS relay status, console errors, wallet app version, exact scan entry point (WC menu vs camera).
3. Separate QA project id for staging vs prod (#89 — PlasticDigits already suggested).

Low-risk product improvements (future MRs):

1. In-modal helper text for WC scan entry points (Trust / MetaMask / Keplr).
2. Pass appUrl from VITE_SITE_URL or window.location.origin into RainbowKit config for Verify parity.
3. Set VITE_CHAIN_NAME=MegaETH in production env template (deployment-guide.md).
4. Optional: surface relay/connect errors in UI when WC pairing times out (RainbowKit modal may stay silent today).

Larger alternative (already noted by maintainer): Privy / Reown AppKit — would change connector surface but not fix user education on scan paths.

Investigation / regression:

• Execute #89 acceptance matrix on production URL with prod project id (Trust WC menu, MetaMask Mobile WC menu, one more wallet).
• Compare MetaMask extension slow path with relay logs; retry after clearing MM pending requests.

---

Diagnostic playbook (for next QA pass)

1. Hard refresh → Connect → WalletConnect → open DevTools before scan.
2. Confirm console does not show empty projectId banner.
3. Watch WSS to WalletConnect relay during scan; note stall vs close.
4. On mobile: use wallet’s WalletConnect scanner (document path per wallet).
5. After success, confirm header shows 4326 / MegaETH and a read-only call works.
6. If pairing works but txs fail, debug chain switch / RPC separately (#95 write gating).

---

Related issues

• #89 — mobile WC E2E with real project id (still open QA)
• #203 — empty projectId modal must still list injected wallets (closed)
• #215 — “connect doesn’t fire” — may overlap if users click wallets during relay stall; worth retest with DevTools
• #219 — Keplr extension OK; WC path separate

---

Suggested issue disposition: Keep open as low priority per maintainer, but track as UX/docs + wallet-matrix QA rather than “WC broken on prod.” Upgrade priority if relay allowlist or MetaMask timing proves systemic after dashboard + network checks.

## Investigation note (codebase + docs + external WC/RainbowKit guidance) **Scope:** Read-only review of `frontend/src/wagmi-config.ts`, `docs/frontend/wallet-connection.md`, deployment guide, related issues (#89, #203, #215), and Reown/RainbowKit/MetaMask public issue threads. No code changes in this pass. --- ### Bottom line This does **not** look like a single “WC is off in the bundle” regression. Maintainer confirmed **`VITE_WALLETCONNECT_PROJECT_ID` is set on production** (2026-05-20). Brouie’s follow-up that **Trust Wallet connects successfully via Settings → WalletConnect → in-app scanner** (with **Verified domain** + **MegaETH network**) is strong evidence the **relay + projectId + chain 4326 path can work**. Remaining pain is a **mix of wallet-specific entry points, silent failures when users scan with the wrong in-wallet flow, relay/network latency, and optional Reown dashboard / metadata hygiene** — not necessarily a YieldOmega-only bug. MetaMask desktop ~2 min and MetaMask mobile stuck at “Connecting…” may still warrant infra checks. --- ### Code paths (what production should be doing) | Condition | Behavior (`wagmi-config.ts`) | |-----------|------------------------------| | `VITE_WALLETCONNECT_PROJECT_ID` **set** (prod) | `getDefaultConfig` + `walletConnectWallet` in Popular group (with SafePal, MetaMask, etc.) | | Project id **empty** (default local QA) | `getDefaultConfig` **without** `walletConnectWallet`; console: *"VITE_WALLETCONNECT_PROJECT_ID is empty — using injected-detection wallets only"* ([#203](https://gitlab.com/PlasticDigits/yieldomega/-/issues/203)) | | `VITE_E2E_MOCK_WALLET=1` | wagmi `mock` connector only | **Implication:** If users see a **WalletConnect QR** in RainbowKit, the production build almost certainly took the **projectId-set** branch. An empty project id would **omit** the WC wallet option entirely (not “QR that never completes”). Initial hypothesis #1 in the issue description is therefore **unlikely** for prod *given* maintainer confirmation + QR visibility. Wiring is minimal: `AppProviders.tsx` → `WagmiProvider` + `RainbowKitProvider`; no custom WC relay URL. Stack: **RainbowKit ^2.2.4**, **wagmi ^2.14.15**, **WalletConnect/Reown 2.21.0** (via lockfile; several WC packages carry upstream “reliability improvements” deprecation notices). Chain: `configuredChain()` → **4326** with RPC from `VITE_RPC_URL` (default `https://mainnet.megaeth.com/rpc`). Display name is `VITE_CHAIN_NAME` or fallback **`Chain 4326`** — Trust’s UI showed “MegaETH network”, so wallets can still present a friendly label via their own chain DB / Verify. --- ### Likely causes (ranked) #### 1. Wallet entry-point / UX (high confidence — matches Brouie update) Many wallets **do not** treat the main camera / generic QR as WalletConnect v2 URI handling. Failures look like “nothing happens” or generic errors (Keplr “try again”, Trust silent on main camera) even when the **WC-specific scanner** works. **Not a dapp bug**, but launch-impacting: users lack guidance at the QR step. **Mitigations (product, no protocol change):** Short copy under the QR: *“Open your wallet → WalletConnect → scan here (not the main camera).”* Link to wallet-specific paths. Reown docs explicitly recommend QR-from-wallet-app when deep links fail (in-app browsers, Android WebViews). #### 2. Reown Cloud domain allowlist / Verify metadata (medium — verify in dashboard) Reown **APKT002 / “origin isn’t in your allowlist”** and Verify API compare the running origin to configured domains. Misconfiguration can cause warnings, slow paths, or blocked sessions on some wallets. **Checks:** - [dashboard.reown.com](https://dashboard.reown.com) → project → **Domains**: allowlist `https://yieldomega.com` (and `www` if used). - Ensure WC session `app.metadata.url` matches the live origin (RainbowKit `getDefaultConfig` uses `appName: "YieldOmega"`; consider setting **`appUrl`** / ensuring build uses **`VITE_SITE_URL=https://yieldomega.com`** for consistent metadata — optional env exists in `.env.example` / `vite.config.ts` OG injection but is **not** wired into `getDefaultConfig` today). #### 3. Relay / network / VPN (medium — explains stalls, multi-wallet) Common production failures: **WSS to `relay.walletconnect.com` / `relay.walletconnect.org` stalled**, VPN/firewall/corporate Wi‑Fi, regional blocking. RainbowKit GitHub has multiple “works on localhost, stalls in prod” reports; Reown FAQ lists relay unreachable as primary cause of greyed-out connect. **Checks during repro:** DevTools → Network → WS to relay; console for `transportOpen has stalled` / socket errors. Try different network, disable VPN, ping relay host. #### 4. MetaMask-specific slowness / mobile bugs (medium — matches MM desktop ~2 min + mobile stuck) Public MetaMask Mobile issues: WC handshake instability on iOS, delayed approval UI, QR misreads, background timeout. **2+ minute** desktop extension confirm may be relay + extension backlog or pending `-32002` request (MetaMask Connect troubleshooting: don’t double-call `connect`). Less likely YieldOmega-specific if Trust completes on same site/session. #### 5. MegaETH chain 4326 at session time (lower — partial) Custom chains often fail **after** pairing on `wallet_switchEthereumChain` / `wallet_addEthereumChain`, not always at QR scan. Trust success with MegaETH shown suggests chain is not universally rejected at handshake. If issues appear **after** Connect: ensure wallets have MegaETH; session namespaces must include `eip155:4326`. Optional: set **`VITE_CHAIN_NAME=MegaETH`** in prod build for clearer WC chain labels (cosmetic). #### 6. Missing production E2E for WC path (process gap — #89) Local QA stack historically runs **without** project id; **#89** tracks real mobile WC matrix. No automated Playwright coverage for WC (Anvil E2E uses mock wallet). Doesn’t explain prod failure but explains late discovery. --- ### Ruled out or deprioritized | Hypothesis | Status | |------------|--------| | Empty `VITE_WALLETCONNECT_PROJECT_ID` on prod | **Ruled out** (maintainer comment) + inconsistent with WC option in modal | | Wrong branch (#203 blank modal) | Different symptom (empty wallet list), fixed by dual `getDefaultConfig` branches | | Single-wallet Keplr-only bug | Superseded by multi-wallet report + Trust WC-path success ([#219](https://gitlab.com/PlasticDigits/yieldomega/-/issues/219)) | --- ### Recommended fixes / next steps **Ops / dashboard (no deploy needed):** 1. Reown dashboard: confirm **domain allowlist** for production host(s). 2. On failed repro, capture: WS relay status, console errors, wallet app version, **exact scan entry point** (WC menu vs camera). 3. Separate QA project id for staging vs prod ([#89](https://gitlab.com/PlasticDigits/yieldomega/-/issues/89) — PlasticDigits already suggested). **Low-risk product improvements (future MRs):** 1. In-modal helper text for WC scan entry points (Trust / MetaMask / Keplr). 2. Pass **`appUrl`** from `VITE_SITE_URL` or `window.location.origin` into RainbowKit config for Verify parity. 3. Set **`VITE_CHAIN_NAME=MegaETH`** in production env template (`deployment-guide.md`). 4. Optional: surface relay/connect errors in UI when WC pairing times out (RainbowKit modal may stay silent today). **Larger alternative (already noted by maintainer):** Privy / Reown AppKit — would change connector surface but not fix user education on scan paths. **Investigation / regression:** - Execute **#89** acceptance matrix on **production URL** with prod project id (Trust WC menu, MetaMask Mobile WC menu, one more wallet). - Compare MetaMask extension slow path with relay logs; retry after clearing MM pending requests. --- ### Diagnostic playbook (for next QA pass) 1. Hard refresh → Connect → WalletConnect → open DevTools before scan. 2. Confirm console **does not** show empty projectId banner. 3. Watch **WSS** to WalletConnect relay during scan; note stall vs close. 4. On mobile: use wallet’s **WalletConnect** scanner (document path per wallet). 5. After success, confirm header shows **4326 / MegaETH** and a read-only call works. 6. If pairing works but txs fail, debug chain switch / RPC separately ([#95](https://gitlab.com/PlasticDigits/yieldomega/-/issues/95) write gating). --- ### Related issues - **#89** — mobile WC E2E with real project id (still open QA) - **#203** — empty projectId modal must still list injected wallets (closed) - **#215** — “connect doesn’t fire” — may overlap if users click wallets during relay stall; worth retest with DevTools - **#219** — Keplr extension OK; WC path separate --- **Suggested issue disposition:** Keep open as **low priority** per maintainer, but track as **UX/docs + wallet-matrix QA** rather than “WC broken on prod.” Upgrade priority if relay allowlist or MetaMask timing proves systemic after dashboard + network checks.

Brouie commented 2026-05-20 05:21:59 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #215

mentioned in issue #215

PlasticDigits (Migrated from gitlab.com) closed this issue 2026-05-30 13:23:12 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

cac-design-issue-544

renovate/configure

No results found.

Labels

Clear labels   

agent:fix_bugfix

  

agent:fix_conflicts

  

agent:fix_security

  

agent:gap_analysis

  

agent:implement

  

agent:open_issues

  

agents

  

agent:security_audit

  

agent:verify

  

area

timecurve

  

arena

  

arena-v2

  

audit

  

block:feature_review

  

block:security

  

bug

  

contracts

  

design

  

devops

  

docs

Documentation

  

documentation

  

enhancement

  

epic

Epic / umbrella issue

  

feature

  

frontend

  

indexer

  

low priority

Low priority, investigate other issues first

  

megaeth

  

operations

  

ops

Deploy and operations

  

performance

  

QA

  

qa checklist

  

referrals

  

removal

Legacy removal

  

security

  

smart-contracts

  

tech-debt

  

testing

  

time-arena

TimeArena v2 revamp

  

timecurve

  

visual-qa

No labels

agent:fix_bugfix

agent:fix_conflicts

agent:fix_security

agent:gap_analysis

agent:implement

agent:open_issues

agents

agent:security_audit

agent:verify

area

timecurve

arena

arena-v2

audit

block:feature_review

block:security

bug

contracts

design

devops

docs

documentation

enhancement

epic

feature

frontend

indexer

low priority

megaeth

operations

ops

performance

QA

qa checklist

referrals

removal

security

smart-contracts

tech-debt

testing

time-arena

timecurve

visual-qa

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

code/yieldomega#220

No description provided.