Kaspa programmability overview

Kaspa programmability is not one model. It is a set of building blocks.

Important

Tooling and builder workflows are still evolving. Use this guide to choose the right option, then go deeper as the implementation stack matures.

If you come from EVM or Solana, do not look for one universal smart contract box that fits everything.

On Kaspa, the first question is: Do I need execution concurrency?

• Sequential execution means users can wait for the previous action to finish before sending their own action.
• Concurrent execution means multiple users need to use the app at the same time, without waiting for each other.

flowchart TD
    A{"Do I need execution concurrency?"}
    A -->|Yes| B["Start with Based Apps"]
    A -->|No| D
    D["Start with Covenants"]
    B -.-> F["If I can split the app into sub-apps, Covenants can still work"]
    F -.-> D

If the product can be split into independent sub-apps, Covenants can still work even when some concurrency exists across those separate states.

Current options

Covenants

Best when the product is centered on asset rules and stateful outputs: who can move funds, how outputs evolve, how issuance works, or which conditions must hold before assets flow. Directly expressed on Kaspa L1.

Learn more about Covenants

Based Apps

Best when you want one app with built-in accounts and shared state. You write the app in Rust.

Learn more about Based Apps

Future direction

Full vProgs are the future direction for app-to-app composition across independent apps. If you picked Based Apps, treat Full vProgs as end-goal.

Specialized option

Inline ZK

Warning

Consider Based Apps and Covenants first. This option exists, but it usually demands significantly more builder effort.

Best when each action needs its own proof or validity check and should be verified and settled independently.

Learn more about Inline ZK

Covenants

What it is

Start here when the product is best expressed as asset-native state on Kaspa L1.

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. One protected state advances sequentially, though independent states or sub-apps can still run in parallel.

Mental model

Picture a chain of protected outputs, where each spend must create the next valid state.

flowchart TD
    S0[Protected output<br/>State S0]
    T1[Spend transaction<br/>Validate S0 to next state]
    S1A[Protected output<br/>State S1A]
    S1B[Protected output<br/>State S1B]
    T2[Later spend<br/>Validate S1A to S2]
    S2[Protected output<br/>State S2]

    S0 --> T1
    T1 --> S1A
    T1 --> S1B
    S1A --> T2 --> S2

Pick this when

• One shared state can advance one valid step at a time.
• Your product is centered on asset behavior and stateful outputs such as transfers, custody, issuance, unlock conditions, controlled flows, or output-level state transitions.
• Your state stays small relative to covenant redeem-script size. The script size limit is about 300 KB, and your usable state must stay below that because the contract code also consumes part of the same script budget.

Good fits

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

When not to use it

• Many users need to mutate the same shared state concurrently.
• Your state becomes too large or your state transitions become too complex for Covenants to stay pleasant.
• Each action needs custom private or proof-driven verification.

Current expectations

You can build with this model today, but the tooling is still early.

Silverscript is the main builder reference point right now. It gives you a higher-level way to define your covenant and state transitions.

Expect some manual work around deployment, transaction construction, and state handling.

Based Apps

What it is

Start here when one app needs shared-state concurrency by default.

You build one app in Rust. It runs inside a managed environment that provides built-in accounts, balances, shared-state execution. If your product is mostly about native asset rules without default shared-state concurrency, first check whether Covenants fits more naturally.

Mental model

Picture users sending app actions through Kaspa L1 to your app. The managed environment runs your Rust logic, updates shared app state, and later settles back on L1.

flowchart TD
    U1[User A]
    U2[User B]
    L1[Kaspa L1]
    R[Managed environment]
    A[Your Rust app logic]
    S[Shared app state<br/>Balances and app data]

    U1 --> L1
    U2 --> L1
    L1 --> R
    R --> A
    A --> S
    S --> R
    R -.-> L1

Pick this when

• Many users need to touch the same app state without waiting for previous actions to finish.
• You want built-in accounts and shared-state execution.

Good fits

• Consumer apps with many concurrent active users
• Trading venues or product suites

When not to use it

• Your product is mostly about native asset rules and flows.
• You do not need concurrency by default and your state fits naturally in Covenants.
• Each action should be verified and settled independently.
• You need a custom account model or a privacy-first execution model.

Current expectations

This option is in construction.

If you are thinking about broader app-to-app composition, treat Full vProgs as the future direction rather than a separate current option.

Future Direction: Full vProgs

What it is

Full vProgs are the future network-composition direction for independent apps on Kaspa.

This page is forward-looking architectural context, not a separate current option. If you need an option today, use Based Apps.

The core idea is that independent apps would be able to read or call one another directly across the (TODO: how do you want to call it? L2?) network instead of keeping composition inside a single app.

How it differs from Based Apps

Based Apps lets you build one app today, with built-in accounts and app-local composition.

Full vProgs describe a future where composition is a network property between independent apps, not just something that happens inside one app.

What synchronous composition means

Synchronous composition means one app can read another app’s current state or call another app in the same flow, without waiting for a later settlement round, bridge step, or deferred action.

It changes the design space for builders who eventually want an ecosystem of interoperable apps instead of composition staying inside a single app.

Inline ZK

What it is

Start here when each action should prove its own validity and settle independently.

This is the specialist path for products whose core job is the proof attached to each action: privacy, custom validity rules, or a custom account model.

Warning

Consider Based Apps and Covenants first. If your main need is shared app concurrency, start with Based Apps; if it is native asset rules and flows, start with Covenants.

Mental model

sequenceDiagram
    participant U as User
    participant K as Kaspa

    U->>U: Compute the action result and proof
    U->>K: Submit the execution proof
    K->>K: Verify the proof
    K-->>U: One action settles

Pick this when

• Each action needs its own proof or custom validity check before it settles.
• Each action should be verified and settled independently instead of living inside one shared-state app.
• Privacy is part of the product.
• You need a custom account model instead of the built-in one from Based Apps.
• You want Kaspa to verify the result without putting all of the computation on-chain.

Good fits

• Privacy-preserving actions
• Proof-verified workflows
• Independent actions with custom settlement rules

When not to use it

• Your logic is mostly about asset rules and flows.
• You want built-in accounts and ongoing shared state.

Current expectations

This is the most specialized and demanding option in this guide.

You own more of the proof design, prover architecture, and operational setup than in Covenants or Based Apps.