How to Buy and Sell With KAS on Kaspa Marketplace

To buy and sell with KAS on Kaspa Marketplace, you don’t send money to a platform. You browse live listings, start an encrypted chat with the seller, and click “Buy.” Behind the scenes, the Marketplace creates a real escrow deal on the Kaspa blockchain using the same escrow.sil covenant that powers all Kaspa Escrow transactions. You fund the covenant address directly from your own wallet. The seller sees the funded escrow, delivers the goods or service, and you release the funds — or open a dispute if something goes wrong. The marketplace itself never touches your KAS.

This guide walks through the full technical journey: from discovering a listing to final settlement, including the scam-prevention checks baked into the system.

The Problem: Trustless P2P Commerce

Traditional peer-to-peer marketplaces face a fundamental tension. Either you trust a centralized platform to hold funds (and hope it doesn’t get hacked, go rogue, or disappear), or you rely on honor-system arrangements that offer no recourse if one party cheats.

Kaspa Marketplace solves this by making every listing a thin wrapper around an on-chain escrow contract. The contract is a Kaspa covenant — a script embedded in the UTXO that enforces release/refund/dispute rules without any platform key. The marketplace provides the *discovery layer* (listings, search, photos, chat), but the *payment layer* is pure blockchain logic.

How Buying and Selling Works, Step by Step

1. Browse or Create a Listing

The Marketplace vitrine shows all published listings. You can filter by category (goods, digital, services), price range (in sompi — 1 KAS = 100,000,000 sompi), and full-text search powered by SQLite FTS5 with BM25 ranking. Search handles both Latin and Cyrillic word prefixes.

If you’re a seller, you create a listing through the Desk interface. The form asks for:

• Category (goods, digital, or services — OTC/crypto is intentionally excluded since July 2026)
• Price (minimum 50 KAS, no upper cap beyond sompi precision limits)
• Description and up to 3 photos
• Dispute window (24/48/72 hours, from a preset whitelist)
• Type (single-use or repeatable — repeatable listings stay live after a successful sale)

Photos are processed server-side: EXIF metadata is stripped (including GPS), images are re-encoded as JPEG (max 2400px long side), and stored content-addressed by SHA-256 hash. This prevents metadata leaks and polyglot payloads.

2. AI Moderation Queue

After submission, the listing enters a durable background moderation queue. The system uses an OpenAI-compatible endpoint (default model: mimo-v2.5-pro) with a system prompt that defines reject categories: spam, illegal items, phishing, malware, pirated content. For photo listings, a vision model analyzes the images.

The verdict is one of:

• approved → listing becomes published, visible on the vitrine
• rejected → listing stays hidden (auto-deleted after 24 hours if not manually reviewed)
• needs_review → alerts a human moderator via Telegram

If the AI call fails (timeout, transport error), the system retries with exponential backoff (default: 3 attempts, 15s/30s delays). After exhaustion, the listing remains unpublished and goes to human review. The system never silently publishes a listing that failed moderation.

3. Pre-Purchase Chat

Before buying, a potential buyer can start an encrypted chat with the seller directly from the listing page. This uses the same Kasia E2E protocol as deal chats: the server relays ciphertext only, and messages are anchored to on-chain transaction IDs for integrity.

Key differences from deal chats:

• Chat keys are derived from listing_id × hash(buyer_token), not from a deal ID
• This means asking a question doesn’t “spend” your one-time escrow join code
• Both parties pay for their own chat messages from their Desk wallet (no faucet funding)
• Limits: 500 messages per thread, 50 threads per listing, 10 new threads per hour

4. Checkout: Creating the Escrow Deal

When ready to buy, clicking “Buy via Escrow” triggers POST /api/safe/listings/:id/checkout with a random request_id. The server: 1. Creates a fresh escrow deal through Deals::create_deal — the same contract used by standalone Escrow 2. Links it to the listing in the listing_orders table (idempotent: same request_id returns same join code) 3. Returns a 12-character join_code

The join code lets you enter the deal panel at /deal.html?join=<code>. From there, you see the escrow address, dispute window, and can fund from your wallet.

For digital goods, the default settings are repeatable=true with a 48-hour dispute window.

5. Funding the Escrow

You send KAS to the covenant address displayed in the deal panel. The minimum is 50 KAS (matching MIN_DEAL_SOMPI). There’s no upper product cap — only precision limits from the sompi denomination.

Once the watcher detects the funding transaction (10-second polling loop), the deal transitions to funded. At this point:

• For goods: the listing status changes to reserved (single-use) or stays published (repeatable), and the watcher creates a fresh join code for the next buyer
• For digital goods: the listing stays published if repeatable
• A 1-hour timer starts: if the buyer joins but doesn’t fund within 60 minutes, the deal expires and the listing republishes

The watcher::run_escrow function handles all this lifecycle logic in a single 10-second loop, servicing both escrow deals and marketplace listings.

6. Delivery and Release

After funding, communication moves to the deal chat (separate from the pre-purchase listing chat). For digital goods, this is where the seller delivers: a file, license key, access link, or similar deliverable. The deal chat uses the same E2E encryption.

When satisfied, the buyer signs a release transaction. The funds move from the covenant to the seller’s address, minus escrow fees (min 0.5% or 1.2 KAS). The deal closes, and for single-use listings, the marketplace marks the listing closed and deletes photos.

7. Disputes: The Safety Net

If something goes wrong, either party can open a dispute within the preset window. The process:

