Wallet Session

Overview

How it works

Sessions can exist after login, device approval, API authentication, browser connection, or a protocol handshake. They may expose account information, allow specific methods, receive events, or request signatures without repeating the initial connection process.

A session is not merely a convenience token. Theft can let an attacker impersonate a user or application, and persistent permissions may survive after the original task. Sessions can reveal addresses and activity even when each financial transaction still requires signing.

Wallets should bind sessions to verified identity, device, application origin, permitted accounts, networks, methods, and expiry. Sensitive sessions need secure storage, rotation, inactivity timeout, and revocation. Users should review and remove stale connections. Organizations must monitor creation, scope changes, unusual use, and termination. Every transaction request still requires exact intent validation independent of session approval.

What matters in practice

A wallet session is a time-bounded and permission-scoped connection between a wallet and an application, often established through a wallet connector. The session may authorize reading addresses, proposing signatures or submitting transactions, depending on its grants. Connecting is not always equivalent to authorizing a payment, but overbroad session permissions create phishing exposure. The UI should name the site, chain, allowed actions and expiry. Users need ways to revoke old sessions, and applications should recover safely when a session expires midway through checkout.