Kaspa Forge: non-custodial services for KAS

Kaspa Forge is not an exchange, a bank or another wallet with a polished balance screen. It is a suite of non-custodial services for KAS where users sign on their own devices and the rules of storage, settlement or payout are encoded in Kaspa transactions and covenants. The ecosystem includes Kaspa Safe, Kaspa Escrow, Marketplace, Deposit, Arena, Boards, and the shared encrypted Desk profile.

This is a practical platform guide. It explains which product fits which job, where the trust boundaries sit, and why “non-custodial” describes a concrete system design here rather than a marketing adjective.

Contents

• What connects the Kaspa Forge services
• Which product to choose
• Safe, Escrow, Market and Deposit
• Arena and Boards
• How the non-custodial model works
• How to get started

What connects the Kaspa Forge services

Kaspa is a live proof-of-work BlockDAG running at 10 blocks per second, as the official Kaspa overview explains. Rather than discarding parallel blocks as orphans, the protocol orders them. For Kaspa Forge users, that creates a fast rhythm for on-chain activity: funding, state transitions and public posts do not feel like an occasional batch process.

The Toccata upgrade added further first-layer programmability. Active proposals KIP-17 and KIP-20 describe enhanced scripting and covenant identifiers. Kaspa Forge uses that foundation for vaults, escrow and other state machines that must continue from one UTXO to the next through a restricted set of paths.

Technology only matters when it becomes an understandable user guarantee. Kaspa Forge therefore follows four shared principles.

• Keys are created locally. Signing happens in the browser through a Rust/WASM core. A private key is not sent to the server “for the duration of the operation.”
• Money does not sit on a platform balance. In financial products, KAS remains in the user's wallet or in an on-chain state with constrained spending paths.
• The server does not pretend to be the blockchain. It indexes, displays, relays and notifies. The Kaspa network decides whether a financial transition is valid.
• Trust boundaries are published. A beta is called a beta, a third-party service is identified as external, and automation is not marketed as a consensus guarantee.

That final point matters. Non-custodial does not mean risk-free. It means the operator does not receive a universal key to your money. Software bugs, lost backups, phishing, poorly chosen terms and beta risk still exist. A sound product does not hide those risks; it shows where they live.

Which Kaspa Forge product should you choose?

The services solve different problems but share one entry point: Desk. This is not a server account. It is an encrypted wallet profile on your device that stores a master seed, derived keys for separate tools, local history and recovery data. You export one encrypted file and keep its password separately.

There is an important operational consequence: backup is part of the product, not an optional advanced feature. Kaspa Forge cannot email you a private key or reset the password through support because the platform does not have that key. Before the first meaningful operation, export the Desk file, verify the password and store a copy away from the primary device.

The financial tools: Safe, Escrow, Market and Deposit

Kaspa Safe: when protecting the key is not enough

A standard wallet protects a secret, but once a valid transaction is signed, it leaves without a reconsideration window. Kaspa Safe changes the withdrawal process itself. The hot key can initiate a withdrawal and pin the destination, while the funds remain in a waiting state for a period selected by the owner. During that window, a separate alarm key can return the funds to the vault.

The delay is useful beyond hacks. It creates a second chance after a bad address, phishing, coercion or compromise of a working device. For a business, the same mechanism makes a treasury withdrawal visible before it settles. A family can optionally configure an inheritance path with periodic check-ins, or leave inheritance disabled entirely.

The essential discipline is straightforward: do not store the hot and alarm keys together. If an attacker gets both, the cancellation window loses its advantage. Safe does not replace operational security; it gives operational security an on-chain foundation.

Kaspa Escrow: a deal without a middleman's wallet

A traditional P2P guarantor concentrates trust in one person: that person holds the money, reads the dispute and decides where to send it. Kaspa Escrow separates those powers. Funds lock into an on-chain covenant, the parties' chat becomes the case record, and payouts are constrained in advance to the buyer, seller, a split, and a visible service fee.

