How the Kaspa Marketplace Turns Every Listing Into an On-Chain Escrow Deal

Telegram group chats remain the default venue for peer-to-peer crypto trades in many Kaspa communities. A buyer sends KAS to a "guarantor" — a stranger with a pinned message and a reputation score — and hopes the seller ships the goods. The guarantor holds real money. If they disappear, so do the funds.

Kaspa Marketplace takes a fundamentally different approach: it wraps every listing inside a real on-chain escrow deal. Funds never sit with the operator, the seller, or any middleman. They sit in a Toccata covenant — an on-chain script whose spending rules are verified by every Kaspa node at the consensus level.

This article explains how that works, from the contract mechanics up through the listing lifecycle.

The Escrow Covenant Underneath

Every marketplace listing is backed by the same ten-path escrow contract that powers Kaspa Escrow. Think of the contract as a vending machine bolted to the blockchain: it accepts deposits, but can only dispense to three pre-committed addresses — buyer, seller, and a fixed service-fee sink. No cashier needed, no override key.

The contract lives at a P2SH address derived from three public keys: buyer, seller, and arbiter. It is compiled from the Silverscript source file escrow.sil and deployed on-chain via Toccata's transaction-introspection opcodes.

The ten spending paths cover every scenario the marketplace needs:

Dispute windows are measured in DAA scores — a monotonically increasing counter tied to Kaspa's difficulty adjustment, not wall-clock time. This makes time locks immune to timestamp manipulation.

Three security properties make this safe for marketplace use:

1. Single-input invariant. Every path begins with require(tx.inputs.length == 1), blocking a multi-UTXO siphon attack where two outputs at the same P2SH address get merged and excess value leaks into fees. 2. Fee griefing cap. A feeBudget parameter (on-chain maximum 0.1 KAS) prevents anyone from burning the escrow's value in an inflated network fee on a keyless path. 3. Conservation on arbitrate paths. The arbiter's split explicitly checks out0 + out1 >= in - feeBudget, so value can't silently disappear.

The full contract analysis lives in our Escrow Spending Paths and Covenant Security deep dives.

Anatomy of a Listing: Draft → Reserved → Funded → Closed

The marketplace doesn't invent a new contract. It adds a storefront layer — a lifecycle manager — on top of the existing escrow machinery.

1. Seller Publishes

The seller fills out a form: category (goods, digital, OTC, services), price (minimum 50 KAS, no upper cap), dispute window preset, and up to three photos. Under the hood, create_listing does two things atomically:

• Creates a draft escrow deal via the same Deals::create_deal function used for standalone escrow transactions.
• Generates a single-use join code tied to that draft.

An AI moderation pass flags policy violations before the listing goes live on the storefront. The storefront itself is server-side rendered with JSON-LD and Open Graph metadata for search visibility.

2. Buyer Joins

When a buyer clicks "Buy via Escrow," the marketplace hands them the join code. This triggers the standard escrow join flow: the buyer's public key is added to the deal parameters, the server computes the P2SH escrow address from both keys plus the arbiter's, and the buyer sees a funding address and exact amount.

The listing is now reserved — hidden from the storefront so no second buyer can double-join. The reservation carries a one-hour TTL. If the buyer doesn't fund within that window, the deal expires and the listing automatically republishes with a fresh join code.

3. Fund, Deliver, Close

Once the buyer sends KAS to the escrow address and the watcher confirms the UTXO, the deal becomes funded:

• The deal chat activates — end-to-end encrypted messages anchored in the BlockDAG via the Kasia protocol. Each message is a ciph_msg:… payload whose transaction hash serves as a tamper-proof timestamp.
• The seller delivers the goods or service. For physical items, shipping details go through the chat. For digital items (see below), the deliverable itself is transferred here.
• The buyer inspects and either releases payment (signs the release path) or disputes (signs dispute, activating the arbiter window).
• If neither party acts, the watcher broadcasts the keyless autoRelease after the dispute window — funds go to the seller, and the service fee goes to the fee address. No signature from anyone required, because the covenant already hardcoded both destinations.

When the UTXO is spent, the watcher detects it and either republishes the listing (for repeatable digital items) or closes it.

Pre-Deal Chat: Negotiate Without Burning the Join Code

