WalletConnect: end-to-end mobile WC testing with real VITE_WALLETCONNECT_PROJECT_ID + mobile wallet

Brouie commented

2026-04-29 05:22:49 +00:00

(Migrated from gitlab.com)

Summary

Filed per dev's TG request to keep walletconnect testing scope separate from #58 (which closed today on the SafePal browser-extension verification).

WalletConnect mobile path on YO frontend needs end-to-end exercise with a real VITE_WALLETCONNECT_PROJECT_ID set in the build + a mobile wallet (e.g. SafePal, Trust, Rainbow, MetaMask Mobile) on a phone. Currently the QA stack runs with VITE_WALLETCONNECT_PROJECT_ID empty (injected-only fallback path), so the WC QR / deep-link path isn't built into the bundle and can't be exercised locally.

Suggested test matrix

Set VITE_WALLETCONNECT_PROJECT_ID in frontend/.env.local to a free Reown / WalletConnect project ID (e.g. obtained at cloud.reown.com)
Restart Vite, hard refresh localhost:5173/timecurve
Verify console no longer prints "VITE_WALLETCONNECT_PROJECT_ID is empty - using injected wallets only" banner
Click Connect, select WalletConnect option from the RainbowKit modal
QR code should display
From a phone with SafePal mobile (or other WC-compatible wallet): scan the QR
Confirm the dapp pairs successfully + chain matches dapp config
From mobile wallet, drive a real buy or read flow on the deployed test chain
Confirm signed tx propagates back to the dapp UI without disconnecting

Acceptance criteria