If the deal goes well, the buyer signs the seller payout. If the seller backs out, a refund path is available. If a dispute starts, an AI mediator can propose a resolution but cannot move funds. A proposal that the parties do not accept escalates to a human arbiter, while even that signature cannot invent an arbitrary destination. An emergency timeout exists if the arbiter misses the contract deadline.

Normal settlement costs 0.5% with a 1.2 KAS minimum; human arbitration costs 2% with a 5 KAS minimum. Exact terms are shown before signing. Escrow is an open beta, so begin within the published limits and with an amount that matches your own tolerance for software risk.

Kaspa Marketplace: a storefront where protection is not optional

Kaspa Marketplace connects listings to Escrow. The Buy button does not send KAS to the seller. It opens a deal with the listing's exact terms, after which the buyer funds an on-chain escrow. A seller therefore cannot ask to “disable protection for a discount,” and the platform cannot silently redirect payment.

The storefront supports physical goods, digital items and services. A listing includes its KAS price, description, up to three images and the dispute window. Communication and digital delivery run through the encrypted deal chat. Browsing and listing are free; the fee appears only when the escrow deal resolves.

Protection works both ways. A buyer cannot remain silent forever after delivery because an undisputed deal has a defined release path. For the buyer, the reverse matters: pressing Buy does not immediately transfer money to the seller, and all deal terms are visible before funding.

Kaspa Deposit: collateral you do not have to chase

Kaspa Deposit is designed for rentals, equipment and other obligations where one party posts collateral but neither side should control the funds alone. The agreement fixes the amount, term and final claim window. If the holder does not file a claim on time, KAS returns to the depositor through the predefined path.

If a claim arises, the holder describes the breach and amount while the parties attach evidence from the deal chat. Outcomes can include a full return, a holder payout or a split. The AI remains an adviser rather than a signer. The normal service fee is funded on top of the collateral, so the agreed deposit amount returns in full on a normal outcome.

Arena and Boards: public experiences on Kaspa

Kaspa Forge goes beyond storage and settlement. Two products demonstrate that on-chain infrastructure can be a user environment rather than merely a financial backend.

Arena: a game decomposed into verifiable layers

KaspaForge Arena is a public mainnet beta for games using real KAS. Its flagship first experience is blackjack: the room and hand are represented by a sequence of on-chain states, the client verifies a transaction before signing, and covenant rules constrain settlement.

The model should not be reduced to “ZK proves it.” Separate layers provide separate guarantees: commit–reveal fixes randomness inputs, a proof binds the hidden deck to those commitments, Merkle paths authenticate opened cards, the wallet checks admission, and Kaspa L1 constrains states and payouts. The current beta also publishes its boundary: the KaspaForge house is the dealer and the hosted prover sees the witness required to construct the proof. Verifiable does not mean fully trustless, and the documentation keeps those concepts separate.

Arena is for users who want to explore practical on-chain game mechanics and who treat mainnet beta software as beta software. Before joining, read the rules, economics and verification boundaries, keep a current Desk backup and use published rooms.

Boards: accountless publishing without platform rent

KaspaForge Boards are public topic boards where a thread or reply is sent as a Kaspa transaction. Reading needs no account. To post, Desk signs a small on-chain operation; KaspaForge charges no platform fee, so the user pays only the dynamic network fee.

This is a public and pseudonymous environment, not an invisible one. The transaction graph remains open, so pseudonymity should not be confused with guaranteed anonymity. A moderator can hide rule-breaking content from the KaspaForge interface but cannot rewrite an existing BlockDAG transaction. The difference between protocol and viewer becomes directly visible.

How the non-custodial model works

The term “non-custodial” becomes meaningless unless we answer: who can sign, and what can the network allow that signature to do? In Kaspa Forge, the answer is distributed across four layers.

Three practical conclusions follow.

First, the Desk backup is critical. A non-custodial operator cannot restore what it never possessed. Second, read the amount, address and terms before signing even when the interface is familiar. Local signing prevents server-side key custody, but it does not prevent inattentive approval. Third, distinguish an on-chain guarantee from server convenience. A covenant timeout and a Telegram notification about that timeout are different things: the network validates one, while our infrastructure delivers the other.

