Covenants

What it is

Covenants are the path for asset rules on Kaspa.

They build on covenant-style spending constraints, but the model here is broader than a plain covenant. A protected output can carry state, define a state transition, validate the next outputs, and keep non-forgeable lineage through Covenant IDs. If the main job of the product is transfer policy, issuance, custody, release conditions, or asset-native state machines, this is the closest fit.

Mental model

flowchart TB
    A[Define the program]
    B[Create the first protected output]
    C[Covenant is live]
    A --> B --> C
        

flowchart TB
    W[Spend the protected output later]
    X[Kaspa checks the covenant]
    Y[Funds move and the next state is created]
    W --> X --> Y
        

Pick this when

• Your product is centered on asset behavior and stateful outputs rather than a full app runtime.
• You need rules for transfers, custody, issuance, unlock conditions, controlled flows, or output-level state transitions.
• You want the most direct path for value-moving logic with lineage-aware validation.

Good fits

• Vaults and treasury controls
• Escrow-like flows
• Time-based or condition-based unlocking
• Native asset logic
• Issuance and transfer policies
• Stateful asset programs

Developer experience

As a developer, this feels closer to declaring asset-flow rules and state transitions than building an application backend. It is the most native fit for asset behavior, but also the least managed one: you think more about transactions, protected outputs, Covenant IDs, output validation, settlement conditions, and state transitions than about a managed app environment.

When not to use it

• Your state becomes too large or your state transitions become too complex for this path to stay pleasant.
• Each action needs custom private or proof-driven verification.
• You want a built-in account model and a managed app environment.

Current expectations

This is a practical path for asset-centric and stateful-output-centric products, but the end-to-end tooling is still improving. Silverscript is a useful builder-facing reference point here: an experimental high-level language and compiler for Kaspa script with state-transition helpers and output-validation patterns.

Expect some lower-level workflow details around deployment and state handling while the builder experience matures. At a lower level, these programs build on covenant primitives that constrain how a UTXO can be spent, but the public model is richer than a plain spending constraint: lineage, state, and validated next outputs are part of the design.