Reown / WalletConnect project ID acquired (free tier sufficient for testing)
VITE_WALLETCONNECT_PROJECT_ID set in build config (or .env.local for local QA)
WC QR appears in RainbowKit modal when WalletConnect option is clicked
Mobile wallet (at least SafePal mobile per #58 scope, ideally also one more like MetaMask Mobile or Rainbow for regression) successfully pairs via QR scan
Chain detection matches dapp expectation (chainId from VITE_CHAIN_ID)
Live signed transaction from mobile wallet appears in dapp UI / chain
No regression to the injected-only path (MetaMask extension etc still connects fine)

Why this is a follow-up to #58

#58 verified the SafePal browser-extension wiring end-to-end on the QA Anvil stack (live connect + buy via SafePal extension confirmed today on the running 799cf6f stack). The WC mobile path is a different code branch that requires the production-style env config to even exist in the bundle, so it's its own scope.

Severity: P2-medium. Not a launch-blocker (most users connect via injected extensions, especially on desktop), but mobile WC is a meaningful supported path and worth testing before TGE.

cc @PlasticDigits

## Summary Filed per dev's TG request to keep walletconnect testing scope separate from #58 (which closed today on the SafePal browser-extension verification). WalletConnect mobile path on YO frontend needs end-to-end exercise with a real VITE_WALLETCONNECT_PROJECT_ID set in the build + a mobile wallet (e.g. SafePal, Trust, Rainbow, MetaMask Mobile) on a phone. Currently the QA stack runs with VITE_WALLETCONNECT_PROJECT_ID empty (injected-only fallback path), so the WC QR / deep-link path isn't built into the bundle and can't be exercised locally. ## Suggested test matrix 1. Set VITE_WALLETCONNECT_PROJECT_ID in frontend/.env.local to a free Reown / WalletConnect project ID (e.g. obtained at cloud.reown.com) 2. Restart Vite, hard refresh localhost:5173/timecurve 3. Verify console no longer prints "VITE_WALLETCONNECT_PROJECT_ID is empty - using injected wallets only" banner 4. Click Connect, select WalletConnect option from the RainbowKit modal 5. QR code should display 6. From a phone with SafePal mobile (or other WC-compatible wallet): scan the QR 7. Confirm the dapp pairs successfully + chain matches dapp config 8. From mobile wallet, drive a real buy or read flow on the deployed test chain 9. Confirm signed tx propagates back to the dapp UI without disconnecting ## Acceptance criteria - [ ] Reown / WalletConnect project ID acquired (free tier sufficient for testing) - [ ] VITE_WALLETCONNECT_PROJECT_ID set in build config (or .env.local for local QA) - [ ] WC QR appears in RainbowKit modal when WalletConnect option is clicked - [ ] Mobile wallet (at least SafePal mobile per #58 scope, ideally also one more like MetaMask Mobile or Rainbow for regression) successfully pairs via QR scan - [ ] Chain detection matches dapp expectation (chainId from VITE_CHAIN_ID) - [ ] Live signed transaction from mobile wallet appears in dapp UI / chain - [ ] No regression to the injected-only path (MetaMask extension etc still connects fine) ## Why this is a follow-up to #58 #58 verified the SafePal browser-extension wiring end-to-end on the QA Anvil stack (live connect + buy via SafePal extension confirmed today on the running 799cf6f stack). The WC mobile path is a different code branch that requires the production-style env config to even exist in the bundle, so it's its own scope. Severity: P2-medium. Not a launch-blocker (most users connect via injected extensions, especially on desktop), but mobile WC is a meaningful supported path and worth testing before TGE. cc @PlasticDigits

Brouie commented

2026-04-29 06:08:52 +00:00

(Migrated from gitlab.com)

mentioned in issue #39

Brouie commented

2026-04-30 04:21:08 +00:00

(Migrated from gitlab.com)

mentioned in issue #38

Brouie commented

2026-05-01 15:03:51 +00:00

(Migrated from gitlab.com)

Source-level confirmation while passing through this issue today — wiring is complete, this is purely an "acquire WC project ID + run mobile test" gap on the QA side. Not blocked by code.

wagmi-config.ts:29-34 reads VITE_WALLETCONNECT_PROJECT_ID?.trim() and logs console.info when empty (visible to my repro step 3).
Three-branch wagmi config:
1. VITE_E2E_MOCK_WALLET=1 → Playwright mock
2. projectId set → full RainbowKit getDefaultConfig with wallets: rainbowKitWalletGroups (SafePal included per your #58 comment cross-link)
3. No project ID → bare createConfig with connectors: [injected()] only — no WC QR path in the bundle
.env.example:12 documents VITE_WALLETCONNECT_PROJECT_ID= (empty default).

Will pick this up next time the QA stack is rebuilt with a Reown / WalletConnect free-tier project ID and a mobile wallet on hand. Just bumping for visibility — leaving open per the original scope.

cc @PlasticDigits

Source-level confirmation while passing through this issue today — wiring is complete, this is purely an "acquire WC project ID + run mobile test" gap on the QA side. Not blocked by code. - `wagmi-config.ts:29-34` reads `VITE_WALLETCONNECT_PROJECT_ID?.trim()` and logs `console.info` when empty (visible to my repro step 3). - Three-branch wagmi config: 1. `VITE_E2E_MOCK_WALLET=1` → Playwright mock 2. `projectId` set → full RainbowKit `getDefaultConfig` with `wallets: rainbowKitWalletGroups` (SafePal included per your #58 comment cross-link) 3. No project ID → bare `createConfig` with `connectors: [injected()]` only — no WC QR path in the bundle - `.env.example:12` documents `VITE_WALLETCONNECT_PROJECT_ID=` (empty default). Will pick this up next time the QA stack is rebuilt with a Reown / WalletConnect free-tier project ID and a mobile wallet on hand. Just bumping for visibility — leaving open per the original scope. cc @PlasticDigits

PlasticDigits commented

2026-05-02 06:58:03 +00:00

(Migrated from gitlab.com)

Ive added a walletconnect id to production yieldomega.com website, but I still recommend setting up a different id for qa development for yieldomega and other projects @Brouie

Brouie commented

2026-05-08 00:47:04 +00:00

(Migrated from gitlab.com)

mentioned in issue #164

PlasticDigits commented

2026-05-12 07:40:32 +00:00

(Migrated from gitlab.com)

@Brouie For verification, you need to use the reown website to create a free walletconnect id - it will require email registration

Brouie commented

2026-05-20 00:47:03 +00:00

(Migrated from gitlab.com)

mentioned in issue #220

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-05-21 12:05:49 +00:00

Rows
Columns

WalletConnect: end-to-end mobile WC testing with real VITE_WALLETCONNECT_PROJECT_ID + mobile wallet #89

Summary

Suggested test matrix

Acceptance criteria

Why this is a follow-up to #58