The marketplace supports a listing chat that exists before any deal is created. A potential buyer asks about shipping, specs, or custom terms — all end-to-end encrypted.

The key architectural detail: listing chat keys are derived per listing × buyer-token, not per deal_id. This matters because the join code is single-use. Burning it on a conversation that doesn't lead to a purchase would force the seller to create a fresh draft. Listing chat lets buyers negotiate freely without consuming the escrow flow. Only when a buyer decides to purchase do they move to the deal chat tied to the actual funded covenant.

Digital Items: Electronic Delivery on the BlockDAG

A significant share of P2P trades are digital: software licenses, API keys, access tokens, gift cards. The marketplace maps these to service listings with template_id=digital-goods, which changes several defaults:

• Repeatable by default. The listing republishes after each completed deal, since the seller can deliver the same product type again.
• 48-hour dispute window — shorter than physical goods, since delivery is instant.
• No geography, carrier, or tracking fields. Delivery happens entirely through the E2E deal chat.
• The seller attaches the deliverable as an encrypted media message. Files are encrypted per-attachment with a unique key; a SHA-256 hash is anchored in the BlockDAG so the buyer can verify integrity before releasing payment.

The Watcher: Off-Chain State Machine Driving On-Chain Contracts

A single background process — the watcher — polls the Kaspa node every 10 seconds and manages both Safe vaults and escrow deals, including marketplace listings. For listings specifically, it handles:

• Draft expiration for listings that never get joined.
• Reservation timeout: if a joined deal isn't funded in 3600 seconds, the deal expires and the listing republishes.
• Auto-release: after the dispute window, the watcher broadcasts the keyless autoRelease transaction.
• Timeout: after the arbiter deadline, the watcher broadcasts the keyless timeout transaction.
• Republishing: when a deal closes on a repeatable listing, the watcher creates a fresh draft and join code.
• Alerts: notifications at 50% and 90% of the dispute window, and ~20% before the arbiter deadline, through Telegram, email, and web push.

The watcher never holds keys or funds. It broadcasts only keyless paths — transactions that the covenant permits *anyone* to submit, because the destination is already hardcoded in the on-chain script. This is the fundamental safety property: even if the watcher is compromised, it can only accelerate the timeline, not redirect funds.

Fee Structure

Service fees are split into two tiers, enforced by the covenant's feeSpk output:

The feeBudget — maximum network fee the covenant permits on keyless paths — is bounded between 0.01 and 0.1 KAS in production. This prevents a griefing attack where someone broadcasts a keyless path with an absurdly high fee, burning the escrow's value as miner reward.

Trade-offs and Honest Boundaries

Advisory cross-chain verification, not binding. For OTC deals involving other chains (USDT on Tron, BTC, etc.), the server can auto-verify a claimed transaction ID against public blockchain explorers — up to 17 network/method combinations. But this is an *advisory signal*: a green badge saying "this txid looks valid." The buyer still releases payment manually. The on-chain covenant has no awareness of other blockchains.

Fiat trades live entirely in chat. There is no contract-level integration with bank transfers or payment processors. Fiat payment details and proof of transfer happen in the E2E chat. The covenant only knows that KAS was escrowed.

No on-chain listing metadata. The listing itself — title, description, price, photos — lives in the server's database, not on the BlockDAG. The covenant stores only escrow parameters (keys, windows, fees). If the server disappeared, listing content would be lost, but escrow funds would remain safely spendable via the covenant's keyless paths and offline recovery tools like vaultctl.

AI moderation is a filter, not a guarantee. The marketplace runs an AI moderation pass on new listings to catch obvious policy violations. It reduces spam and fraud but doesn't replace buyer diligence. The E2E encrypted chat means the server cannot moderate deal conversations — that's by design, for privacy.

Minimum 50 KAS per listing. Below that threshold, dispute-resolution fees (minimum 5 KAS) eat more than 10% of the deal value, making the economics impractical.

Single-process architecture. The marketplace shares the same Rust server process, SQLite database, and watcher loop as Kaspa Safe and standalone Escrow. This simplifies operations but means a single restart affects all products. The on-chain funds are never at risk — covenants persist independently of any server, and both contracts include keyless paths that survive total service failure.