How it works.

CLAIMA is fully client-side. There is no API, no database, no background worker. The marketing site and the application are static assets served by Vercel. Everything else happens in two places: your browser and the Solana network.

The unit of value transfer is the claim link: a URL whose fragment carries an encrypted blob, a temporary wallet pubkey, a lamport amount, and a network label. Anyone who has the URL and the password can claim the locked balance to any wallet they control.

1. User opens /c/new and connects a wallet.
2. User enters an amount, a password (min 8 chars), and an optional note.
3. CLAIMA generates a fresh ed25519 keypair (the "temp vault") using Keypair.generate() from @solana/web3.js.
4. CLAIMA bundles { secretKey, note } as JSON and encrypts it with the password using PBKDF2 (250,000 SHA-256 rounds) → AES-256-GCM.
5. The user's wallet signs a single SystemProgram.transfer instruction sending the locked amount from the user's wallet to the temp vault.
6. CLAIMA writes the full payload (pubkey, lamports, network, salt, iv, ciphertext) to the URL fragment and surfaces the link, QR code, and share buttons.
7. The sender shares the URL and the password through two different channels.

1. Recipient opens the URL. The browser sends a GET request to /c; the fragment after # is read locally and never transmitted.
2. CLAIMA decodes the payload, fetches the temp vault's current balance, and shows a preview card.
3. Recipient connects their own wallet.
4. Recipient enters the password. CLAIMA re-derives the AES key from the password and the payload's salt, decrypts the blob, and reconstructs the temp keypair.
5. CLAIMA builds a transfer of the vault's full balance minus a small fee reserve to the recipient's wallet. The temp keypair signs it locally; the recipient's wallet does not sign anything.
6. The transaction is sent through the configured RPC and confirmed. CLAIMA re-polls the vault balance to confirm it's zero, then shows a success card.

All crypto is done with the browser's native WebCrypto API. No third-party crypto library is bundled.

• Key derivation: PBKDF2 with SHA-256, 250,000 iterations, 16-byte random salt per link.
• Symmetric encryption: AES-256-GCM, 12-byte random IV per link. GCM provides authentication — tampering or a wrong password fail the same way (auth tag mismatch).
• Encoding: URL-safe base64 (base64url, no padding) for salt / iv / ciphertext. The full payload is a base64url-encoded JSON string in the URL fragment.

See URL payload format for the byte layout.

A complete sender→recipient round trip costs two Solana transactions: one to fund the vault, one to drain it. Each is a single-signature SystemProgram.transfer with the standard base fee.

Sender funding tx       : ~5_000 lamports = 0.000005 SOL
Recipient drain tx      : ~5_000 lamports = 0.000005 SOL
Total network fee       : ~10_000 lamports = 0.00001 SOL

CLAIMA itself charges no fee at this time. The temp vault is a regular system account; once it's drained to zero lamports it is automatically removed from on-chain state.

• Reclaim. If a recipient never claims, the funds sit in the temp vault forever unless someone can produce the password. The current design has no sender-side escape hatch — a future on-chain program could add one.
• SPL tokens. Only native SOL today. USDC and other SPL tokens require Associated Token Account logic that is on the backlog.
• Anonymity. Amounts and vault addresses are visible on the public Solana ledger like any other transaction. CLAIMA hides the recipient identity at the moment of send, not after.