A covenant on Kaspa is KAS held under rules that the network enforces. It can control not only who may spend the coins, but also what the spending transaction must do next. A valid signature alone may not be enough. [1]
How it works
Kaspa keeps coins in unspent transaction outputs, usually called UTXOs. Think of each output as a separate package of coins with a lock. A transaction spends existing packages and creates new ones. [2]
With a normal signature-based lock, the main question is whether the spender has the right key. A covenant can also inspect the transaction spending it, including its inputs and outputs. This lets it check where the coins go and which rules protect them afterward. [1]
The rules are a script, a small program. The current output holds a cryptographic commitment to that program. When someone spends the output, they reveal the program, and the network checks that the transaction follows it. [3]
A continuing covenant can require the transaction to create its next valid version. This is how an agreement can carry its rules forward rather than lose them after the first payment. [1]
What it makes possible
- Money with conditions. A signature can be required alongside restrictions on the transaction’s destination or outputs. [1]
- Agreements that remember progress. The documentation gives a counter example: each update must increase the number, but cannot increase it beyond a permitted step. Its current number travels with the protected output. [3]
- Games with enforceable rules. In the March 2026 developer discussion, the speakers explain how coins can be locked to follow chess rules and the game’s settlement conditions. [1]
The stored information is not a shared account variable. It belongs to the current output’s script. Updating it means spending that output and creating a new one with the new information. [3]
Why Kaspa uses this approach
Ori Newman, one of Kaspa’s earliest core developers, explains that the aim was “smarter money” while keeping the UTXO model simple to verify and easy to process in parallel. Covenants add useful conditions without replacing that model with one shared application state. [4]
They are not just a proposed feature. The September 2026 Kaspa Covenant Dev Workshop describes the richer covenant locks as enabled following the Toccata upgrade. [2]
One unusual example from that workshop is a snowball covenant: its rules require it to be recreated holding more coins. This illustrates that covenant rules can continue across successive spends, rather than merely approve one payment. [2]
For the plain-language reasoning, watch Ori Newman explain why Kaspa needed covenants. [4] For the spending mechanics, watch the developer discussion from 7:56, then read the Covenant State documentation. [1][3]