Location
contexts/WalletContext.tsx:277-284 (reads parsed.exp/parsed.expiresAt); written at lines 377, 435
Description
The session-restore logic reads parsed.exp ?? parsed.expiresAt from localStorage to decide whether a stored session should be purged as stale. But a repo-wide check confirms exp/expiresAt is never written anywhere — the session-persistence writes at lines 377 and 435 only store { key, name }, with no expiry field at all.
Why it matters
The expiry check always sees undefined for both fields and presumably no-ops (never purges) — stored wallet sessions persist indefinitely regardless of age, despite the code implying there's an expiry mechanism protecting against stale sessions. This is a security-relevant gap for a wallet-connected financial app.
Suggested fix
Either write a real expiry timestamp when persisting the session and confirm the read-side check purges correctly, or remove the dead read-side logic if expiry isn't actually intended.
Acceptance criteria
Location
contexts/WalletContext.tsx:277-284(readsparsed.exp/parsed.expiresAt); written at lines 377, 435Description
The session-restore logic reads
parsed.exp ?? parsed.expiresAtfrom localStorage to decide whether a stored session should be purged as stale. But a repo-wide check confirmsexp/expiresAtis never written anywhere — the session-persistence writes at lines 377 and 435 only store{ key, name }, with no expiry field at all.Why it matters
The expiry check always sees
undefinedfor both fields and presumably no-ops (never purges) — stored wallet sessions persist indefinitely regardless of age, despite the code implying there's an expiry mechanism protecting against stale sessions. This is a security-relevant gap for a wallet-connected financial app.Suggested fix
Either write a real expiry timestamp when persisting the session and confirm the read-side check purges correctly, or remove the dead read-side logic if expiry isn't actually intended.
Acceptance criteria