Kaspa’s story has always been about solving what others said couldn’t be solved: achieving high throughput in proof of work without increasing L1 complexity or weakening decentralization. Now, as builders begin exploring what’s possible on top of that foundation, a new question emerges: how do we enable rich programmability around a fast Layer 1 while keeping the base protocol minimal and easy to verify?

The conversation has become crowded with terms like vProgs, rollups, sidechains, and L1 tokens such as KRC-20. Each points toward a vision of programmable money and data, but they live on different timelines and serve different purposes. Some exist now, others are still being written into Kaspa’s long-term design, some may evolve or become redundant.

This document maps that landscape. It separates the near-term tools that developers can use today, like Igra’s based rollups, from the long-term direction of Kaspa Core’s verifiable programs (vProgs). It also places sidechains and on-chain token standards in context, showing how these approaches can coexist, evolve, and find their natural roles as the ecosystem matures.

The goal isn’t to crown a winner, but to bring clarity. By understanding where each layer fits, and when it fits, we can align the community’s expectations and accelerate the collective vision: a verifiable, and sovereign digital economy built on Kaspa.

The Kaspa Programmability Landscape

Near term: Rollups on Kaspa give real programmability now. Igra’s based rollup approach is the most active track today, with public nodes and EVM tooling coming online. igralabs.com+1

Long term: vProgs are Kaspa’s native execution vision for verifiable programs with off-chain execution and on-chain verification, designed to keep L1 lean while enabling rich logic and synchronous composability. Kaspa Research+2Kaspa Research+2 

For more insight into vProgs and the Kaspa Core roadmap, read the Kaspa vProgs Architecture Overview.will be a kaspa.org blog and Youtube link

Sidechains and app-chains: Useful for sovereignty and specialization, but they are separate consensus domains that do not inherit Kaspa L1 security by default. Dymension’s RollApps are an example of this design space. docs.dymension.xyz

L1 “programmability” today: KRC-20 (Kasplex) and similar inscription style protocols live on L1 as data. These are helpful experiments, but much of this functionality is expected to migrate to L2 environments as they mature. docs-kasplex.gitbook.io+1

The Landscape

vProgs on L1: Kaspa’s native verifiable programs model. Execute off chain, verify on chain, keep L1 fast and lean. Targets synchronous composability without sacrificing sovereignty of programs. Timeline is long term and tied to core protocol work alongside DagKnight era improvements. Kaspa Research+1

Rollups on Kaspa (L2): Pragmatic route to programmability now. Sequencing leverages Kaspa’s blockDAG. Igra Labs is building a based rollup stack with EVM support and bridging modules, shipping testnet infra and public endpoints. Kaspa Research+2igralabs.com+2

L1 inscriptions and KRC-20: Data insertion plus indexing on Kaspa L1. Useful for tokens and NFTs, while L2 environments will handle use cases that benefit from richer logic and more complex state. docs-kasplex.gitbook.io+1

Sidechains and app-chains: Separate chains with their own consensus that connect to Kaspa. Good for sovereignty and customization, but security depends on bridges and the sidechain’s validator set. Dymension RollApps illustrate this pattern. docs.dymension.xyz

What ships when

Near term, community can build today

• Deploy dApps to EVM environments that sequence on Kaspa through Igra’s stack. Public test nodes and RPC are available. Kaspa
• Use KRC-20 or inscription style patterns when you only need simple on-chain data and indexing, not complex logic. docs-kasplex.gitbook.io+1

Mid to long term, core protocol goal

• vProgs deliver native, verifiable program execution with on-chain proofs, designed for synchronous composability and high throughput. Community research threads lay out pruning, composability, and L1↔L2 design questions. Kaspa Research+1
• Some of these capabilities may also appear through based rollups combined with L1 ZK facilities, since certain elements of the vProg architecture can be explored without the complete vProg mechanism. This remains an active area of research.

How they differ

Topic	vProgs (L1-integrated rollup architecture)*	Rollups on Kaspa (L2)	Sidechains or app-chains	L1 inscriptions, KRC-20
Security anchor	Kaspa L1, native verification of proofs	Kaspa L1 for ordering and settlement, proofs verified per rollup design	Own consensus, bridge trust model	Kaspa L1 data plus off-chain indexers
Composability goal	Synchronous across programs, by design	Within a rollup now, cross-rollup via messaging or based designs later	Within each sidechain only	Limited to data formats
Timeframe	Long term roadmap	Near term, already usable	Always available, but separate from L1	Available now for simple use cases
Dev UX	New model, not EVM	EVM first through Igra	Varies by stack	No full smart contracts

Sources on vProgs design and goals, and L1↔L2 research threads. Kaspa Research+1
Igra architecture and public endpoints for near-term dev work. igralabs.com+1
Kasplex KRC-20 docs and overview. docs-kasplex.gitbook.io+1
Dymension RollApps overview. docs.dymension.xyz

