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. 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.

The fee payer sees, and links, your activity

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. 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

WebAuthn only hands you the public key at creation time, which makes it look private. It isn't. ECDSA allows public key recovery: from one signature and the signed bytes you get at most two candidate keys, and a second signature leaves exactly one. Combined with the vault derivation, a single leaked assertion can reveal your vault. On Solana the key is in the instruction anyway. This matters for assertions you send off-chain, for example to a backend for login, or to a relayer before submission.

One signature plus its message is enough to recover the passkey's public key.