A wallet tab constantly calls <code>getBalance</code>, <code>getTokenAccountsByOwner</code>, <code>getSignaturesForAddress</code>, and opens <code>accountSubscribe</code> websockets for your vault. Each request tells the RPC node which accounts you care about and the IP address asking. <code>sendTransaction</code> ties your IP to a specific transaction.<br/><br/>Free and public RPC tiers commonly log requests, and a few large providers serve most Solana traffic, so a handful of companies can map IP addresses to vaults at scale.

Balance polls, subscriptions, and sendTransaction requests all carry your IP address.

Your RPC provider maps your IP to your vault

Wallets build transactions in recognizable ways: a fixed <code>SetComputeUnitLimit</code> and <code>SetComputeUnitPrice</code> pair, a particular instruction order, the same address lookup tables, the same tip account for a block-engine bundle. Combined with the precompile instruction, this shape usually identifies which passkey wallet you use, and narrows the set of people you could be.

Compute budget values, instruction order, and lookup tables fingerprint who built the transaction.

Transaction shape reveals the wallet software

Solana's fee payer must be the first <code>ed25519</code> signer of the transaction, so a passkey alone can never submit anything. In practice a relayer run by the wallet provider adds its signature and pays.<br/><br/>The relayer sees your IP address, the time of each request, and the full transaction before it lands. On-chain, its address appears as the fee payer of every transaction your vault makes. If many users share one relayer this adds some cover, but a relayer used by only a few vaults links them all.

Someone else's ed25519 key signs and pays for every passkey transaction.