Kaspa Collateral Contract — Claims, Refunds & Timeouts

When you lock KAS into a Kaspa Deposit — for rent, equipment, freelance collateral, or any temporary hold — the money leaves your wallet and lands inside an on-chain covenant: a small program written in Kaspa's Toccata scripting language. The covenant decides who gets the funds and under what conditions. No human can override it. No server can intercept it.

This article maps every outcome the contract allows: the normal return by agreement, the automatic return when no one files a claim, the dispute path, the arbitrator's verdict, and the emergency timeout that fires if the service itself disappears. It also covers what evidence to preserve and where the real limits are.

The covenant at a glance

A Kaspa Deposit runs on the same ten-path contract (escrow.sil) that powers Kaspa Escrow. The difference is a single role inversion at creation time: the depositor (the person posting collateral) maps to the contract's seller slot; the holder (the landlord, client, or counterparty) maps to the buyer slot. This means every standard path — release, refund, dispute, timeout — does the right thing for a collateral scenario without changing a line of the contract.

// Conceptual — state stored inside the escrow.sil covenant
let mode: u8 = 0;   // 0 = ACTIVE, 1 = DISPUTED

// Constructor parameters baked into the covenant address:
// depositor, holder, arbiter   — public keys
// disputeWindow, arbiterDeadline — in DAA score increments
// timeoutTo  (0 = holder, 1 = depositor)
// feeSpk, feeResolve, feeDispute, feeBudget, initMode

The address itself encodes all eleven parameters. Once funded, the UTXO can only be spent through one of ten specific paths — each a different combination of signatures, state checks, and timing conditions. You can verify the compiled contract and its Toccata opcodes in the published source at github.com/Kaspaforge/kaspaforge.

The five outcomes

Every funded Kaspa Deposit resolves through exactly one of these paths. There is no path that sends funds to the platform, the arbiter, or any third party — the script physically rejects any transaction that tries.

1. Normal return (by agreement)

The two simplest paths exist so the parties can settle without involving anyone else.

release(depositorSig) — the depositor signs. Funds return to the depositor minus the resolve fee (0.5 %, minimum 1.2 KAS). Because the depositor is mapped to the contract's seller slot, a standard release directs funds to them. This is the "everything went fine, return my collateral" path.

refund(holderSig) — the holder signs. Funds transfer to the holder, minus the same resolve fee. In a deposit context, this means the holder is voluntarily waiving any claim. It is also the path a holder uses *during* a dispute to settle amicably.

Both paths work in any mode — ACTIVE or DISPUTED — so either party can close the deal at any time. No timer needs to expire.

If both sides agree on a custom split (say the holder keeps 30 % for damages), they co-sign a mutual transaction. The contract mandates that the first output is the service fee — an intentional design choice the team calls *anti-bypass K1*, preventing parties from dodging fees through creative "agreements." Remaining outputs are free-form but each must exceed 1 KAS (the dust guard from KIP-9).

2. Auto-return (no claim filed)

This is the most common outcome for well-functioning deposits and the path that protects the depositor from a holder who simply disappears.

When the depositor creates a Deposit, they configure a window that covers the service term and the subsequent claim window. The holder can file a claim at any point during this period. If the window expires with no claim filed, the contract's autoRelease path fires:

// Conceptual — escrow.sil
// ACTIVE mode, no signature required
if mode == ACTIVE && age >= disputeWindow {
    // send entire balance to seller  (= depositor)
    // minus feeResolve
}

No signature is needed. A background watcher service broadcasts this transaction automatically. The depositor gets their KAS back minus the resolve fee. The deal is closed.

3. Filing a claim (dispute)

If the holder believes they have a legitimate claim — damaged equipment, broken terms, unpaid rent — they execute the dispute(holderSig) path during the open window. On-chain, this transitions the covenant from ACTIVE to DISPUTED:

• The UTXO is recreated with mode = 1.
• The age counter resets to zero.
• The arbiterDeadline timer starts ticking.

Only the holder (= contract buyer) can initiate a dispute. The depositor cannot dispute their own deposit — they can only release, refund, or wait for auto-return.

Once DISPUTED, the auto-return path is locked out. The only remaining paths require either the arbiter's signature or the arbiter deadline to expire.

4. Arbitration verdict

In DISPUTED mode, three paths become available — all requiring the arbiter's signature:

The arbiter cannot send funds to themselves or to any third party. The covenant checks every output against the allowed set and rejects anything else. This is enforced at the consensus level — it is a mathematical property of the script, not a platform policy.

Evidence for the dispute flows through the deal's encrypted chat — an on-chain Kasia thread where every message is an end-to-end-encrypted transaction. The server only ever sees ciphertext. Timestamps are anchored to the BlockDAG and cannot be forged.

