Kaspa programmability overview
Kaspa programmability is not one model. It is a set of building blocks. Start with the option that matches where your product logic lives today.
Tooling and builder workflows are still evolving. Use this guide to choose the right option first, 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 simpler: where does the core logic of your product live?
Choose by where the product logic lives
- If the core logic is about how assets can move and how protected outputs evolve, start with Covenants.
- If the core logic lives inside one managed app environment with a built-in account model for users, balances, permissions, and app state, look at Based Apps.
- If the core logic is per-action verification and settlement, especially for privacy, custom validity rules, or a custom account model, look at Inline ZK.
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.
Based Apps
Best when you want one managed app environment for a Rust app with users, balances, permissions, ongoing state, and a provided Kas bridge.
Inline ZK
Best when each action needs its own proof or validity check and should be verified and settled independently.
Future direction
Full vProgs describe a future network-composition model where independent apps can read or call each other directly.
They are future direction for Based Apps, not a separate current option. If you are building an app in a managed app environment today, use Based Apps and treat Full vProgs as the direction for richer app-to-app composition. Covenants and Inline ZK remain valid choices in their own right.
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
| Deploy | Execute |
|---|---|
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.
Based Apps
What it is
Based Apps are the current app-building path on Kaspa.
They give you one managed app environment with a built-in account model for users, balances, permissions, and app state. You write a Rust app against that environment and use the provided Kas bridge instead of designing the execution stack yourself.
Mental model
sequenceDiagram
participant W as Wallet
participant K as Kaspa
participant E as Based App Environment
participant A as Rust App
W->>K: Send an app action
K-->>E: Route the action into the environment
E->>A: Run the app logic
A-->>E: Update balances and app state
E-->>W: Return the new app result
Pick this when
- You want one managed app environment for your product.
- You want the built-in account model instead of defining users, balances, permissions, and app-state rules from scratch.
- Your product needs rich shared state and multi-step business logic.
- You want to build in Rust with the provided Kas bridge.
- Multiple features should coexist inside one app.
Good fits
- Consumer apps
- Trading or product suites
- Products with rich shared state and multi-step business logic
- Products that need bridging between the managed app environment and Kaspa
Developer experience
This is the most app-shaped option in the docs today. You focus on Rust logic and state transitions inside the managed app environment rather than designing the whole execution model yourself.
The environment provides the built-in account model and the Kas bridge. You still own product logic, state design, permissions, and UX. This is the closest current lane to the future Full vProgs world, but it is still one managed environment today rather than sovereign network-wide composition.
When not to use it
- Your product is mostly about native asset rules and flows.
- Each action should be verified and settled independently.
- You need a custom account model or a privacy-first execution model.
Current expectations
This is the current app path on Kaspa. The main builder job is to define product logic, state, and UX inside one managed app environment while the surrounding builder workflows continue to mature.
Future direction
For app builders, Full vProgs are the future direction for network-level app composition. Based Apps are the current app path and the simpler migration lane.
Inline ZK
What it is
Inline ZK are the specialist path for per-action verification and settlement.
Use it when the interesting part of the product is the proof attached to each action: privacy, custom validity rules, or a custom account model.
Unlike Based Apps, you do not inherit a built-in account model from a managed app environment. This path is for products that revolve around proving one action at a time.
Mental model
sequenceDiagram
participant W as Wallet
participant S as Proof Service
participant K as Kaspa
W->>S: Ask to verify an action
S->>S: Compute the action result and proof
S->>K: Submit the verified action
K->>K: Verify the proof
K-->>W: One action settles
Pick this when
- Each action needs custom validity checks before it settles.
- Each action should be verified and settled independently.
- Privacy is part of the product.
- You need a custom account model instead of the built-in account model from a managed app environment.
- You want Kaspa to verify the result without putting all of the computation on-chain.
Good fits
- Privacy-preserving actions
- Custom verified workflows
- Actions that should stay independent instead of living inside one managed app environment
Developer experience
This path gives you the most control over how one action is validated and settled, but it asks more from you. You own more of the proof design, system architecture, and operational setup than in Based Apps.
When not to use it
- Your logic is mostly about asset rules and flows.
- You want a managed app environment with a built-in account model and ongoing shared state.
- You want many actions to live inside one app environment rather than settle independently.
Current expectations
This is a specialist path. It usually requires more proof-system design and operational infrastructure than Covenants or Based Apps.
In deeper technical material, the component that generates the proof is often called the prover. That detail matters later. On a first read, the important idea is simpler: one action is proved, then that one action settles.
Future Direction: Full vProgs
What it is
Full vProgs are the future network-composition model for independent apps on Kaspa.
This page is architectural context for app builders, not a separate current option. The core idea is that independent apps would be able to read or call one another directly across the network instead of having composition happen inside one managed app environment.
How it differs from Based Apps
Based Apps give you one managed app environment today, with a built-in account model and app-local composition inside that environment.
Full vProgs describe a future where composition is a network property between independent apps, not just something that happens inside one managed app environment.
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.
Why it matters
The point is to make direct app-to-app composition possible across the network.
That changes the design space for builders who eventually want an ecosystem of interoperable apps instead of a single managed app environment.
Current expectations
This is not the path to optimize for today. If you are building an app now, use Based Apps and treat Full vProgs as the future direction for richer app-to-app composition. Covenants and Inline ZK remain valid choices for asset rules and per-action verification.