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.
Based Apps
Best when you want one app with built-in accounts and shared state. You write the app in Rust.
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 AppsandCovenantsfirst. 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.