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.