GHOSTSIG
the passkey is the private key
New account
····
paste a transaction to see what will be signed
Derivation
about
A passkey normally proves who you are. This one is the account. The WebAuthn PRF extension returns 32 bytes that never leave the authenticator unless you verify, and those bytes are mapped to a secp256k1 scalar. Since secp256k1 is XRPL's native key type, that scalar is an account master key directly, with no wrapping layer in between.
PRF → HKDF-SHA256 (48 bytes) → mod n−1, +1 → base58(0x00 ‖ RIPEMD160(SHA256(pk)) ‖ checksum)
48 bytes rather than 32 keeps the modular bias below 2⁻¹²⁸, and the reduction uses the scalar group order n, not the field prime. Address derivation has no network component, so the same passkey gives the same address on every network.
Every payment takes a fresh passkey verification. The transaction's signing digest is used as the assertion challenge, so the prompt approves that one payment rather than the whole session: change the amount or the destination and the digest changes with it. The key is re-derived for that signature and zeroed straight after, so between payments there is no key in memory, only a credential id and a public key.
One credential controls the account, with no backup, no rotation and no recovery. Lose the passkey and the account is gone, on any network. The key also passes through ordinary page memory while signing, which is a real downgrade from the passkey's own hardware-held key and the reason production wallets isolate this in a separate origin.
The raw tab signs transactions this wallet does not otherwise build. JSON is serialized here and submitted; serialized hex is signed and handed back, because inserting a signature into opaque bytes would need a decoder this page does not carry. Issued-currency amounts and paths are refused by name rather than mis-encoded.