The 37-byte <code>authenticatorData</code> is part of the signed message, so it sits inside the precompile instruction: • <code>rpIdHash</code>: SHA-256 of the domain. Hash a list of likely wallet domains and compare. • flags: backup-eligible and backed up usually separate an iCloud or Google synced passkey from a hardware key. • <code>signCount</code>: synced passkeys report <code>0</code>, while hardware keys increment it. An increasing counter shows how often the key is used and orders your transactions across vaults.

rpIdHash, backup flags, and signCount are signed, so they go on-chain too.

authenticatorData fingerprints your device

SPL tokens don't live in the vault itself. They live in associated token accounts (ATAs) whose addresses are a PDA of <code>(vault, token program, mint)</code>. A single <code>getTokenAccountsByOwner(vault)</code> call returns every token and balance you hold, and the same applies to NFTs and compressed assets through DAS indexers. A passkey vault makes this worse, not better: every token account points back to one long-lived owner that is itself linked to your public key.

Associated token accounts are derived from the vault address and are public.

Your token holdings are one RPC call away

A passkey never signs your Solana transaction directly. It signs <code>authenticatorData || SHA-256(clientDataJSON)</code>, where <code>clientDataJSON</code> is built by the browser: <code>{"type":"webauthn.get","challenge":"…","origin":"https://wallet.example"}</code> To prove that the challenge equals the transaction hash, a program has to receive the full <code>clientDataJSON</code> in instruction data and parse it. That publishes the exact origin, subdomain included, next to your public key. It also costs 100–200 bytes of a transaction that is capped at 1232 bytes.

Verifying the challenge on-chain means publishing the origin you signed on.