ProblemWalletConnect v2 envelopes and the pairing topic carry no client-side expiry enforcement in walletconnect.ts. Stale pairing/session topics can be reused, and WCEncryptedEnvelope responses are accepted regardless of age.
- No
expiresAt check on accepted session proposals/settles.
- Cached topics are not cleaned up on expiry, so memory and relay subscriptions leak over long sessions.
- There is no per-message timestamp/AAD binding in the AES-GCM layers, weakening replay resistance compared with the WC spec.
Solution
- Store and enforce session/proposal expiry timestamps on both sides of the relay.
- Purge expired topics on interval and on new pairings.
- Follow the WC v2 envelope format (metadata, AAD) rather than a custom envelope shape.
Acceptance Criteria
- Expired session proposals are rejected instead of accepted.
- Relay subscriptions are cleaned up after session timeout.
- No growth in
walletStore session state after repeated connect/disconnect.
npm run build passes.
Note for Contributors: Write a clear PR description. Show a session that is accepted then rejected after expiry, and memory/heap stableness under repeated pairings.
ProblemWalletConnect v2 envelopes and the pairing topic carry no client-side expiry enforcement in
walletconnect.ts. Stale pairing/session topics can be reused, andWCEncryptedEnveloperesponses are accepted regardless of age.expiresAtcheck on accepted session proposals/settles.Solution
Acceptance Criteria
walletStoresession state after repeated connect/disconnect.npm run buildpasses.Note for Contributors: Write a clear PR description. Show a session that is accepted then rejected after expiry, and memory/heap stableness under repeated pairings.