It keeps the core things Bitcoiners care about:
✅ Proof-of-Work
✅ UTXO model
✅ permissionless decentralization
✅ open-source, fair launch ethos

But it introduces an architecture Bitcoin would never adopt without becoming a different system entirely: BlockDAG consensus (GHOSTDAG), which allows parallel blocks while preserving ordered consensus.
See Links to Github, community chats forums white papers and other Dev resources on http://kaspa.org

1) Beyond “digital cash”: Kaspa aims at sovereign settlement infrastructure
Bitcoin proved digital scarcity. The next stage is neutral, sovereign settlement at real-world speed.
Kaspa’s argument is bigger than payments: Kaspa is positioning as a universal settlement grid, essentially “Sovereignty as a Service” as its been said by @hashdag and @michaelsuttonil

Kaspa will be Meaning settlement infrastructure that can be:
✅ Global
✅ Neutral
✅ Real-time
✅ Permissionless
✅ Not controlled by a state, corporation, or validator cartel

This matters because the modern world is moving toward:
✅ Always-on markets
✅ Machine-to-machine payments
✅ Real-time trade and logistics
✅ Programmable compliance and reporting
✅ Tokenized assets and settlement rails

That future needs settlement that is fast enough to keep up.

2) Kaspa fills Bitcoin’s gaps without abandoning Bitcoin’s values
• Bitcoin’s base chain is intentionally slow and conservative. It wasn’t engineered for real-time settlement.
• Kaspa keeps PoW, but changes the throughput assumptions.

Kaspa’s network generates:
⚡️10 blocks per second
⚡️fully confirmed transactions in about 1 second

That’s why the comparison isn’t “Kaspa beats Bitcoin.”

It’s: Kaspa extends Bitcoin’s vision into a new performance envelope.
✅Bitcoin is sound scarcity.
✅Kaspa is sound settlement.

3) The broader altcoin problem: trilemma, MEV, parasitic L2s
Most altcoins “scale” by changing the rules of the game:
• Proof-of-Stake and validator politics
• governance capture and insider power
• centralized sequencing, bridging assumptions
• ecosystems where L2s extract rent while security and neutrality become fragmented

Kaspa solves scaling at the consensus layer using BlockDAG rather than relying on centralized validators or a stack of parasitic layers.

4) Adoption movers: independent orgs pushing real integration
Every blockchain’s final vulnerability is not tech. It’s adoption.

Some online community stats:
• Largest X Account – 246,649 followers @kaspaunchained
(plus 1000’s of Kaspa focused content creators)
• Telegram: 37,474 Members
• Discord 55,482 members

Kaspa is unusual because it’s not just hoping adoption happens. It has independent initiatives designed to drive it.
• Consistently innovating and flawlessly delivering from Genesis to the RUST Rewrite to Crescendo and now looking towards VProgs, Covenants, Oracles, DagKnight.
• Kaspa Industrial Initiative (@KaspaKii): focused on enterprise and industrial adoption across finance, supply chain, energy, and public sector pathways.
• WarpCore (KII initiative): middleware designed to bridge traditional institutional rails and standards into Kaspa settlement logic, including ISO 20022 alignment.
• Kaspa Ecosystem Foundation ( @Kaspa_KEF): separate ecosystem organization supporting long-term growth and development support.
Whether people agree with every approach or not, the point is: Kaspa has serious adoption scaffolding forming around it.

5) Proof the ecosystem is real: applications and events already shipping
Settlement infrastructure is proven by builders and real outputs, not promises.
Kaspa already has live ecosystem activity beyond “store of value” narratives:

Apps and primitives:
• Kaspa Name Service (@knsdomain): .kas domains and identity layer
• @kasiamessaging Messaging: encrypted decentralized P2P messaging built on Kaspa L1 transactions
• K-Social: ( http://k-social.network) Like X but decentralized and powered by Kaspa
• @KasMaporg – Mapping the Kaspa community, merchants and events
• Numerous decentralized Wallets, Explorers, DEXs, and more.

Events (real-world proof of adoption momentum):
• 100s of Global Events and Meetups since 2022
•Kaspa Experience (@KaspaExperience
– Berlin 2025): a full community conference showcasing the ecosystem and real-world adoption energy
• @kaspathon: a community-organized hackathon designed to test and showcase Kaspa’s latest builder capabilities

This is what matters: you’re watching a network evolve from a coin into a settlement-grade ecosystem.
This isn’t really #Bitcoin vs #Kaspa.
Bitcoin remains a benchmark for digital scarcity and first mover.
Kaspa is what happens when you take that same PoW ethos and push it into a new technical category: real-time, sovereign, scalable settlement infrastructure.
If the modern world is heading toward real-time settlement, Kaspa is one of the only networks attempting that future without abandoning the foundational decentralization model.

So….
Bitcoin:
• exposed the problem
• created an alternative store-of-value
• became a protest symbol against fiat + banking capture
• Was first to market for this new technology

Kaspa:
• keeps the same ethos (PoW, decentralization)
but focuses on the infrastructure layer
• aiming at real-time, high-frequency settlement and coordination. Not just money that holds value, but the backbone for real-time systems: finance, identity, trade, and data.

PS. One of the best “aha” moments is when we show 10BPS on a BlockDAG visualizer. 🙂

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

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.

Eliott Mea in France CtyptoXR Event

This event marks the culmination of nearly three years of monumental effort by the core development team, who have undertaken a complete architectural redesign and rewritten Kaspa’s core code from Golang to Rust, focusing on performance optimization across all possible fronts simultaneously. Thanks to this feat, Kaspa will become, by a wide margin, the fastest pure Proof-of-Work (PoW) coin in history, while maintaining the highest level of decentralization and transaction processing and confirmation speed in a permissionless, asynchronous system.

Moreover, this block generation speed, combined with linking blocks not in a chain but in a directed acyclic graph, creates a truly unique multi-leader consensus mechanism. This consensus has the potential to serve as the foundation for achieving the holy grails of crypto: a security budget, MEV (Miner Extractable Value) avoidance, and the implementation of reliable decentralized oracles.

At the same time, the code is written in such a way that running a full Kaspa node is possible on ordinary household PCs with standard internet connections, which is itself a unique feature for crypto projects offering this level of capability. It fully aligns with, and realizes in practice Satoshi’s vision of complete autonomy and self-sovereignty for every network participant, from large corporations and governments to ordinary individuals.

Last but not least, a new WASM interface for RPC requests was created along the way, greatly simplifying how wallets and apps interact with Kaspa nodes. It sparked a surge in Kaspa-compatible wallets, thanks to the sub-team that simultaneously worked on the node’s WASM subsystem and developed the Kaspa-NG wallet (https://kaspa-ng.org/) to replace the retiring Kaspa web and KDX wallets. People are gathering to watch and celebrate the transition online, so join us:

• @Kaspa Silver 𐤊 – Watch party: https://www.youtube.com/live/lLuT89eXmHY

• Blockchain Banter X Spaces: https://x.com/levendipro/status/1918000727378587861?t=m8Y4n7ycbtA6FkZtZcz7kQ

If, for some reason, you haven’t yet upgraded to the hardfork-ready node version, here’s the link to it: https://github.com/kaspanet/rusty-kaspa/releases/latest, and here’s the link to the post-fork working version of the Kaspa-stratum bridge which enables solo mining: https://github.com/aglov413/kaspa-stratum-bridge/releases/tag/v1.3.0

Today, without any doubt, will go down in crypto history as the day when the efforts of human intellect once again proved that the bastions of what seemed impossible inevitably fall under the pressure of talent and selfless dedication!

_____________________________________________________________________________________

X Post excerpts from Lead Developer, Michael Sutton about Crescendo

Kaspa’s 10 bps crescendo upgrade, activated today on mainnet, allows the innovation and scalability of the Ghostdag protocol (@hashdaget al) to truly shine for the first time. While the theory behind this multi‑leader, parallel‑structured DAG protocol has been implemented at 1 bps as well, a 1000‑millisecond block time is still sufficiently above modern internet RTT; thus, by tightening latency and network assumptions one can imagine a linear blockchain structure at 1 bps as well (cf. Solana’s 400 ms block time with a linear structure). Increasing the block rate to 10 per second, achieved by reducing block time to 100 ms (< 200 ms ≈ global RTT), can only be secure with a consensus protocol that inherently allows parallelism = multi‑leader consensus. Passing the RTT threshold is thus a qualitative, not merely a quantitative, leap. Link

A brain dump of all things crescendo, what’s included, what are the benefits… Link

Increasing the block per seconds from 1 to 10 bps while keeping block capacity ~fixed (more on that later). Throughput: obviously, transaction throughput increases. How much? almost tenfold but not exactly 10x. Having more parallel blocks increases the collision rate to some degree.

On TN10 and with current mempool txn selection policy, we observe ~80-90% efficiency (i.e., 80-90% of the txns are unique). If the mempool gets over congested and demand significantly exceeds capacity, this efficiency value goes towards 100%. So to conclude, TPS is increasing 8-9x. The missing info is mainnet average DAG width post-activation vs. today. Mempool policies can be finetuned in the coming future without a hardfork based on such real-world data. Frequency: average block time (=interval between blocks) is being reduced from 1 second to 100 milliseconds. This means blink-of-an-eye txn inclusion time. A transaction need not propagate to the whole network in order to be included; for instance, it can reach miners in its continent in 50ms and get mined after 200ms. The frequency also decreases post-inclusion confirmation times due to the increased density of the mining sampling process. Not to say confirmation times decrease tenfold, because they are now dominated by block latency which hasn’t changed. Rather, by back-of-the-envelope calculations, they have improved 30% (for the advanced: the tail of the Poisson governing worst-case DAG width diminishes faster, thus K can be set relatively lower, from 18 (1bps) to 124 (for 10bps) and not to 180 as one might expect).

Block parallelism: block parallelism increases with the block rate, and that, contrary to what you might think, is good. Despite collisions being slightly increased due to block parallelism, parallelism is crucial for creating a more fair system. It means there isn’t a monopoly of a single winning miner per round, but rather blocks must compete and make wise and competitive decisions within the latency round. The implications can be huge and far-reaching.

Oracle systems and MEV kickback auctions are some of the preliminary efforts. Going more into this is out-of-scope. I also need to justify why finance is becoming more relevant post-crescendo… assuming that’s the case, I think that even without implementing MEV kickback designs explicitly in consensus (yet), the mere intra-round “chaos” of the parallel DAG at 10 bps will already make economic manipulation much harder than in other, leader-based systems.

Other changes included in crescendo. How do I start, there’s so much.

KIP-9 is integrated into consensus, baking our unique state bloat solution inherently into the system. By the way, we call this “harmonic” sub-protocol the name STORM (for STORage Mass). In the process, KIP-9 was extended to include UTXO storage plurality (i.e., taxing a UTXO which consumes more storage appropriately), making it more futureproof.

KIP-10 adds support for basic covenants and additive addresses.

KIP-13 regulates transient storage requirements more strictly. Smart contract-related changes: KIP-14 enables payloads, allowing txns to carry arbitrary data (e.g., smart contract function calls).

KIP-15 is a technically minor upgrade — comprising one line of code — but enables a conceptually meaningful feature, allowing nodes to archive only transactions and prove their sequencing and acceptance trustlessly. This is significant for allowing pre-zk era L2 nodes to store and prove full SC execution to new syncers at a reasonable cost—hence effectively making such systems possible right after crescendo. The change proposed is a tiny subset of the zk design proposal (see Kaspa research forum—based rollups design posts) where such a mechanism was proposed as a necessary requirement for zk systems to operate over Kaspa, and turned out to have significant value also pre-zk. Overall, this means that preliminary SC L2s are possible over post-crescendo Kaspa (or Kaspa 2.0 as @hashdag refers to it internally) with sufficient trust models.

Crescendo is an historical moment in permissionless distributed systems, showing that a multi-leader consensus real-world system can achieve block times shorter than global internet round-trip time (RTT) without artificially suppressing the P2P network size or assuming proximity. Link