1. Claim: Buyer or seller states their position (refund/release/split) 2. Reveal: Both parties must reveal their chat secret key (not their escrow key — different keys). This lets the system decrypt the chat transcript for evidence review 3. AI Mediation: The arbiter AI (mimo-v2.5-pro, temp 0) reviews the transcript, any attached media (photos verified against on-chain SHA-256 anchors, videos processed frame-by-frame), and issues a non-binding verdict 4. Acceptance Window: Parties have 24 hours to accept the verdict 5. Escalation: If rejected, a human arbiter can intervene via the admin panel

The dispute path uses the same escrow.sil covenant state machine: ACTIVE → DISPUTED → arbiter resolves.

Trade-offs and Honest Boundaries

No system is perfect. Here’s what you should know about the current state:

AI moderation is a filter, not a guarantee. It catches obvious policy violations but can miss novel scams. The needs_review path exists for edge cases, but moderation volume can create delays. Sellers should expect pending times.

Reputation is opt-in and unlinkable by default. Each listing generates fresh cryptographic keys. Without enrolling in the reputation system, a seller’s listings cannot be correlated — this is by design for privacy, but it means you can’t easily vet a seller’s history unless they choose to publish it.

Photos are limited to 3 per listing, 8 MB each, 25 GB total storage cap. Content-addressed storage means identical images across listings share storage, but orphan cleanup runs every 30 minutes.

Digital goods delivery is manual. There’s no automated license key delivery system. Sellers must deliver through the deal chat, and the platform doesn’t verify that the deliverable matches the description — that’s between buyer and seller (and the dispute system if things go wrong).

The dispute window is preset (24/48/72 hours) — you can’t choose arbitrary durations. For digital goods, 48 hours is the default.

OTC/crypto trading is intentionally excluded from the marketplace since July 2026. The marketplace is for goods and services paid in KAS, not for exchanging KAS for other cryptocurrencies. That’s the domain of the standalone Escrow service.

Fees are unavoidable. Escrow resolve fees start at max(0.5%, 1.2 KAS); dispute fees at max(2%, 5 KAS). These go to the same fee address as all escrow transactions.

Key management is on you. Your Desk profile encrypts keys locally. If you lose access and didn’t back up your .age key-file, funds in escrow may be unrecoverable (though the public dealctl CLI exists for this scenario).

The escrow contract itself has a known boundary: paths validate leading outputs and preserve principal within feeBudget precision, but don’t enforce exact output count. This is documented in the public errata and is being addressed in a future covenant version — not silently patched in the current live contract.

How Kaspa Forge Wires It Together

Under the hood, the Marketplace is a module layered on top of the escrow backend (kaspa-safe-server). The listings.rs module (~112KB, the server’s largest) handles CRUD, moderation, and SSR. It shares a SQLite database with escrow, with tables for listings, listing_orders (idempotent checkout tracking), listing_photo_uploads/refs (staging and durable photo ownership), listing_chats/listing_chat_msgs (encrypted pre-purchase threads), and listings_fts (full-text search index).

The HTTP API lives under /api/safe/ with routes merged from listings::routes() and listing_chat::routes(). Key endpoints:

POST   /api/safe/listings          # create listing (pending moderation)
GET    /api/safe/listings          # browse (category, q, sort, price range, limit≤100)
POST   /api/safe/listings/:id/checkout  # create escrow deal for this listing
POST   /api/safe/listings/chat/start    # begin pre-purchase encrypted thread

The listing lifecycle is driven by the same watcher::run_escrow function that handles all escrow deals. When a buyer funds an escrow, the watcher:

• Reserves single-use listings (status → reserved)
• Republishes repeatable listings with a fresh deal and join code
• Closes listings after deal completion (for single-use items, photos are deleted)

Photo storage uses content-addressing: photo_id = sha256(normalized_jpeg). Uploads are rate-limited (30 per 10 minutes, 10 creates per hour). The server re-encodes every upload to strip metadata, preventing EXIF leaks.

Moderation runs as a durable background worker with exponential backoff. Failed AI calls don’t block the listing — they retry silently and escalate to humans after exhaustion. The admin panel (market-admin.html and a Telegram Mini App) shares authentication with the escrow arbiter dashboard through the same admin_ok gate.

For Kaspa-specific context: the Marketplace leverages Kaspa’s fast block times for quick escrow funding confirmation, and the UTXO model ensures each escrow is a discrete, verifiable on-chain object. The GHOSTDAG protocol provides the consensus foundation — your escrow transaction is ordered and confirmed within the DAG structure, with the DAA score controlling the timing of difficulty adjustments.

Practical Tips for Buyers and Sellers

For buyers:

• Use the pre-purchase chat to verify details before committing
• Check if the seller has a reputation badge (opt-in, but useful when present)
• For digital goods, verify the deliverable in the deal chat before releasing funds
• Dispute within the window if something’s wrong — after it expires, only the arbiter path remains

For sellers:

• Write clear descriptions; the AI moderator reads them and your photos
• For digital goods, deliver promptly after funding to avoid disputes
• Consider enabling the reputation badge if you plan multiple sales — it helps buyers trust you
• Use the repeatable flag for items you can sell multiple times (software, services)

For both:

• Keep your Desk profile backed up (.age key-file)
• Understand that the escrow covenant is the source of truth — not the platform
• Remember: the Marketplace is a discovery layer, not a custodian. Your KAS lives on-chain.

The full Kaspa Escrow documentation covers the covenant mechanics, dispute flow, and recovery options in detail. For the open-source contract code and recovery tools, see the Kaspa Forge repository.