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

WebAuthn returns ASN.1 DER signatures, and authenticators may produce either of the two valid <code>s</code> values. Solana's secp256r1 precompile requires the compact 64-byte <code>r||s</code> form with <code>s ≤ n/2</code>, to prevent malleability. Submitting raw DER, or a high-S value, makes the transaction fail.<br/><br/>A transaction that fails after landing still pays fees and still puts your public key on-chain, so it leaks data for nothing.

The precompile only accepts low-S, 64-byte r||s signatures.

High-S signatures fail, and still leak

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.