* vProgs are rollup-like and fit within the broader rollup family, but they differ from classical L2 rollups because they are sequenced by Kaspa L1 and designed for synchronous composability instead of operating as separate chains.

Evolution path without confusion

1. Start on L2: Ship apps on Igra’s EVM rollup. You inherit Kaspa L1 ordering, get mainstream tooling, and can move fast while vProgs mature. igralabs.com+1
2. Graduate features to vProgs over time: Critical logic that benefits from native verification and tighter L1 guarantees can migrate to vProgs once available. Research is already outlining composability and pruning requirements. Kaspa Research+1
3. Use sidechains only when sovereignty outweighs L1 settlement benefits: Choose this when you need your own parameters and do not require Kaspa’s L1 security for every step. docs.dymension.xyz
4. Treat KRC-20 as a bridge, not a destination: Great for lightweight tokens or proofs of concept. docs-kasplex.gitbook.io

Frequent misconceptions

“vProgs are just another name for rollups.”
Yes and No. vProgs are a type of rollup in architecture, but not classical rollups. They are an L1-integrated rollup architecture with off-chain execution, on-chain verification, and native sequencing. Classical rollups run as separate L2 chains, while vProgs are built directly into L1 semantics. Kaspa Research+1

“vProgs are smart contracts running on Kaspa L1.”
No. vProgs are an architecture for apps running next to L1, with ZK verification and shared state standards. Not executing on-chain. Kaspa vProgs yellow paper

“Rollups on Kaspa cannot be EVM or practical now.”
Igra’s stack explicitly targets EVM compatibility and has published litepaper and public endpoints for builders. igralabs.com+2X (formerly Twitter)+2

“Kaspa L2s work like Ethereum rollups.”
No. Based rollups have no centralized sequencer — transactions ordered directly by Kaspa consensus. Fundamentally different model, with different security assumptions and economy. Igra litepaper

“L2s compete with vProgs.”
No. Based L2s are proto-vProgs. As ZK VMs, state composability standards, and native verification mature, L2s evolve into full vProg architecture. From Rollups to vProgs

“Covenants alone enable programmability.”
Partial. Covenants give conditional spending (asset scripts, token standards). Add ZK verification = foundation for sovereign composable vProgs. Both needed. Kaspa Research

“vProgs guarantee liquidity defragmentation.”
No. vProgs need unified asset layer. Without base-layer token standard, each vProg issues wrapped tokens = fragmented liquidity, broken ecosystem. The architecture enables composability, but only if value can move smoothly between vProgs. vProgs Yellow Paper

“ZK opcodes = vProgs.”
No. ZK opcodes provide L1 foundation. Production vProg ecosystem requires mature stack: battle-tested ZK VMs, composability standards adopted across builders, dev tooling, auditors familiar with sovereignty model, legal frameworks. These will be developed through builder ecosystem collaboration and iteration cycles

“KRC-20 is Kaspa’s smart contract system.”
KRC-20 is a data insertion and indexing protocol on L1. It is not a full contract VM. L2s are expected to take over richer programmability. docs-kasplex.gitbook.io+1

“Sidechains equal L2.”
Sidechains are separate consensus domains. They do not automatically inherit L1 security. That trade-off is intentional for sovereignty and performance. Dymension’s docs describe this explicitly. docs.dymension.xyz

Community confusion called out by builders themselves:
Igra publicly clarified language about inspiration and scope to reduce misreadings about “competing with Kaspa core.” This helps separate near term rollups from long term vProgs. X (formerly Twitter)

What to use, when

• Payments, DeFi, EVM tooling, quick integrations: Rollup via Igra. Build now, connect existing wallets and infra, plan a future on-ramp to vProgs for critical parts. igralabs.com+1
• Native verifiable apps with L1-level guarantees and fine-grained composability: vProgs, once ready. Track research threads and proposals. Kaspa Research+1
• Specialized zones or domain-specific throughput where you accept separate consensus: Sidechain or app-chain. docs.dymension.xyz
• Simple tokens or proofs on L1 for now: KRC-20. Expect migration to L2 as ecosystems mature. docs-kasplex.gitbook.io

Kaspa’s architecture is not a single lane, but a highway system under construction. Each route, L1 vProgs, L2 rollups, sidechains, and experimental on-chain standards, serves a different purpose, yet all lead toward the same destination: scalable, verifiable freedom.

The next few years will be about connecting those routes. Rollups will deliver real applications first, proving what is possible on Kaspa’s settlement layer. Sidechains will test sovereignty and specialization. Meanwhile, vProgs will continue to take shape inside Kaspa Core, preparing the protocol for a future where logic and proof coexist natively.

Builders, researchers, and users all contribute to the direction of this ecosystem. Clarity matters, knowing what belongs on L1 and what grows around it. As these pieces mature, Kaspa stands to become a standard for settlement and a secure base for providing sovereignty as a service to applications, chains, and users.