WalletConnect Session Privacy: Which Accounts Did You Share?

A WalletConnect application can receive the accounts and chain context approved for its session; it does not automatically obtain every address derived from your wallet seed. Review the settled session, because it may contain more accounts or networks than the one currently visible on the app's page. Connection privacy also depends on the wallet, application and infrastructure involved.

Start with the agreed session, not the connect button

The WalletConnect namespace specification distinguishes what an application requests from what the wallet approves. The proposal describes required and optional permissions. The resulting session describes the approved accounts, methods, chains and events. The word Connected is therefore not a complete inventory of the information exchanged.

An account selected in the application's current interface may be only its active view, not the session's entire account list. If the wallet exposes connected-app details, inspect that list there. If the interface does not show the scope clearly, consult its current documentation rather than assuming that changing the displayed tab silently removes previously shared accounts.

The network belongs to the account identifier

CAIP-10 defines an account identifier by combining chain context and an address. This matters when similar-looking strings exist across networks. Sharing the same EVM address in two chain contexts can tell the receiving application that both were part of this approved session; it is not evidence that the balances or assets are the same.

Take a fictional user who approves account Cedar on two networks and account Maple on a third. The dApp can receive those approved account identifiers even if its homepage initially displays only Cedar on the first network. A screenshot of that homepage cannot establish that Maple was never shared. The relevant evidence is the settled session scope and what the wallet actually sent.

Nor should the user infer that all other accounts in the wallet were shared. The approved namespace is not a dump of the seed's complete derivation history. Use the concrete account list for the assessment. A wallet's implementation choices and later session updates still need checking; the interface's current active account alone is not enough.

Encryption protects a channel, not every surrounding data flow

The pairing specification describes an encrypted communication layer between peers. The session-proposal flow then establishes the Sign session and exchanges its namespace and peer metadata. That does not mean an approved dApp is unable to read the account information deliberately sent to it.

Keep the parties separate: the wallet, the dApp and any hosted infrastructure have different roles. Reown's privacy policy discusses its hosted cloud infrastructure and categories that may include IP addresses, wallet addresses, encrypted payloads and protocol metadata. That is a stated policy scope, not an independent traffic audit or proof that every integration collects every listed category.

The same policy says third-party services have their own privacy practices. Read the wallet and dApp policies separately. A transport's encryption property does not, by itself, explain account analytics, browser sessions or data retention at the endpoint. Do not translate encrypted communication into a promise that nobody can associate the visit with an address.

Treat the pairing QR as connection material

The pairing-URI specification includes a symmetric key used for pairing encryption. A connection QR or URI is therefore not merely a harmless public payment address. Do not post an active pairing string in a public support thread or hand it to a stranger offering to troubleshoot your connection.

A seed phrase is a different and more sensitive category again. WalletConnect pairing does not require sending the seed to the dApp. If a page asks for it as a privacy check or session repair, stop. For support, begin with the wallet version, network, app domain, time and an error description, using a redacted screenshot that excludes connection secrets.

Track changes and understand what disconnecting means

The session-event reference documents updates, deletion, expiry and account-change events. A session can have a lifecycle beyond its first approval. Review connected-app permissions after a meaningful change rather than assuming that the original screen permanently describes all later interactions.

Disconnecting ends that connection under the wallet's supported process; it is not proof that the dApp deleted account identifiers it already received. It also does not rewrite the public chain history attached to those addresses. If you need information about stored data, use the relevant service's privacy contact or published controls rather than expecting a connection button to erase an earlier disclosure.

Connection scope is separate from onchain permissions. A token allowance already granted onchain is not removed merely because the communication session ends. That distinction matters for security, but it should not distract from the privacy question: even if no spending approval was given, the dApp may already have learned the approved account list.

A practical account-sharing review

1. Open the connection from a trusted application domain and inspect which wallet account is active before approving.
2. Read the proposed networks and methods. Where the wallet offers account selection, choose the accounts the intended task actually needs.
3. After connection, inspect the settled session or connected-app details. Do not rely solely on the dApp's current account display.
4. Compare the approved addresses with public information you have already associated with them. Separate known disclosure from guesses about every account in the wallet.
5. Review the wallet, infrastructure and dApp privacy information for their respective services; do not apply one policy to all parties.
6. When finished, disconnect through the wallet's supported process and review any onchain permissions separately.

If the interface cannot show the approved scope, that is a reason to ask a precise question: which accounts and chains are in this session? It is not a reason to send a raw exported session or seed to public chat. Preserve a local note of the app and scope when the distinction matters for your records.

For a separate security check after an approval, use token approval revocation. A no-account swap is another service flow and should be assessed through its own instructions and AML policy. This session review does not assert that KOT.CASH requires WalletConnect, implements its infrastructure or offers an address-disclosure guarantee.