Security · the whole model
How Clasp works
Clasp derives one 16-byte secret from a WebAuthn PRF assertion on your own device, and builds both an XRP Ledger account and an XRPL EVM account from those same bytes. It never stores that secret and never sends it — the app is a static export, so there’s no server to send it to and no database to keep it in. This page is the whole model: the derivation chain as it actually runs, how to open both accounts without Clasp, and what Clasp doesn’t claim.
01
The three claims
We never make your key.
So we can't make it badly. The chip does — hardware built by people much larger than us, which we think is the right way round.
navigator.credentials.get() · the chip's answer
We never store your key.
Almost every wallet keeps something somewhere — an encrypted file, a server, a recovery service. We keep nothing. There's nothing to break into.
output: "export" · no API routes, no middleware
We never see your key.
It's built in your browser and it dies with the tab. Close it, and the key is gone until your next touch.
memory only · never written to storage
02
The two keys
Two keys, and they aren’t interchangeable. One gets you in. The other is the wallet.
The passkey is convenience
One touch re-derives the wallet, on every device the passkey syncs to — iCloud Keychain, Google Password Manager. Losing a device loses nothing, because the passkey comes back with your platform account.
The seed is ownership
It is the wallet itself, shown once when you create it. One backup covers both ledgers: it opens the XRP Ledger account in Xaman or Joey, and the XRPL EVM account in MetaMask — with or without Clasp.
Losing one of the two costs you nothing. Losing both is unrecoverable — there is no server copy, by design.
A different address than you expected
Each passkey opens exactly one wallet. A second passkey — made on another platform account, or after deleting the first — opens a different, empty wallet. No funds moved; they are still under the first passkey. Check your password manager’s passkey list for this site. If that passkey is gone for good, the seed still opens the original wallet.
Lost the passkey
The seed you wrote down opens the wallet in one tab, for as long as that tab stays open: recover from seed. The seed is held in memory only — nothing is stored, and the session ends when the tab does.
Clasp will never ask for a seed anywhere else. Normal sign-in is always a passkey touch — there is nothing to type.
03
The derivation chain
One touch produces one 16-byte secret, and both accounts are that secret re-encoded. Below is the chain as it runs, and the constants it runs on.
The two salts are different things, and it is the easiest line on this page to misread. clasp:xrpl:v1:prf-salt is the salt WebAuthn evaluates the PRF against, inside the authenticator. HKDF’s own salt is empty.
| Constant | Value | Where it lives |
|---|---|---|
| PRF salt | clasp:xrpl:v1:prf-salt | UTF-8 bytes. Evaluated on the passkey itself, on create and on every unlock — lib/prf.ts |
| HKDF hash | SHA-256 | lib/derive.ts |
| HKDF info | clasp:xrpl:v1 | lib/derive.ts |
| HKDF salt | Empty — zero bytes, and not the PRF salt above. | lib/derive.ts |
| HKDF output | 128 bits — the 16 bytes both accounts come out of. | lib/derive.ts |
| XRP Ledger key | ed25519, from those 16 bytes. The sEd… seed is the same 16 bytes, base58 with the ed25519 family prefix. | lib/derive.ts |
| BIP39 | 12 words, English wordlist, no passphrase. | lib/evm/derive.ts |
| EVM address | secp256k1 → keccak256 → last 20 bytes → EIP-55. | lib/evm/derive.ts |
There is no BIP39 passphrase — the seed function is handed the twelve words and nothing else. That omission is what lets the phrase open at another wallet’s default settings, with no extra field to remember. §04 is the import itself.
Sixteen bytes, not thirty-two — so the seed is a standard XRPL family seed that imports anywhere, and the same bytes re-encode as a standard 12-word phrase at the default path. One backup, two chains.
Everything above runs client-side, in the tab. The app is a static export — there is no server to send a key to and no database to keep one in.
The derivation constants are frozen and pinned by vector tests. If those tests fail, the code is wrong — never the vectors.
The signing screen shows every request before it signs it — on the XRP Ledger only the shapes it can render in full, on XRPL EVM the exact bytes it was handed, read back as far as they can be read. §05 is the detail.
04
Recovering without Clasp
Clasp is a convenience, not a custodian. Both accounts open in software we don’t control, using the backup you already wrote down — there’s no export step, no Clasp-only file, and nothing to ask us for.
| What you hold | XRP Ledger account | XRPL EVM account |
|---|---|---|
| The passkey | One touch, right here. | The same touch — one assertion derives both. |
| The sEd… seed | Xaman, Joey, or any XRPL tool. It goes in unmodified. | Opens this too — the seed and the words are the same 16 bytes. |
| The 12 words | Re-encode the 16 bytes as a family seed with standard BIP39 tooling. | MetaMask, Rabby, or any BIP39 wallet, at the default path. |
The XRP Ledger account
The seed goes in Xaman’s import-account field, or Joey’s, or anything else that takes a family seed. Nothing gets converted on the way — what Clasp showed you at creation is already the standard thing those wallets read.
That’s true because Clasp derives to sixteen bytes and not thirty-two. An XRPL family seed encodes exactly 16 bytes, so deriving to that width produces an ordinary sEd… seed; deriving a raw 32-byte key instead would have produced something only Clasp could read. It’s the most consequential decision in the whole design, and this row of the table is the entire reason for it.
The XRPL EVM account
The 12 words import into MetaMask, Rabby, or any standard wallet at the default path, with no passphrase. There’s no extra field to fill in: Clasp derives with an empty BIP39 passphrase precisely so that the default import works.
These 12 words are your sEd… seed in another form — one backup covers both chains. §03 above sets out the chain that turns one into the other, step by step.
The seed alone is enough
The backup ceremony shows you one thing, and it’s the seed. If that’s all you wrote down, you haven’t lost anything on the EVM side: any XRPL family seed decodes back to the same 16 bytes, and those 16 bytes are what the 12 words spell out. The seed reconstructs the EVM account whether or not you ever looked at the phrase.
If you want the phrase anyway, it’s in the wallet — Settings, then Security & backup, then 12 words, behind a fresh passkey touch. It isn’t a second backup. It’s the same secret in the spelling some wallets insist on.
You can leave whenever you want
Your recovery phrase is a standard one — it works in the common wallets people already use. If Clasp vanished tomorrow, your money wouldn’t. That’s a deliberate engineering decision, not a courtesy: we built your key to be an ordinary key rather than a Clasp-only one, and it cost us real constraints to do it. A wallet that makes leaving easy is saying something about why it expects you to stay.
05
What Clasp will sign
Clasp opens its own window for every request, shows you what you would be signing, and takes one touch. What that review can promise you differs by chain, and the difference is deliberate.
Every request is its own window
When a site wants to use your wallet, Clasp opens its own window, with its own address bar. You see which site is asking and what you would be signing, and you approve it with one touch. The site never sees your key — it gets back the signed result, never the thing that signed it.
Nothing stays connected afterwards. Clasp keeps no list of approved sites, because every request is approved on its own — there is no permission to revoke, because nothing is holding one. A site may remember your address between visits, but an address is public, and that memory is the site’s rather than ours.
Two chains, two rules
The XRP Ledger and XRPL EVM are not the same problem, so Clasp does not pretend they are.
| Chain | What Clasp will sign |
|---|---|
| XRP Ledger | Payments and trust lines, rendered whole. Everything else is refused before you are asked. |
| XRPL EVM | Whatever the site asks — signed as the exact bytes it sent, and shown at the deepest reading Clasp can get. |
The XRP Ledger: a short list, rendered whole
Clasp signs two kinds of transaction there and no others: a payment, and a trust line. Both are small enough to render completely — who is being paid, in what, how much — so the review is the transaction itself rather than a summary of it. Anything else is refused on the wire, before a screen is ever drawn.
XRPL EVM: the exact bytes, and the best reading of them
A contract call can be anything at all, and a wallet that signs only the handful of shapes it recognises cannot be used with most of the chain. So this side is open by design: Clasp signs the exact bytes the site sent, and spends its effort reading them back to you instead of refusing them.
You get the deepest reading that settles before you are asked to approve.
A known operation — a transfer, an approval — decoded in full: the real amount at the token’s own decimals, read from the token contract itself rather than taken from the site, and who is being paid or given permission.
Otherwise, a decode from the contract’s published source, labelled on the review as coming from a block explorer rather than from us. The function’s name is the explorer’s claim; every amount and address beside it is read out of the bytes themselves.
At the floor, the selector, the length and the exact bytes, shown whole, under a standing warning. This reading is signable. It is the one that never refuses.
The reading cannot change under you. Approve stays disabled until it settles, so a request can never shift from one reading to another after you have looked at it.
What a warning means here
This page used to say Clasp refuses anything it cannot put in plain words. On the XRP Ledger that is still exactly what happens. On XRPL EVM it is not, and the rule there is a different one: we never hide what we cannot read.
So a warning on an EVM review sits beside a working Approve button. It is a fact we found and stated, not an action we blocked. An approval with no limit, a destination that is the zero address, a call the network says will probably fail — each of them is named on the review, and none of them is stopped.
At the floor that means you can be asked to approve bytes nobody could name. Clasp will say so, in about those words, and it will still let you sign. If you cannot tell why a site wants that, that is your answer.
Still refused outright
Two kinds of request are refused on XRPL EVM rather than rendered. eth_sign, the legacy method that signs a hash with nothing behind it to render — no wallet should still be offering it. And a sign-in message whose stated domain does not match the site actually asking for it, which is how a signature collected on one site gets used on another.
Separately, and on both chains: Clasp fills in the network fee and the transaction’s number itself, and a request that tries to set either of them for you is refused rather than quietly corrected. A site never decides what a transaction costs you.
The wire protocol, the names for those three readings and the exact codes a refusal returns are on the developers page.
06
Living with it
The practical part. What you install, what carries across your devices, where each thing lives, and the one cost the XRP Ledger asks of every account.
- Nothing to install
- No app store, no browser extension. It’s a web page.
- Every device you own
- Your passkey syncs — phone, laptop, tablet. The same wallet everywhere, nothing set up twice.
- New phone, same wallet
- Nothing to restore, nothing to type in.
- Nothing stays connected
- When you’re done with a site, you’re done. No lingering permissions to clean up later.
THE USUAL WAY
- 01 A site shows a QR code
- 02 Unlock your phone
- 03 Open the wallet app
- 04 Scan the code
- 05 Approve, switch back
- 06 Wait to see if it worked
WITH CLASP
01 Touch. Done.
Where things are
One wallet holds both ledgers, and Home shows all of it. The Both / XRP Ledger / EVM switch above your balance only narrows what you are looking at — it never changes which wallet you are in, and nothing you sign reads it.
Your address and its QR code live on Receive. The full addresses, the light or dark theme, and the test-network switches are in Settings.
Reserves, not fees
The XRP Ledger locks 1 XRP while an account exists, plus 0.2 XRP per owned object (like a token trust line). That XRP stays yours — it’s reserved, not spent. Creating an address costs nothing; it activates when it first receives 1 XRP.
07 · The honest part
What we don’t claim
We're a website — check you're on the real address before you unlock.
If someone tricks you into approving something on a fake site, we can't undo it.
On XRPL EVM we'll sign a request we can't explain — you get the raw bytes and a warning, not a refusal.
Your wallet is only as safe as the phone or laptop you open it on.
The security chip is Apple's or Google's work, not ours. We depend on it.
Token art, contract names and decoded calls come from explorers and issuers, not from us. We label where each one came from, but we can't vouch for it.
Every security page says “bank grade” and means nothing by it. We’d rather say the true thing.
That’s the whole model.
No vault anywhere, nothing to install — and a way out whenever you want it. A wallet takes about as long as a touch.
claspwallet.com