How Kasia E2E Chat Anchors Encrypted Messages on the Kaspa BlockDAG

P2P escrow on a blockchain solves the "who goes first" problem — funds sit in a covenant neither party controls unilaterally. But there's a second problem hiding behind it: how do buyer and seller communicate privately during the deal, and how do you make that communication verifiable if things go wrong?

Telegram group chats leak metadata. Email is centralized and mutable. Plain web chat has no proof-of-existence — a message can be edited or backdated. Kaspa Escrow's answer is Kasia, an end-to-end encrypted chat protocol where each message commitment is anchored to the Kaspa BlockDAG.

This isn't a separate chain or a sidechain. It's a layer on top of ordinary Kaspa transactions, leveraging the DAG's high throughput to stamp encrypted message proofs on-chain at minimal cost.

The Key Separation Decision

The first design choice is the most consequential: chat keys are not escrow keys.

Every escrow deal involves cryptographic identities that control the covenant — keys that authorize release, refund, dispute, and mutual spending paths. These are high-value credentials; losing or exposing them means losing control of the contract funds.

Chat keys are generated separately for each deal. Their only job is to encrypt and authenticate messages between the parties. This separation creates two important properties:

• Revealing a chat key during a dispute doesn't compromise funds. When a dispute enters arbitration, each party reveals their chat key so the conversation can be reviewed (more on this below). If these were the same keys that controlled the escrow UTXO, the mediator or any interceptor could attempt to authorize transactions.
• Chat works even if a party has zero KAS. A faucet service funds each chat key with a small amount of dust (default 0.5 KAS) so the anchoring transaction can be broadcast. The party never needs a funded wallet to participate in the conversation.

ECIES: How Messages Are Encrypted

The encryption uses ECIES (Elliptic Curve Integrated Encryption Scheme) built on the k256 curve — the same curve family Kaspa uses for transaction signatures, applied here to messaging.

When a party sends a message, the browser:

1. Generates an ephemeral ECDH key pair on k256. 2. Derives a shared secret via ECDH between the ephemeral key and the recipient's public chat key. 3. Feeds the shared secret into ChaCha20-Poly1305, a symmetric AEAD cipher providing both encryption and authentication. 4. Packages the ciphertext with the ephemeral public key and nonce into an encrypted payload.

This happens entirely in the browser's WASM core (the chat_cipher.rs and chat_payload.rs modules compiled from kaspa-safe-core). The relay server receives opaque ciphertext — it never sees plaintext, ephemeral keys, or the shared secret.

For each message, the sender's browser produces two ciphertexts: one encrypted for the recipient and one for the sender (a self-copy). Both go to the relay. Only one anchor transaction is broadcast, but each party can independently decrypt their copy of the conversation.

BlockDAG Anchoring: Proof Without Disclosure

Here's where Kaspa's throughput makes a practical difference compared to anchoring on a slow chain.

For each relayed message, a commitment transaction is broadcast to the BlockDAG carrying a small payload tagged ciph_msg:…. The transaction hash (txid) becomes a permanent, timestamped anchor that proves:

