introduction
As blockchain technology develops, scalability and programmability remain key challenges, especially for blockchains that adopt the UTXO model. Kaspa, as a layer-one public blockchain that utilizes the BlockDAG structure, achieves high throughput, but lacks native smart contract functionality, a limitation also faced by other UTXO systems such as Bitcoin. To address this problem, the Kaspa ecosystem developed Kasplex L2, a second-layer solution that implements smart contracts compatible with the Ethereum Virtual Machine (EVM) based on the Rollup architecture.
In this article, we will conduct a technical analysis of Kasplex L2 from the perspective of security and research institutions. Our goal is to provide a tangible assessment of its design, technical implementation, and its impact on UTXO blockchains. We will explore how Kasplex L2 works, compare it to Bitcoin Inscriptions (such as BRC-20), and discuss its strengths and limitations. This analysis is intended to provide a reference for a broader discussion of scalability solutions for UTXO model blockchains.
Understanding Kaspa's primary chain: a high-throughput UTXO blockchain
Kaspa is a first-level blockchain with a BlockDAG structure that allows multiple blocks to be generated in parallel. The design is driven by the GHOSTDAG protocol, which enables Kaspa to achieve a high throughput of 10 BPS. Unlike account-based blockchains such as Ethereum, Kaspa uses the UTXO model, where transactions are verified by consuming unspent outputs and creating new outputs, thus ensuring an efficient verification process.
While this architecture performs well in payment scenarios, it presents challenges in terms of programmability. The UTXO model is inherently stateless and lacks the ability to maintain persistent state or perform complex computations — critical features required for smart contracts. As a result, Kaspa’s functionality is limited to simple transfers, which has prompted the development of second-layer solutions to expand its capabilities.
Kasplex L2: Rollup-based blockchain for smart contract execution
The Kaspa ecosystem explores three Layer 2 (L2) solutions: Sparkle, Igra L2, and Kasplex L2. Sparkle is still in the theoretical stage, and Igra L2 is still in the development stage. Our analysis focuses on Kasplex L2 because it is the closest to mature implementation so far.
Kasplex L2 is a Rollup-based second-layer scaling solution that relies on the first-level chain for transaction ordering and data availability, while shifting the computational load to the second layer. In this design, Kaspa's first-level chain is responsible for determining the standard order of transactions and ensuring that its data is publicly available, while Kasplex L2 executes EVM bytecode to implement smart contract functions.
Technical design and workflow
The core mechanism of Kasplex L2 is to embed EVM bytecode in the payload of Kaspa primary chain transactions. The process can be divided into the following steps:
Transaction submission: A user submits a transaction to the Kaspa primary chain, where the payload contains EVM bytecode. For example, the payload may encode a call to the HelloWorld() smart contract function.
First-level chain ordering: Kaspa's BlockDAG orders transactions within its DAG structure, providing a deterministic transaction sequence.
Layer 2 execution: Kasplex L2 runs as an indexer, scanning the payload transactions on the primary chain, extracting the EVM bytecode, executing it in the specified order, and updating its state. Invalid or conflicting transactions (such as transactions attempting to double-spend) will be discarded.
Transaction submission mechanism
Kasplex L2 supports two transaction submission methods, each with different effects:
Canonical Submission: Transactions are submitted directly to L1 through Kaspa-compatible wallets. This method does not require relay nodes and complies with the decentralization principle of the blockchain system.
Proxied Submission: Transactions are submitted through a relayer to be compatible with EVM tools like MetaMask. The relayer forwards the transaction to Kaspa L1 to ensure that it is recorded before being processed by L2. This approach prioritizes user convenience but introduces a reliance on relayers.
The proxy submission mechanism ensures atomicity by requiring all second-layer transactions to be anchored on the L1 chain. If a transaction is generated on L2 but has not yet been recorded on the primary chain, the relayer will submit it to the L1 chain for confirmation. This design prevents "native" L2 transactions that bypass the L1 chain consensus and avoids potential security risks. The following figure illustrates the two submission paths:
Canonical path: Wallet → Kaspa L1 → Kasplex L2
Proxy path: MetaMask → Relay → Kaspa L1 → Kasplex L2
You may notice that the transaction is actually finalized on L1 before being interpreted by the L2 indexer. This is exactly how Kasplex L2 works: L1 finalizes the data first, and then L2 reads the transaction and updates the state.
Comparison with Bitcoin Inscriptions
To better understand Kasplex L2, it is helpful to contrast it with Bitcoin Inscriptions (specifically BRC-20). Both aim to extend the functionality of UTXO model blockchains by leveraging L1 for data storage and sorting, but there are differences in their implementation and goals.
Similarities
Embedding data in L1: Both Kasplex L2 and BRC-20 will embed data in primary chain transactions. BRC-20 uses Bitcoin's Tapscript (enabled by the SegWit upgrade) to store token metadata, usually implemented through a three-step process of "commit (data hash) → reveal (reveal, data itself) → spend (spend, token transfer)". Kasplex L2 embeds EVM bytecode into the payload of Kaspa L1 transactions, achieving similar L2 operation anchoring.
L1 as a trusted source of data: In both cases, L1 provides ordering of operations. BRC-20 relies on the Bitcoin blockchain to order token transfers, while Kasplex L2 uses Kaspa’s BlockDAG to order smart contract executions.
Dependence on indexers: Both rely on off-chain indexers for processing. BRC-20’s indexer parses Bitcoin transactions to track token balances, while Kasplex L2’s indexer executes EVM bytecode to maintain smart contract states.
Differences
Achieving efficiency: BRC-20’s three-step process is a workaround for Bitcoin’s rigid protocol, while Kasplex L2 benefits from Kaspa’s more cooperative L1, enabling data to be embedded within a single transaction payload, reducing complexity and system overhead.
Performance considerations: Bitcoin’s throughput is about 7 transactions per second, with an average block generated every 10 minutes, making the Inscriptions process slow and expensive. Kaspa’s 10 BPS upgrade provides significant performance advantages, enabling Kasplex L2 to process larger transactions more efficiently.
Scope and functionality: While BRC-20 focuses primarily on token issuance and transfer, Kasplex L2 supports full EVM compatibility, allowing the running of complex smart contracts such as DeFi protocols or NFT marketplaces.
Protocol flexibility: Bitcoin’s design emphasizes immutability, forcing L2 solutions to circumvent its limitations. Although Kaspa also uses the UTXO model, its L1 design is more flexible and can be more closely integrated with L2 solutions such as Kasplex.
This comparison highlights a key insight: while both are similar in concept of leveraging L1 for data storage and sorting, Kasplex L2 leverages the architectural strengths of Kaspa to achieve greater efficiency and broader functionality than inscription.
Evaluating Kasplex L2: Strengths and Limitations
From the perspective of technical research, Kasplex L2 exhibits the following significant advantages and limitations.
advantage
Functional expansion: Kasplex L2 successfully expands Kaspa's capabilities by supporting EVM-compatible smart contracts, enabling it to carry use cases such as decentralized applications and tokenization that cannot be achieved on the first-level chain.
Efficient use of L1: Kasplex L2 uses Kaspa's BlockDAG to achieve transaction ordering and data availability, minimizing the computational burden of the second layer and focusing only on the execution level. This design is highly compatible with Kaspa's high-throughput architecture.
Public Verifiability: Since all transactions are recorded on L1, the execution of smart contracts on Kasplex L2 can be independently verified by re-running the EVM bytecode in a standard sequence, thus ensuring transparency.
Limitations and risks
Indexer trust issue: L2 indexers play a key role in executing bytecode and maintaining state, but there is a risk of malicious indexer behavior, such as maintaining fake state privately while providing Merkle roots to the public. Solving this problem requires the establishment of a decentralized indexer network and the introduction of economic incentives or punishment mechanisms.
Reorganization Challenge: Although Kaspa's BlockDAG is efficient, its parallel block generation mechanism may lead to the reorganization of recent blocks. This will force L2 to roll back and re-execute transactions, increasing system complexity and generating a certain risk of zero-confirmation double spending in L2.
Implications for UTXO Model Blockchain
Kasplex L2 provides a case study for programmability expansion of UTXO model blockchains, which has reference significance for systems such as Bitcoin. Both Kaspa and Bitcoin are limited by UTXO design in terms of smart contract support, but Kaspa's higher throughput and more flexible L1 architecture create a more favorable environment for L2 solutions.
For Bitcoin, the design of Kasplex L2 proposes the following directions for exploration:
Relay Integration: Proxy Submission Mechanism shows how to integrate EVM tools with UTXO blockchains, an idea that can be applied to second-layer solutions such as Bitcoin’s BitVM.
Indexer-based execution: Using indexers to perform calculations off-chain and anchor data on L1 is consistent with the Bitcoin Inscriptions model and may inspire new ideas for programmability expansion.
From a research perspective, Kasplex L2 is a valuable experiment that demonstrates how the differences in throughput and protocol flexibility of UTXO blockchains affect the feasibility of L2 solutions. Its research results can provide design references for the entire blockchain ecosystem, especially for systems that prioritize decentralization and security over native programmability.
in conclusion
Kasplex L2 is a technically sound Rollup-based implementation that supports EVM-compatible smart contracts by leveraging Kaspa’s L1 for transaction ordering and data availability. Our analysis highlights its efficiency in leveraging Kaspa’s high-throughput BlockDAG, and its ability to extend functionality through EVM compatibility. We believe Kasplex L2 makes a practical contribution to the research on L2 solutions for UTXO-model blockchains. Comparison with Bitcoin Inscriptions reveals similarities in shared principles and the impact of L1 design on L2 feasibility. For researchers and developers, Kasplex L2 provides a perspective on the intersection of scalability, programmability, and decentralization in blockchain systems.
refer to
Kasplex Github. [Online]. Available: https://github.com/kasplex/indexer-executor
Kaspa Research, "On the Design of Based zk-Rollups over Kaspa's UTXO-Based DAG Consensus," 2024. [Online]. Available: https://research.kas.pa/t/on-the-design-of-based-zk-rollups-over-kaspas-utxo-based-dag-consensus/208
Special thanks to @ZorrotChen, a researcher at our BitsLab, for your contribution to this article!
