Builder guide
Kaspa builders should start with the shape of the state: sequential L1 outputs, shared-state execution, per-action proofs, or later app-to-app composition.
Status rule: builder docs and open repositories show what people can study or prototype. Mainnet status still comes from activation, releases, and working applications.
Decision tree
| Question | If yes | If no |
|---|---|---|
| Do many users need to touch the same app state at the same time? | Start with based apps or vProgs-compatible runtime work. | Start with covenants and L1 state outputs. |
| Can the product be split into independent sub-apps or independent states? | Covenants can still work for each separate state. | Shared-state app architecture becomes more natural. |
| Does each action need its own proof, privacy check, or custom validity rule? | Consider inline ZK, but expect more proof and operations work. | Use covenants or based apps first. |
| Does the app need synchronous composition with other independent apps? | That is the future full-vProgs direction. | Build the narrow app first and keep the interface clean. |
Current options
Targeted
Best for asset rules and stateful outputs: vaults, treasury controls, escrow-like flows, unlock conditions, issuance policy, and small UTXO state machines.
One protected state advances one valid step at a time. Independent states can still run in parallel, but one hot state is sequential.
Roadmap
Best when one app needs built-in accounts, balances, and shared-state execution. Users send actions through Kaspa L1, and a managed environment runs the Rust app logic.
This is construction-stage app architecture, not a mature public app platform.
Specialized
Best when each action needs its own proof or custom validity check before it settles: privacy-preserving actions, proof-verified workflows, or custom account models.
This path usually requires more prover design, proof infrastructure, and operational ownership.
Future direction
Full vProgs are the future app-to-app composition direction: independent apps reading or calling one another in the same flow without separate bridge-style waiting.
Treat this as architectural direction, not a current option for production apps.
Build examples
| Product shape | Likely starting path | Why |
|---|---|---|
| Vault, treasury, inheritance, recovery, escrow | Covenants | The product is mostly about who can move funds and how stateful outputs evolve. |
| Native asset issuance or transfer policy | Covenants | The app logic is asset-native and can often stay close to L1 output rules. |
| Trading venue, game economy, shared balance app | Based app | Many users need to touch shared state without waiting for a single UTXO chain to advance. |
| Private action, custom validity check, proof-gated workflow | Inline ZK | The proof is part of every action, so verification becomes the product boundary. |
| Composable app network with calls across independent apps | Full vProgs later | The need is app-to-app synchronous composition, which belongs to the longer architecture target. |
Builder tooling
Higher-level covenant tooling and examples for state transitions. Useful for learning the covenant direction; tooling and deployment workflows are still early.
Early Rust framework work around based computation, scheduler/runtime/storage layers, L1 bridge concepts, and ZK proving components.
Standalone Python SDK with v1.1.0 release evidence for GetVirtualChainFromBlockV2 and UtxoProcessor/UtxoContext bindings.
Open PR for optional transaction-history indexing and GetTransaction RPC support. Relevant for wallets, explorers, and app infrastructure if merged and released.
Status wording
Use the positive stage first. Add caveats only where a reader might confuse builder work with live mainnet functionality.
Sources