Docs · Concepts

Security model.

Be precise about what CLAIMA defends against, and what it intentionally doesn't.

Trust model

You have to trust four things to use CLAIMA safely:

  1. Your wallet extension not to leak the keys it holds.
  2. Your browser not to leak the password you type into the form or the keypair generated in memory.
  3. The RPC endpoint not to censor your transactions. (Censorship doesn't affect security — only liveness.)
  4. The Solana network to include and finalize your transactions in line with its consensus.

You do not need to trust CLAIMA's servers — we run static hosting. We can't see your password, your encrypted blob, or your wallet, and we can't reverse or freeze a transaction.

Threats we cover

  • Link interception alone. An attacker who sees the URL without the password sees only the encrypted blob. Brute-force requires guessing the password against PBKDF2 with 250k SHA-256 rounds — slow per guess, infeasible against a strong password.
  • Tampering. AES-GCM authenticates the ciphertext. Any modification to salt / iv / ciphertext / pubkey produces an auth-tag mismatch and the claim fails cleanly with Wrong password or tampered link.
  • Server-side data leaks. We have no database to leak. The URL fragment is never sent to our origin.
  • Recipient unknown at send time. Solving exactly this problem is the point — the sender doesn't need to know the recipient's wallet when funds are locked.

Threats we don't cover

  • Both link and password leaked. Anyone who has both can claim. That's the whole point of the password — it is the access credential.
  • Compromised wallet extension. If your wallet extension is malicious or compromised, no client-side scheme can protect you.
  • Compromised browser. Same caveat. Don't create or claim links from machines you don't control.
  • Phishing copies of CLAIMA. Always verify you are on the official domain before connecting a wallet or typing a password.
  • Weak password + targeted attacker. A determined attacker with the URL and a list of common passwords will burn a lot of CPU but eventually crack a weak password. The strength meter is there to discourage this.
  • On-chain privacy. Amounts, timestamps, and vault addresses are public. CLAIMA does not anonymize them.

Choosing a password

  • Minimum length is enforced at 8 characters. The longer, the better — PBKDF2 cost is fixed per guess, so password entropy is what saves you.
  • Mix letters, digits, and symbols. The on-page meter scores length and variety together.
  • Avoid passwords you reuse elsewhere — if it leaks somewhere else, it leaks here too.
  • For high-value drops, generate a random password and share it once, in person or through a secure channel.

If a password leaks

Once a password and the corresponding URL are both in the wild, anyone can claim. There is no "revoke link" action — the temp vault doesn't know who's authorized beyond "whoever proves the secret."

The fastest mitigation is to claim it yourself immediately — open the link in your own browser with your own wallet, enter the password, and pull the funds back. This is your only built-in recovery option today; a future on-chain program would let the sender reclaim without racing.

Responsible disclosure

Found a vulnerability? Please don't disclose it publicly. DM the X / Twitter account in the site footer and we'll coordinate a fix. We will credit reporters who follow responsible disclosure in the changelog.

© 2026 CLAIMA