5. Emergency timeout (arbiter fails)

What if the arbiter never responds — the service goes offline, the operator disappears? The contract has a hard fallback that requires no signatures at all:

// Conceptual — escrow.sil
// DISPUTED mode, no signature required
if mode == DISPUTED && timeoutTo == 1 && age >= arbiterDeadline {
    // send entire balance to seller  (= depositor)
    // NO service fee — network fee only
}

For Kaspa Deposit, timeoutTo is set to 1 (seller = depositor). If the arbiter deadline passes without a verdict, funds automatically return to the depositor with no service fee — only the network fee is deducted. The deal can never get stuck indefinitely, regardless of what happens to any server or service.

The same mechanism powers Kaspa Escrow, where timeoutTo defaults to the buyer. The principle is identical: a hard deadline after which the contract resolves itself without any human involvement.

How Kaspa Forge wires these paths into Deposit

The product does not introduce a new contract. The server module deposit_api.rs accepts Deposit-specific creation and join routes — setting the depositor as seller, the holder as buyer, and timeoutTo = 1 — then hands the record off to the shared deal lifecycle that also serves Escrow: deals.rs (registry), chat_api.rs (encrypted thread), dispute_api.rs (claim/reveal/escalate), arbiter.rs (AI mediation), and watcher.rs (10-second polling loop that triggers auto-release, timeout, expiry alerts, and post-verdict escalation).

The window presets are the same six options available in Escrow: 24 / 48 / 72 / 96 / 120 / 168 hours, each paired with a longer arbiter deadline. Minimum deal size is 50 KAS; there is no upper cap. Fees are enforced by the contract and shown before confirmation.

All keys — the depositor's deal key, the holder's deal key, the funding key — are generated client-side inside Desk and never leave the device. The server stores no private keys and cannot sign on anyone's behalf.

Evidence to preserve

The covenant decides who gets the money. The *arbiter* decides based on evidence. For a deposit dispute, what matters:

• The deal's encrypted chat — this is the primary evidence channel. Keep all communication inside the deal thread. On-chain timestamps cannot be backdated.
• Photographs or video of the item or property at handover and return, with visible timestamps.
• Receipts, tracking numbers, contracts — any off-chain document. Upload through the deal chat's media attachment (up to 60 MB per file).
• Screenshots of terms as they appeared when the deal was joined.

The AI mediator's forensic module checks file integrity (SHA-256 against on-chain anchors, magic bytes, EXIF), runs images through a vision model, and extracts metadata from video and PDF. But it can only analyze what is submitted. If you provide no evidence, the arbiter has nothing to work with.

Fee summary and timing

The feeBudget constructor parameter (visible before funding) caps the on-chain network-fee component between 0.01 and 0.1 KAS. The service fee is mandatory in every path except timeout — enforced at the script level, not by the server.

Honest limits and current boundaries

The contract guarantees fund safety, not outcome fairness. The covenant prevents theft — the arbiter cannot redirect funds to themselves. But whether the verdict is *fair* depends on the evidence and the arbiter's judgment. This is an inherent trade-off of any system bridging on-chain settlement with off-chain reality.

Only the holder can file a claim. The depositor can release, refund, or wait for auto-return — but cannot initiate a dispute against their own deposit. If the depositor believes the holder is abusing the window, their recourse is to refuse release and let the timer run.

The claim window is fixed at creation. Six presets only (24 h to 168 h). Custom values are not supported — this prevents a malicious party from setting a micro-window that denies the other side any real chance to act.

Minimum 50 KAS, no upper cap. Below 50 KAS the dispute fee consumes too large a share of the collateral.

Known errata (Escrow v1, reviewed 2026-07-25): the current contract validates mandatory leading outputs and preserves principal to within feeBudget, but does not enforce an exact output count. A trailing output can absorb bounded budget slack (0.01–0.1 KAS in the supported configuration). The official dealctl recovery CLI produces the canonical transaction form and verifies it locally. An exact-output fix requires a new contract version and will not be applied silently — it will be published as a disclosure with compiler fingerprints.

External audit is ahead. The contract has passed adversarial testing (52/52 scenarios in the Kaspa VM, plus simnet end-to-end runs), four rounds of internal security review including an air-gap trust-boundary analysis, and the recovery tooling has been independently verified. But the formal external audit report has not yet been published. Verify the published source before you send.

Single-input invariant. All ten paths enforce require(tx.inputs.length == 1), closing a class of attacks that would combine the escrow UTXO with other inputs. Confirmed in audit and the public test suite.

Recovery works offline. The published dealctl CLI can extract, verify, build, sign, and submit every covenant path against any Kaspa v2+ node directly — no hosted endpoints, no account, no dependency on the Kaspa Forge website. If you hold your deal key, you can always move your funds.