Open recovery tools and source code live in the KaspaForge GitHub repository. The Toccata node background is also available in the official rusty-kaspa guide. Publication is not a substitute for an independent audit, but it lets users inspect the model rather than accept it on faith.

How Kaspa Forge differs from an exchange, DeFi frontend and ordinary wallet

Compared with an exchange, there is no internal customer balance. We do not accept KAS onto a company account and promise to release it later. Even when a server helps coordinate a flow, the money movement has a public transaction form.

Compared with an ordinary wallet, Kaspa Forge adds specialized states. A wallet answers “how do I sign a transfer?” Safe answers “how do I make a withdrawal delayed and cancellable?” Escrow answers “how do I constrain the outcome of a deal?” Deposit answers “how does collateral return on a deadline?”

Compared with a DeFi frontend, the focus is on understandable use cases with native KAS rather than yields, wrapped assets and long protocol chains. Kaspa Forge does not advertise APY or turn complexity into the product. A user selects a rule, reviews its parameters and signs a concrete action.

Compared with a chat-room guarantor, the intermediary does not receive complete financial control. Arbitration still requires human judgment, so no script can automate the fairness of a real-world dispute. The covenant can nevertheless constrain the consequences of that judgment to predefined recipients and prevent an arbiter from paying themselves.

How to get started with Kaspa Forge

Step 1. Create Desk and its backup

Open Kaspa Desk, create a profile, set a strong password and export the encrypted key file. Confirm that the file was actually saved and that the password can be retrieved from your password manager or chosen secure store.

Step 2. Choose one use case

You do not need to learn the full platform at once. Start with Safe for long-term storage, Escrow for a one-off P2P deal, Deposit for a rental, Marketplace for selling a product or service, or Boards for a public post. Arena requires separate familiarity with beta rules and the settlement receipt.

Step 3. Read the terms before signing

Check the network, amount, fee, deadline, dispute window, destination and product status. For Safe, decide where the alarm key will physically live. For Escrow, ensure both parties interpret the terms the same way. For Deposit, define the return and claim criteria. Clear terms reduce dispute risk better than any arbitrator.

Step 4. Start small and complete the full cycle

Test not only creation but completion: withdraw from Safe, refund a test deal, collect a payout, or restore the profile on another device. A full dry run turns abstract understanding into an operational skill.

Step 5. Check current status

Kaspa Forge evolves quickly, and different products may be mainnet, open beta or public beta. Before each new category of action, review Security, documentation and the product interface. Do not carry assumptions from Safe into Arena or from a normal deal into arbitration: each surface has its own model.

Verify it yourself

You do not have to begin with marketing claims. Check the core statements against primary sources and open artifacts:

• Kaspa Lore — the public overview of BlockDAG, proof of work and the current 10 BPS network.
• Kaspa Build — the official entry point for SDKs, RPC access and developer tools.
• KIP-17 and KIP-20 — the scripting and covenant ID specifications.
• Toccata node guide — the reference node implementation's guide to the upgrade.
• KaspaForge open tools — the contracts, recovery and CLI boundary published by the product team.

Kaspa Forge as a direction for Kaspa applications

Kaspa's public story often starts with speed: BlockDAG, parallel blocks, 10 BPS. That is foundational for infrastructure, but users do not arrive for a block-rate number. They arrive to solve a job — protect savings, complete a deal, recover collateral, sell work, publish an idea or verify a game outcome.

Kaspa Forge is built in that gap between protocol capability and everyday action. We turn Kaspa L1 features into separate tools with visible trust boundaries. Instead of asking users to “trust the ecosystem,” we show which key signs, which path the network allows, what the server does and what happens if the server disappears.

That is the platform's core marketing claim: fewer powers for the intermediary, not more promises from the intermediary. Where a rule can be enforced on-chain, we enforce it there. Where a human judgment remains, we call it human. Where software is still beta, we keep the word beta visible.

If you want one entry point into practical Kaspa services, begin with Desk, save the backup and choose the first job from the table above. Technology becomes useful not when it looks complicated, but when complexity becomes a clear rule you can verify before signing.