Crypto Rental Deposit on Kaspa: Covenant Collateral in Practice

A crypto rental deposit solves a specific trust problem: a landlord and a tenant each want assurance that the security deposit will actually be returned — not disappear into the landlord's spending account, a platform's omnibus wallet, or a smart contract that only one side controls. On Kaspa, the answer is an on-chain covenant — a script that locks KAS as rental collateral and only releases it through predefined paths. Kaspa Deposit, live on mainnet, implements this using the same audited escrow.sil contract that powers Kaspa Escrow, with the roles inverted so the default outcome returns funds to the depositor rather than the payee.

This article explains the mechanism from the contract up: what the covenant actually enforces, how the term and claim window work, and where a blockchain deposit agreement genuinely helps — and where a written lease is still irreplaceable.

The Problem: Custodial Deposits Are IOUs

Traditional security deposits — whether for an apartment, a contractor's performance bond, or rented equipment — share the same weakness: one party holds the money and the other trusts a promise. In fiat, the landlord's bank account is an IOU. In crypto, a platform's omnibus wallet is worse: it's a single point of failure with no enforced rules about when funds move.

Even "escrow" services in the Telegram ecosystem follow the same pattern. A human guarantor receives KAS into their own wallet and manually forwards it. The depositor has zero cryptographic assurance that the funds won't be spent before the term ends.

The Covenant: Same Script, Inverted Roles

Kaspa Deposit does not introduce a new contract. It reuses the same escrow.sil — the same compiled bytecode, the same ten spending paths, the same WASM v5 runtime — but with a single critical difference: the role mapping is flipped.

In a normal Kaspa Escrow deal:

In a Kaspa Deposit:

The depositor funds the covenant — just as the buyer funds an escrow. But because the depositor occupies the seller slot, the standard release path returns funds to them. The refund path sends funds to the holder. The keyless timeout — the emergency path that fires if the service itself disappears — also returns funds to the depositor.

This inversion is not a hack. The escrow.sil contract was designed with ten fixed spending paths that route to buyer, seller, and feeAddr. By choosing which public key maps to which slot, the same bytecode enforces opposite default behaviors. One contract, two products.

Deposit flow (simplified):

  Depositor ──funds──▶ [covenant UTXO]
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
       release          refund         timeout
     → depositor      → holder       → depositor
     (auto after       (holder's      (service
      term+claim       claim wins)     death)
      window)

Step by Step: How a Deposit Deal Works

1. Creation. The depositor opens the Deposit page, sets the amount (minimum 50 KAS), the term length, and the claim window. The server (deposit_api.rs) computes the covenant address from the depositor's public key, the holder's public key (entered or invited), and the service parameters. An invite link is generated. Creating a deposit is free.

2. Join. The holder opens the invite link, reviews the terms, and joins. Each side's browser generates its own private key — stored only in the encrypted Desk profile, never transmitted. The holder has 72 hours to join before the draft expires.

3. Funding. The depositor sends KAS to a funding address (their own address, key in their recovery list), then clicks "Lock into deposit." The browser assembles the on-chain covenant transaction. A plain transfer to the covenant address without the assembly step does not create the contract — the two-step process exists because the covenant requires a specific output structure.

4. The term runs. During the rental period, the funds sit in the covenant UTXO. Neither party can move them unilaterally. Both sides have access to an end-to-end encrypted deal chat (Kasia protocol — every message is an on-chain transaction, so the conversation is tamper-evident and timestamped in the BlockDAG).

5. Term ends, claim window opens. This is the key design element. The term is split into two phases:

• Free term: the rental period itself. No claims can be filed.
• Claim window: a preset period after the term (chosen at creation time). The holder must open a claim before this window closes.

6a. No claim → auto-return. If the claim window expires without the holder filing a claim, the funds auto-release to the depositor. This is the expected path for a clean rental: the tenant returns the apartment, the landlord inspects, the window passes, the deposit returns.

6b. Holder files a claim. If the holder believes they have grounds to keep part or all of the deposit (damages, unpaid rent, incomplete work), they open a claim before the window closes. The deal enters dispute state — funds freeze in the covenant.

7. Dispute resolution. The dispute flow is identical to Kaspa Escrow:

• Both sides submit evidence through the deal chat (photos, documents, messages).
• An AI mediator reconstructs the chat thread from the revealed key, collects evidence, and produces a non-binding verdict.
• A human arbitrator makes the final decision: all to depositor, all to holder, or an N% split.
• If the arbitrator misses their deadline, auto-escalation kicks in.

8. Emergency timeout. If the service itself goes offline — the server disappears, the domain lapses — a keyless timeout path in the covenant returns funds to the depositor. Neither party needs to sign anything. The funds cannot get stuck.

How Kaspa Forge Uses It

Kaspa Deposit is live on mainnet. The product surfaces are:

• Landing page: /deposit-index.html — explains the mechanism and links to the app.
• App: Desk → Deposits tab — create, join, fund, claim, and manage active deposits.
• Recovery: the public dealctl CLI (published in the Kaspa Forge repository) supports deposit deals with the same extract/verify/fund/release/refund/dispute commands as Escrow. If the website is down, dealctl against any Kaspa v2+ node handles everything.

The server-side boundary is deposit_api.rs, which handles creation and joining. After that, a deposit deal flows through the same deals.rs registry, the same encrypted chat, the same dispute and arbiter pipeline, and the same watcher cycle that monitors Escrow deals. The watcher handles draft expiration, auto-release after the claim window, timeout after the arbitrator deadline, and pre-alerts at 50% and 90% of each window.

Where Covenant Collateral Helps — and Where It Doesn't

A blockchain deposit agreement is strongest where the dispute is about whether a condition was met, not about what the condition means.

Good fit:

• Apartment rental: landlord and tenant agree in a written lease that the deposit returns if the apartment passes inspection. The covenant holds the funds; the claim window gives the landlord time to inspect; the dispute flow handles disagreements about damage.
• Contractor performance bond: client locks a deposit that the contractor posts as collateral for timely completion. If the contractor finishes on time and the client doesn't claim, the deposit auto-returns.
• Equipment rental: owner holds a deposit against damage. The term matches the rental period; the claim window matches the return-and-inspect window.

What still needs a written agreement:

• The covenant cannot verify that an apartment was left clean, that a contractor met a specification, or that equipment was returned undamaged. It can only route funds based on whether a claim was filed and what the arbitrator decides.
• The covenant cannot enforce lease terms, late fees, or partial deductions. Those rules belong in a written contract. The blockchain enforces who gets the money; the written contract defines what triggers a valid claim.
• The covenant cannot identify the parties. It sees public keys, not names or ID documents. A written agreement links keys to real-world identities.

In practice, a Kaspa Deposit works best as the enforcement layer underneath a written agreement — the part that makes the Kaspa rental collateral actually non-custodial and removes the "landlord's bank account" problem. The lease defines the rules; the covenant makes them enforceable without trusting either party's wallet.

Trade-offs and Honest Limitations

What the covenant guarantees: funds cannot be stolen by the operator, the arbitrator, or either party acting alone. The ten spending paths in escrow.sil are mathematically constrained — no path sends funds to any address other than the depositor, the holder, or the service fee. This is a property of the compiled script, verified in the Kaspa VM (25 self-tests), not a policy statement.

What the covenant does not guarantee:

• Fairness of the verdict. The AI mediator's verdict is non-binding. The human arbitrator's verdict is final but human — it depends on the quality of evidence submitted. Keep all communication in the deal chat (on-chain, E2E-encrypted, tamper-evident) rather than in side channels.
• Off-chain truth. The contract cannot see the physical world. A KAS security deposit for an apartment that was genuinely damaged will still require the holder to prove it through evidence, and the arbitrator to evaluate that evidence.
• External audit. The contract has been through internal adversarial testing (52/52 VM checks plus testnet runs) and four rounds of independent review of the recovery kit. An external security audit is still ahead. Verify before you lock significant amounts.
• Minimum amount. Deposits below 50 KAS are not supported — the fee structure (minimum 1.2 KAS on release, minimum 5 KAS on dispute) makes smaller deposits impractical.
• Mutual close carries a fee. If both sides agree to close a deposit amicably (mutual signature), the release fee (0.5%, min 1.2 KAS) still applies — this is enforced by the contract itself to prevent fee bypass.

The recovery guarantee: if the service disappears, the keyless timeout returns funds to the depositor. The public dealctl CLI can execute this recovery against any Kaspa node, completely independent of Kaspa Forge infrastructure. This is not a promise — it's a published, tested, open-source tool.