A passkey normally proves who you are. Here it is the account. The WebAuthn PRF extension
returns 32 bytes that only a verified prompt can produce. Those bytes are the master secret of
SEP-52, and each ledger derives its own ed25519 key from them: one passkey, two keys, two
addresses.
Every payment takes a fresh passkey prompt. The transaction's signing digest is the assertion
challenge, and nothing verifies the assertion. The challenge does not limit the key: every
prompt unlocks the same key for this page, and the page signs the payment on the card. The key
is re-derived for the signature and zeroed after it;
between payments the page holds a credential id and the passkey's public addresses. The same address
exists on every network of a ledger, and each ledger signs with its own key.
One credential controls both accounts. There is no rotation. On a hardware
key, losing it is final unless you wrote down backup shares. A passkey that can be synced
(iCloud Keychain, Google Password Manager) carries the secret with it, and your Apple or Google
account becomes what stands between an attacker and your funds.
Backup shares are the master secret, split as SEP-52 describes: SLIP-39, 33
words each for a passkey's secret, any m of n rebuild it and fewer reveal
nothing. They are shown once, never stored and never sent, and anyone holding enough of them
holds both accounts without a passkey. Every backup is a new set, and sets do not mix; every set
ever made still restores the account until its shares are destroyed. A
session restored from shares keeps the secret in this page's memory until you disconnect or it locks
after ten minutes idle, with no prompt before a signature, and says so in red.
The derived key exists in memory for the moment it signs. Zeroing clears every buffer this
code owns, but the curve library turns the key into immutable numbers that nothing can
erase, so a memory dump taken after a payment can still contain it. What you are trusting is
this origin and the code it serves.
The raw tab signs transactions the wallet does not build: transaction JSON or
serialized hex on the XRP Ledger, a base64 envelope on Stellar. For XRP Ledger JSON the preview
shows the transaction exactly as it is signed, with when it expires. For hex it shows the
digest and asks you to tick a box. On Stellar it decodes payments, account creations, trust
lines and account merges, and asks you to tick a box where it cannot decode everything. It is
not a verdict: the page does not judge a transaction, so check a payload from elsewhere in
Stellar Lab or an XRPL decoder before you paste it.
Connected apps. An app that uses a wallet kit can open this page as a popup and
ask for one signature. The card names the app's origin. The request is previewed as the raw tab
previews a paste, and the page takes one passkey prompt for each signature. The app learns your
address, your public key and the signature. Nothing about the app is kept. Read the card as you
would a paste.
Offline. The page installs and runs from this device: its code, its fonts and
the libraries it uses are served from this origin and kept by the browser, and signing in needs
no node. The send and assets tabs read the ledger before they build anything, so they are
disabled until a node answers; the raw tab is not. A signature made with no node in reach opens as a QR code and as
text, to submit from any device that can reach the ledger (Stellar Lab's submit page, an XRPL
submit tool) before it expires. Without a node, a raw XRP Ledger transaction needs its Sequence
and Fee written in; a Stellar envelope carries its own.
Assets. Trust lines and MPTs on the XRP Ledger, trust lines and SEP-41
contract tokens on Stellar, each shown with what the ledger says about it. The curated lists
(XRPL Meta, StellarExpert's SEP-42 Top 50) are asked when you open one, and once for the
logos of what you hold; the request names nothing about you. An asset in the list shows the
logo the list gives it, any other the first letter of its code. While a list is open, a pause
in your typing sends the text in the field to the same source's search. A listing is not
verification, and neither is a logo.
The console. Its session log is what this page did. Its second column, on the
ledger, is what the node says about the account: every transaction it signed and every one that
only touched it. It is read when the console opens and again at each refresh, a page at a time, and kept nowhere. Payments
that others sent you under an amount are hidden by default, and counted. Arrows join the lines
of a transaction the page signed to its row.
Colophon
No backend, no accounts, no analytics on this site. XRP Ledger transactions carry a public
source tag that anyone can count. What this browser stores, key by key, is on the Cookies
page below; none of it is key material.
PRF → SLIP-10 m/44'/144'/0'/0'/0' → XRPL: base58(0x00 ‖ RIPEMD160(SHA256(0xED ‖ key)) ‖ checksum) · PRF → SLIP-10 m/44'/148'/0' → Stellar: base32(0x30 ‖ key ‖ CRC16)
