Kaspa Forge
Documentation · Kaspa Escrow

How Kaspa Escrow works

Kaspa Escrow is a guarantor for P2P deals that physically can't steal: the money sits in an on-chain covenant, not with us, and no spend path in that covenant pays anyone except the buyer, the seller or the visible service fee. This page covers the contract, the deal lifecycle, the encrypted deal chat, disputes and the security boundaries — honestly, including what the contract can't do.

The covenant: ten paths, three possible payees

A deal is an instance of the open-source contract escrow.sil (Kaspa Toccata, mainnet) with two states: active (the dispute window is running) and disputed (waiting for a verdict). Its complete list of spend paths:

Release — buyer signsEverything to the seller (minus the fee). "I got what I paid for."
Refund — seller signsEverything back to the buyer (minus the fee). A seller can concede at any point, even mid-dispute.
Mutual — both signAny split the two sides agree on. The fee output is mandatory by design — otherwise "mutual" would be a free bypass of every other path.
Dispute — buyer signsFreezes the deal into the disputed state and starts the arbiter's deadline clock. No money moves.
Auto-release — keylessThe dispute window closed and nobody acted → funds go to the seller. Protects the seller from a buyer who received the goods and went silent.
Arbitrate — arbiter signsThree variants: all to the buyer, all to the seller, or a split between them. There is no path that pays the arbiter or any third party — the network rejects such a transaction outright.
Timeout — keylessThe arbiter missed their deadline → funds go to the deal's default side (normally the buyer), with no service fee. A deal can never hang, even if we vanish.

That's the whole trust story: we are not asking you to believe the guarantor is honest — the guarantor holds nothing and has no door to walk the money out of. Being precise about the boundary: every spend path in the covenant pays a party of the deal — the operator can't redirect funds; whether a disputed verdict is fair is the work of a human reading your evidence.

A deal, start to finish

  1. Create. Either side opens a new deal: role, type (goods / OTC exchange / service), amount, terms. Sellers of physical goods also pick a shipping geography — the other side sees it before joining. You get an invite link (a one-time code, valid 72 h).
  2. Join. The other side opens the link, sees all terms — including the dispute window — and joins. Each side's deal key is generated in their own browser and saved into their encrypted Desk profile.
  3. Fund. The buyer sends KAS to a funding address (their own — its key is in their profile) and presses "Lock into escrow": the browser assembles the covenant on-chain. From this moment the money is under the contract's rules, nobody's wallet.
  4. Settle. Goods delivered → buyer presses Release. Deal fell through → seller presses Refund. Problem → buyer opens a dispute during the window. Nobody does anything → auto-release to the seller when the window closes.
Deal sizefrom 50 KAS (below 50 KAS the arbitration minimum would eat too large a share).
Dispute windowYour budget for delivery + inspection: the timer starts the moment the escrow is funded, and until it runs out the buyer can open a dispute — that is the normal buyer protection, not an emergency. Chosen by the deal's creator from eight presets: 24 h / 48 h / 72 h / 96 h / 120 h / 7 days / 14 days (domestic shipping) / 30 days (international shipping) — shown to the other side before joining. Defaults by deal type: goods 7 days (a physical parcel needs time to arrive), OTC 24 h, service 120 h. Received the goods with a dispute already open? No problem — a normal Release closes it. Arbitrary values are deliberately impossible (no "micro-window" tricks that would strip the buyer of a real chance to dispute).
FeesCreating a deal — free. Release / refund / mutual — 0.5% (min 1.2 KAS, which also pays for the on-chain chat). Arbitration, only if a dispute happens — 2% (min 5 KAS). Timeout — no service fee. The fee is enforced by the contract itself and visible before you confirm. Telegram guarantors charge 3–10% and hold your money; we charge 0.5% and can't.

OTC deals: swapping KAS for another asset

In an OTC / crypto exchange deal the two legs live on different chains: the buyer locks KAS in the covenant, and the seller pays the counter-leg — USDT/USDC on another network, a native coin, or fiat. The escrow protects the KAS; the counter-payment happens on its own chain. Two things turn that from a blind swap into a safe one:

Fixed at creationThe buyer picks the currency / network and the amount of the counter-payment and enters the receiving address where they expect it — checked against the chosen network the moment you type it. These terms are locked into the deal and visible to both sides and the arbiter; they can't be quietly changed in chat later.
Order that protects the sellerThe buyer funds the KAS into escrow first. Only then does the seller pay the counter-leg. Until the escrow is funded the seller's payment panel stays hidden behind a warning — never send your payment before the KAS is locked, or you would be paying into an empty escrow.
On-chain auto-verificationFor supported networks the seller presses “I have paid” — the service finds the recent payment to the buyer's address (or you paste the transaction id) and checks it live on the public blockchain. A green “payment confirmed on-chain” badge appears for both sides only when everything lines up: the transaction succeeded, has enough confirmations, uses the canonical token contract (no fake-USDT), the recipient is exactly the buyer's fixed address, the amount is at least what was agreed, and the payment is newer than the deal itself (anti-replay). One transaction can back only one deal.
A signal, not an actionThe badge moves nothing on its own. Release stays the buyer's own signature — even with a green badge, confirm the funds truly arrived (an exchange deposit can lag the on-chain confirmation), then release. In a dispute the verified leg is the strongest possible evidence that the seller performed, and the arbiter sees it.

Auto-verified networks: USDT on Tron, TON, Ethereum, BSC, Polygon and Arbitrum; USDC on Ethereum, BSC, Polygon, Arbitrum and Base; native TRX, TON, ETH, BNB; and BTC, LTC. Any other crypto or fiat still works as an OTC deal — the leg's terms are recorded and shown to both sides — but there is no live badge, so you confirm receipt yourself before releasing.

The deal chat: evidence that can't be forged

The chat inside every deal is not a support chat — it's end-to-end encrypted on-chain messaging (the Kasia protocol on the Kaspa BlockDAG). Each message is encrypted in your browser and anchored as a Kaspa transaction; photos, videos and documents are encrypted per-file with an integrity hash anchored on-chain. The server relays and stores only ciphertext it cannot read. The consequence matters in a dispute: the correspondence can't be forged, edited or backdated — it is the case file. A tiny on-chain fee for your chat messages is covered by the service.

Disputes: a rail, not a favor

  1. The buyer opens a dispute during the window; the funds freeze in the disputed state. Both sides submit their claims (refund / release / split) with their story.
  2. One side reveals its chat key to the mediator. The chat key is separate from the deal key — revealing it exposes the correspondence, never the money. Until someone reveals it, nobody — including us — reads the chat.
  3. The evidence is examined. Attachments are checked for integrity against their on-chain anchors, and an AI mediator reads the deal terms, the thread and the files, then proposes an outcome in minutes. The proposal is non-binding: it executes only if the conceding side signs it (a split needs both signatures).
  4. Disagree, or 24 hours of silence? The case escalates to a human arbiter, whose signing key is kept offline, off the server. The arbiter's verdict — all to buyer, all to seller, or a split — is still confined by the covenant to those destinations only.
  5. The arbiter goes silent? The contract's keyless timeout returns the funds to the default side after the deadline. Every deal terminates — by settlement, verdict or timeout.

When a deal closes, the sensitive material — claims, revealed evidence, forensics — is erased from the server. See Escrow privacy for exactly what is stored while a deal is live.

Security boundaries

  1. The arbiter can't steal — no covenant path leads outside the buyer/seller/fee triangle.
  2. The server can't steal — it never holds deal keys; the keyless paths (auto-release, timeout) hard-wire their payees.
  3. The service token can't spend — it's a per-side capability that unlocks reading state, chatting (ciphertext only) and filing dispute claims; every fund-moving action still needs a signature from the deal key, which never leaves the browser. Full boundary: Escrow privacy.
  4. The chat is private until you open it — plaintext exists for the mediator only after a party voluntarily reveals a chat key, and that key can't move funds.
  5. The AI never executes anything — its proposal becomes real only through a party's signature or the human arbiter's; the covenant caps the outcome either way.
  6. The service dying ≠ losing the deal — timeouts are keyless and on-chain. The deal recovery page shows how a deal outlives the website.
Honest boundaries. The contract passed native VM equivalence tests and an adversarial on-chain cycle (52/52 self-tests). Deals start at 50 KAS (no upper limit). One thing no escrow can see is the off-chain world — whether the parcel actually arrived. That's precisely why the dispute rail exists, and why the tamper-proof chat is where your deal should live.

See also: Kaspa Escrow overview · deal recovery · the Marketplace — listings with this escrow built in