You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:networkMismatch in useWalletStore is currently informational only — SwapCard's canSwap and SolvePageClient's canRegister never check it, meaning a user connected to the wrong network can still submit a swap or solver registration. Additionally, signTransaction(xdr, { network: wallet.network ?? undefined }) passes whatever network string Freighter reports, rather than validating it against the app's expected network passphrase before signing.
Problem Statement & Context: Signing and submitting a transaction while connected to the wrong Stellar network (e.g. testnet vs. mainnet) can result in funds being sent on an unintended network, or a transaction being rejected in a confusing way after the user has already gone through the sign flow. The current warning banner in ConnectWalletButton is easy to miss, and nothing actually stops the risky action.
Scope & Acceptance Criteria:
SwapCard's canSwap and SolvePageClient's canRegister must both be false while networkMismatch is true, with a clear inline explanation (not just the existing small warning text) of why submission is blocked.
signTransaction calls in useSwapSubmission.ts/useSolverRegistration.ts should explicitly validate wallet.network against EXPECTED_NETWORK (already computed in src/store/wallet.ts) immediately before calling Freighter, as a defense-in-depth check even if the UI guard above is somehow bypassed (e.g. a stale closure).
Out of scope: automatically switching networks on the user's behalf (not possible via Freighter's API).
This pairs naturally with issue Pr7 swapcard quote api #9's live mismatch detection but can be implemented independently against the mismatch state as it exists today (checked at connect/hydrate time only) — don't block on Pr7 swapcard quote api #9 being done first.
Edge cases: the guard must not falsely block a user who has never connected a wallet at all (networkMismatch defaults to false pre-connection, which is correct — verify this isn't accidentally conflated with "connected and correct").
Testing: extend src/components/SwapCard.test.tsx and SolvePageClient tests to assert submission is disabled and clearly explained under a mocked networkMismatch: true wallet state; extend useSwapSubmission.test.ts/useSolverRegistration.test.ts for the defense-in-depth check throwing before calling freighterApi.signTransaction.
Definition of Done:
Code written, tested.
Acceptance criteria met; verified via test output.
Description:
networkMismatchinuseWalletStoreis currently informational only —SwapCard'scanSwapandSolvePageClient'scanRegisternever check it, meaning a user connected to the wrong network can still submit a swap or solver registration. Additionally,signTransaction(xdr, { network: wallet.network ?? undefined })passes whatever network string Freighter reports, rather than validating it against the app's expected network passphrase before signing.Problem Statement & Context: Signing and submitting a transaction while connected to the wrong Stellar network (e.g. testnet vs. mainnet) can result in funds being sent on an unintended network, or a transaction being rejected in a confusing way after the user has already gone through the sign flow. The current warning banner in
ConnectWalletButtonis easy to miss, and nothing actually stops the risky action.Scope & Acceptance Criteria:
SwapCard'scanSwapandSolvePageClient'scanRegistermust both befalsewhilenetworkMismatchistrue, with a clear inline explanation (not just the existing small warning text) of why submission is blocked.signTransactioncalls inuseSwapSubmission.ts/useSolverRegistration.tsshould explicitly validatewallet.networkagainstEXPECTED_NETWORK(already computed insrc/store/wallet.ts) immediately before calling Freighter, as a defense-in-depth check even if the UI guard above is somehow bypassed (e.g. a stale closure).Implementation Guidelines:
src/store/wallet.ts(EXPECTED_NETWORK,networkMismatch),src/components/SwapCard.tsx,src/app/solve/SolvePageClient.tsx,src/hooks/useSwapSubmission.ts,src/hooks/useSolverRegistration.ts.networkMismatchdefaults tofalsepre-connection, which is correct — verify this isn't accidentally conflated with "connected and correct").src/components/SwapCard.test.tsxandSolvePageClienttests to assert submission is disabled and clearly explained under a mockednetworkMismatch: truewallet state; extenduseSwapSubmission.test.ts/useSolverRegistration.test.tsfor the defense-in-depth check throwing before callingfreighterApi.signTransaction.Definition of Done:
Resources:
src/store/wallet.ts,docs/wallet-hydration.mdComplexity: High (200 points)