• Existence — the message was composed and broadcast at a specific DAA score (Kaspa's monotonic counter, comparable to block height but DAG-aware).
• Order — relative DAA scores establish which message came first, critical for dispute timelines.
• Integrity — if the on-chain anchor matches the message hash, the content hasn't been tampered with since delivery.

What the anchor does *not* reveal: message content, sender or recipient identities beyond pseudonymous addresses, or deal metadata.

At 10 blocks per second, anchoring is fast. A ciph_msg transaction confirms in well under a second, and the fee is negligible. The relay delivers ciphertext immediately so the chat feels instant; the on-chain anchor provides retroactive proof of exactly when the message existed.

Media Handling: Files Behind the Same Wall

Deals often involve files — photos of goods, shipping receipts, payment screenshots. Kasia handles these with a two-layer scheme:

1. Per-file encryption: each file gets a unique symmetric key in the browser, distinct from the message encryption key. The encrypted blob is uploaded to the server. 2. Descriptor in E2E message: a structured payload containing the file's decryption key, original filename, size, and SHA-256 hash is embedded inside the normal ECIES-encrypted chat message. 3. On-chain hash anchor: the SHA-256 of the encrypted file is committed to the BlockDAG through the message's anchor transaction.

On download, the recipient's browser decrypts using the key from the E2E message and verifies the hash against the on-chain commitment. The server stores encrypted blobs it cannot read. Even a compromised server would need the recipient's private chat key to extract the file descriptor — and that key lives only in the browser.

File size is capped (60 MB, configurable), and upload paths enforce traversal guards. Temporary processing during dispute forensics uses RAM-only storage (/dev/shm) that doesn't survive a reboot.

Structured Messages: Typed Payloads for Deal Logic

Kasia supports typed message formats beyond freeform text, each serving a role in the deal lifecycle:

These structured types let the AI mediator and human arbiter parse the deal narrative mechanically. A payto followed by a pay with a verified txid tells a clearer story than "I sent it, trust me" in plaintext. For supported crypto networks, the server can independently verify the on-chain transaction ID — an advisory signal that doesn't replace the buyer's manual release decision but helps both parties and the mediator.

For digital goods (software licenses, access links), delivery happens through the same E2E channel after the deal is funded. There's no shipping carrier to verify; the chat record itself constitutes the delivery evidence.

Dispute Reveal: The Controlled Key Handoff

When a deal enters dispute, the chat history becomes evidence — but the mediator can't read ECIES-encrypted messages without the keys. The solution is a controlled reveal:

1. Each party submits their private chat key to the dispute endpoint. The server verifies it matches the party's registered chat public key — you can't submit a fabricated key. 2. The server uses revealed keys to decrypt the full message thread, assembling a transcript. 3. The transcript feeds into the AI mediator's judgment alongside media forensic analysis. 4. Revealed keys are held in memory only during dispute processing and are not persisted.

The critical invariant holds: what's revealed is the chat key, not the escrow key. The mediator can read the conversation but cannot authorize any movement of funds. The covenant's spending paths remain gated by the original escrow credentials — never disclosed to the server or mediator. For the full dispute flow, see how Kaspa Escrow disputes work.

How Kaspa Forge Uses Kasia in Production

The protocol powers two surfaces in the Kaspa Forge platform:

Escrow deals — every Kaspa Escrow deal spins up a fresh chat thread with derived chat keys. Buyer and seller communicate through the deal panel; messages are anchored per-transaction. The full dispute chain — AI mediation through human arbitration — relies on the transcript reconstructed from revealed keys and on-chain anchors.

Marketplace pre-deal chat — before committing to a deal, a potential buyer can message a seller on a listing. This uses the same Kasia protocol but with keys derived per listing × buyer-token (not per deal), so the one-time join code isn't consumed just for a question. Once the buyer joins, the conversation migrates to the deal's own thread.

On the implementation side, the protocol lives in three Rust modules compiled into the WASM core (kaspa-safe-core): chat_cipher.rs for ECIES, chat_payload.rs for message framing, and media.rs for file encryption and hash verification. Browser-facing bindings (chat_bindings.rs) expose these to the JavaScript layer on deal pages. The server-side relay (chat_api.rs in the single backend process at :8795) handles ciphertext storage, anchor broadcast coordination, and the dispute-phase key reveal flow.

Trade-offs and Current Boundaries

On-chain anchoring isn't free — it's just cheap. Every message produces a Kaspa transaction. At current fee levels the cost is negligible, but the chat faucet explicitly seeds each party's key with dust to cover it. In very high-volume negotiations, per-message anchoring adds up — though Kaspa's per-UTXO fee model and small ciph_msg outputs keep it minimal.

The server is a relay, not a vault — but it is a relay. The server cannot read content, but it *could* theoretically withhold or delay ciphertext delivery. On-chain anchors mitigate this: a message in the chat window without a corresponding BlockDAG anchor is suspect. And if the server goes down entirely, the anchors preserve a timeline of when messages existed, even if the ciphertext blobs are lost.

Key loss means chat loss. If a party loses their Desk profile and .age backup before a dispute resolves, the chat history is unrecoverable from their side. The escrow funds are still governed by the covenant, but the evidentiary record is gone. Chat keys live in the same encrypted profile as everything else — one backup covers all products.

No forward secrecy. The current ECIES scheme uses a single key pair per deal. If a chat private key were compromised, all messages encrypted to that key become readable. A Signal-style Double Ratchet would add per-message key rotation but also significant state management. For the deal-chat use case — short-lived, bounded by the deal lifecycle — the single-key model is a deliberate simplicity trade-off.

Reveal is all-or-nothing. Revealing the chat key gives the mediator access to the entire thread; there's no selective disclosure. In practice disputes need full context, but parties should treat the chat as potentially readable by a third party once a dispute is filed.

---

The Kasia protocol illustrates a pattern becoming viable on high-throughput PoW chains: using the blockchain not as a message store, but as an immutable notary. Messages live off-chain in encrypted form; the BlockDAG provides timestamps and integrity proofs. Kaspa's 10-block-per-second cadence makes this practical at negligible cost — a message commitment confirms in the time it takes to type the next line.