To avoid a biometric prompt for every action, some passkey wallets let the passkey authorize a short-lived <code>ed25519</code> session key, often stored in the browser. The registration transaction links the session key to the vault. Every transaction signed by the session key is then attributable to you, and if the browser storage leaks, so does spending power until the session expires.

Temporary ed25519 keys that avoid repeated prompts are registered on-chain.

Session keys are identities too

A passkey is bound to its RP ID, so only pages served from <code>wallet.example</code> can ask it to sign. If that domain expires, is seized, or is taken over, you can no longer sign for a vault whose only authority is that passkey. The funds stay on-chain but frozen, and a new owner of the domain could prompt your passkey on their own page.<br/><br/>Passkeys.is documents a workaround: serve the open-source wallet locally on the old domain using <code>/etc/hosts</code> and a locally trusted TLS certificate (for example <code>mkcert</code>).

A passkey only signs for the domain that created it, but your SOL stays on-chain.

If the domain disappears, the vault is stuck

A passkey prompt takes seconds, and a <code>recentBlockhash</code> expires after about 150 slots. Some wallets therefore use durable nonces, so a transaction can be signed now and submitted later. The nonce account is a public account that each transaction advances, so every transaction using it is linked, and so is whoever created and funded it.

A reused nonce account ties every transaction that uses it together.