Kaspa Escrow — Privacy Policy

The short version

Kaspa Escrow is non-custodial and account-less. Your deal keys (deal, funding and chat keys) are generated and used only in your browser and are never transmitted to us. The deal chat is end-to-end encrypted — the server relays ciphertext it cannot read. The one deliberate exception is a dispute: to let the arbiter judge, you may reveal your chat key (never your escrow key), and only then can the revealed conversation be decrypted for the arbiter. No sign-up, no advertising, no third-party analytics SDKs.

What stays only in your browser

The private keys for your side of the deal — the escrow key that signs release/refund/dispute, the funding key (buyer), and the chat key — plus your service token. They live in this browser's local storage (in your encrypted master key file) and can be removed with "Forget this deal". Back up the master key file from your Desk (Export key file); it is the only copy of these keys, and we never receive it.

What the server receives and stores

• Deal terms — type, amount and the conditions text you type. These are stored in the clear (not encrypted): the other party sees them in the invite preview before joining, and the arbiter sees them in a dispute.
• Public parameters — each side's public keys and the covenant addresses, needed to build and watch the on-chain deal.
• Service tokens — a random token per side that authorizes reading and acting on the deal within limits; it can never move funds by itself. Saved in your master key file (back it up from your Desk). Full breakdown: what it can and cannot do.
• Invite link / code — a capability: whoever opens it can join as the counterparty. It expires after 72 hours if unused.
• Chat ciphertext & encrypted media — the deal chat runs on the Kaspa BlockDAG (Kasia protocol); the server relays and stores only ciphertext and already-encrypted media blobs. It cannot read your messages, photos or videos.
• Dispute claims — if a dispute is opened, the "what I ask for + why" statement each side submits.
• Telegram chat ID — only if you connect Telegram notifications for the deal.
• Standard web-server logs (IP, request path, user agent), kept briefly for abuse protection, not used for profiling.

All on-chain transactions and covenant balances are public data on the Kaspa blockchain by design.

OTC deals with on-chain auto-verification

For OTC deals, any crypto counter-leg fixes the chosen method, the currency label (for an "other crypto" pick like XMR), the expected amount and the buyer's receiving address as server-side deal fields — visible to the server and both sides outside any dispute — whether it's a supported network (Tron, Ethereum/BSC/Polygon/Arbitrum/Base, Bitcoin, Litecoin — see the network picker in the deal wizard) or an "other crypto" pick like Monero. Only supported networks get live verification: the server checks the seller's declared txid automatically instead of waiting for a dispute, using the same information anyone could already read on that public blockchain if they knew the txid. For "other crypto," there's no server-side txid check — the paid-txid claim stays in the end-to-end chat only. Fiat legs (bank transfer, card, cash) are the sole fully end-to-end category: no server fields at all, only the encrypted deal chat (the "payment details" / "paid" messages).

The server keeps a snapshot of the last check (amount, recipient, confirmations, time) so both sides see the same status badge. When the deal closes, the buyer's address, the declared txid and that snapshot are erased — only the chosen method and the final verification outcome remain (anonymized). Verification is a signal, not an action — it never moves funds by itself. Release is always the buyer's own signature made in the browser; nothing on this page or in this check can release, refund or otherwise spend the escrowed coins.

Service token — what it can and cannot do

Each side of a deal gets one random token (192-bit, generated in your browser at create/join) that the panel sends with every request instead of a login. The server checks only that it matches a side's slot — it is a capability, not proof of who you are. It lives inside your encrypted master key file, next to your keys (back it up from the Desk).

With the token alone, its holder can:

• Read the deal's state — status, amounts, timers, addresses, both sides' chat public keys.
• Read the dispute's state — claims, the AI verdict, reveal flags, escalation status.
• Post to the deal chat as that side, and read the thread and download attachments — always ciphertext / already-encrypted blobs, never plaintext (the server can't decrypt them either).
• File or update that side's dispute claim ("what I'm asking for and why"), send supporting details for the arbiter's ticket, and escalate the dispute to the human arbiter.
• Submit that side's half of a mutual-settlement signature (the server stores whatever hex it's given — it doesn't check the signature is valid; only the Kaspa network does that when a transaction is actually broadcast) and read both halves once submitted.
• Request a Telegram code to link deal notifications, which includes the "funds withdrawn" alert sent when either side's payout is confirmed on-chain.

The token alone cannot:

• Move funds. Release, refund, on-chain dispute and the final mutual-settlement transaction are all signed in the browser with the deal (escrow) key and reach the Kaspa network through a separate relay that isn't token-gated at all — it just accepts an already fully-signed transaction. A token with no key can watch and talk; it can't spend.
• Read the decrypted chat. The one decrypt path, /dispute/reveal, additionally verifies that the key it's given actually derives that side's on-record chat public key — a token can't substitute for the key.
• Send money anywhere but the deal. Even the escrow key is capped by the covenant to the buyer, the seller or the visible fee; there is no destination outside that triangle for it to sign toward.

We don't have token re-issuance yet — if you believe your master key file leaked, the token inside it leaked with it, and there is currently no way to invalidate just the token. See Recover a deal for what that actually means in practice: since spend paths are capped to the buyer/seller/fee triangle above, a leaked token (or even a leaked deal key) can't be used to steal your coins outright — the real exposure is someone reading your ciphertext-only chat access or acting a little early on your side.

Disputes: reveal & what the arbiter sees

Until a dispute, the server holds only ciphertext and no one can read your chat. In a dispute, resolution needs evidence, so a party may deliberately reveal their chat key (sent to /dispute/reveal) — this is the only time a key leaves your device, and a chat key can never move funds. On reveal, the server decrypts that side's thread and stores the plaintext transcript for the arbiter only, alongside media the arbiter can decrypt with the keys carried inside the revealed messages. The AI mediator reads this to propose a non-binding outcome; a human arbiter reads it only if the case escalates. The revealed transcript is erased when the deal closes, and encrypted media blobs are deleted 24 hours after the deal closes. The on-chain ciphertext remains (it is the tamper-evident record), but without a revealed key it is unreadable.

What we never collect

Your escrow, funding or chat private keys, seed phrases or recovery sheets (we never ask for them); names, documents or KYC (there are no accounts); contacts, location or files beyond the media you attach to a deal; advertising identifiers.

Third parties

Website fonts load from Google Fonts (your IP is visible to Google on load). The support chat widget uses Cloudflare Turnstile (Cloudflare processes the challenge). Telegram delivers deal notifications if you opt in. The AI mediator runs on a third-party LLM provider, which receives only the deal terms, the revealed transcript and the claims — never any private key. The Kaspa network is public infrastructure. We do not sell or share data with anyone else.

Retention & deletion

A deal's records exist so the deal can run and be watched. The revealed chat transcript is wiped at close; media blobs are deleted 24 hours after close — save anything you need, including a purchase you received, before then. To delete a deal's remaining records (including any Telegram link), write to kaspa@officeforge.co naming the deal. On-chain data cannot be deleted by anyone — that is the nature of a blockchain.

Changes

Updates to this policy are published on this page with a new effective date.