Kaspa ExplainedRead the network
Use node or public-service interfaces for blocks, transactions, and accepted history. Know which service you trust and how it handles missing or changed data.
Build
What spending rules can enforce
A covenant is a spending rule attached to an output. Test a wait, amount limit, and destination, then compare the rule with the application and tools around it.
A withdrawal with three conditions
A covenant can constrain how an output is spent. Try a withdrawal against three conditions.
What spending rules can enforceConstructed example
Locked output10,000 KAS
The remainder keeps the spending rule.
×Wait at least 60 example steps
✓Withdraw no more than 2,000 KAS
✓Use the authorized destination
No wallet or real funds. Each attempt starts from the same 10,000 KAS. “Steps” are illustrative; this is not a deployable contract or a specified locktime encoding.
Integration tasks
Receive payments
Track the accepting history, persist a checkpoint, and reverse application state when the accepted chain changes. Choose a policy for your use case.
Constrain spending
Specify which outputs are allowed, how state moves, and who can authorize each path. Test rejected transactions as carefully as successful ones.
Tools and implementation status
Live protocol
Toccata
Covenant spending rules, identifiers, sequencing commitments, and supported proof verification are active. Application readiness is separate.
DocumentationRelease candidate
Silverscript
v1-rc1 is experimental. Its documentation recommends testnet-10 until a stable v1.
DocumentationPrototype
Argent
Compiler and examples exist. Its README says it is not release-ready.
DocumentationResearch
vProgs
Early implementation. Repository existence does not establish production availability.
DocumentationCovenants, shared execution, and proofs
One agreement
A buyer can authorize payment to a seller, with a refund path after a deadline. The spending conditions travel with the output. Each permitted exit has to satisfy the contract.
An application many people update
A lending market also needs to coordinate deposits, loans, prices, and competing requests. Individual spending rules do not by themselves supply that shared execution system.
A computation checked by proof
A proof can establish a calculation over its specified inputs. If a user’s request was omitted from those inputs, a correct calculation can still leave that user out. The application needs to establish which requests belong in the calculation and their order.
The programmability documentation separates covenant rules, Based Apps, and the future direction of Full vProgs. Check the guarantees and readiness of each part before choosing an architecture. Programmability documentation
What a proof leaves to the application
Verification establishes the statement encoded in the proof under its assumptions. It does not automatically establish where inputs came from, whether required data remains available, or whether surrounding software is secure.
A claim about complete transaction processing therefore needs evidence about both computation and the sequence it processes.
Educational model
I will move if enough of us move.
A new service needs a viable group. Each person chooses when moving makes sense for them. Authorizing a move leaves their credits available until the group acts.
Try authorizing Ben and Cleo. Preview the group, then spend some of Ana’s balance before executing.
Ana is willing to move with a group. Ben and Cleo have not authorized a move yet.
This model moves imaginary credits in this page. It demonstrates revocable conditions and an all-or-nothing state change. No funds are locked or sent. Proposed coordination systems would need private group formation and secure execution; this example implements neither encryption nor a network protocol.
Before putting funds at risk
Review the exact compiler and node versions, transaction encoding, rejected paths, recovery paths, fee behavior, and independent security review. The educational vault above is not a deployable contract.