Introduction

As blockchain technology evolves, scalability and programmability remain critical challenges, particularly for blockchains using the UTXO model. Kaspa, a Layer 1 blockchain leveraging a BlockDAG structure, achieves high throughput but lacks native smart contract functionality, a limitation shared by other UTXO-based systems like Bitcoin. To address this, the Kaspa ecosystem has developed Kasplex L2, a Layer 2 solution designed to enable Ethereum Virtual Machine (EVM) compatible smart contracts through a based rollup architecture.

In this article, we provide a technical analysis of Kasplex L2 from the perspective of a security and research firm. Our goal is to evaluate its design, implementation, and implications for UTXO-based blockchains, without advocating for Kaspa or its ecosystem. We’ll explore how Kasplex L2 works, compare it to Bitcoin’s Inscriptions (e.g., BRC-20), and assess its strengths and limitations. This analysis aims to contribute to the broader discourse on scaling solutions for blockchains with constrained programmability.

Understanding Kaspa Layer 1: A High-Throughput UTXO Blockchain

Kaspa is a Layer 1 blockchain that uses a BlockDAG structure, allowing multiple blocks to be produced in parallel. This design, powered by the GHOSTDAG protocol, enables Kaspa to achieve a throughput of 10 BPS performance. Unlike account-based blockchains such as Ethereum, Kaspa employs a UTXO model, where transactions consume unspent outputs and create new ones, ensuring efficient validation.

While this architecture excels for payment use cases, it poses challenges for programmability. The UTXO model is stateless by nature, lacking the ability to maintain persistent state or execute complex computations—key requirements for smart contracts. As a result, Kaspa’s functionality is limited to simple transfers, prompting the development of Layer 2 solutions to expand its capabilities.

Kasplex L2: A Based Rollup for Smart Contract Execution

The Kaspa ecosystem has explored three L2 approaches: Sparkle, Igra L2, and Kasplex L2. Sparkle remains largely theoretical, and Igra L2 trails in development. Our analysis focuses on Kasplex L2, as it represents the most mature implementation to date.

Kasplex L2 is a based rollup, a type of Layer 2 scaling solution that relies on the L1 for transaction sequencing and data availability, while offloading computation to the L2. In this design, Kaspa’s L1 determines the canonical order of transactions and ensures their data is publicly accessible, while Kasplex L2 executes EVM bytecode to enable smart contract functionality.

Technical Design and Workflow

The core mechanism of Kasplex L2 involves embedding EVM bytecode in the payload of Kaspa L1 transactions. The process can be broken down as follows:

Transaction Submission: A user submits a transaction to Kaspa L1, including a payload that contains EVM bytecode. For example, the payload might encode a call to a smart contract function like HelloWorld().

Sequencing by L1: Kaspa’s BlockDAG orders the transaction within its DAG structure, providing a deterministic sequence of all transactions.

L2 Execution: Kasplex L2 operates as an indexer, scanning the L1 for transactions with payloads. It extracts the EVM bytecode, executes it in the specified order, and updates its state. Invalid or conflicting transactions (e.g., those attempting to double-spend) are discarded.

Transaction Submission Mechanisms

Kasplex L2 supports two methods for submitting transactions, each with distinct implications:

Canonical Submission: Transactions are submitted directly to Kaspa L1 using a Kaspa-compatible wallet. This approach ensures that no intermediaries are involved, aligning with the decentralization principles of blockchain systems.
Proxied Submission: Transactions are submitted via a relayer, enabling compatibility with EVM-based tools like MetaMask. The relayer forwards the transaction to Kaspa L1, ensuring it is recorded before the L2 processes it. This method prioritizes user convenience but introduces a dependency on the relayer.

The proxied submission mechanism enforces atomicity by requiring all L2 transactions to be anchored on the L1. If a transaction originates on the L2 without an L1 record, the relayer submits it to the L1 for confirmation. This design prevents “native” L2 transactions, which could bypass L1 consensus and introduce security risks. Figure 2 illustrates the two submission paths.

Canonical Path: Wallet → Kaspa L1 → Kasplex L2 .
Proxied Path: MetaMask → Relayer → Kaspa L1 → Kasplex L2.

You may notice the transaction is actually going through the L1 first then interpreted by the L2 indexer. That is exactly how Kasplex L2 works, where the L1 finalises the data, before the L2 reads the transaction then transits the state.

Comparing Kasplex L2 with Bitcoin Inscriptions

To contextualize Kasplex L2, it’s useful to compare it with Bitcoin Inscriptions, specifically BRC-20, a popular mechanism for token issuance on Bitcoin. Both systems aim to extend the functionality of UTXO-based blockchains by leveraging the L1 for data storage and ordering, but they differ in their implementation and goals.

Similarities

Data Embedding in L1: Both Kasplex L2 and BRC-20 embed data in L1 transactions. BRC-20 uses Bitcoin’s Tapscript (enabled by the SegWit upgrade) to store token metadata, typically through a three-step process: commit (hash of the data), reveal (the data itself), and spend (token transfer). Kasplex L2 embeds EVM bytecode in the payload of Kaspa L1 transactions, achieving a similar goal of anchoring L2 operations to the L1.

L1 as the Source of Truth: In both cases, the L1 provides the canonical ordering of operations. BRC-20 relies on Bitcoin’s blockchain to sequence token transfers, while Kasplex L2 uses Kaspa’s BlockDAG to order smart contract executions.

Indexer Dependency: Both systems depend on off-chain indexers for processing. BRC-20 indexers parse Bitcoin transactions to track token balances, while Kasplex L2’s indexer executes EVM bytecode to maintain smart contract states.

Differences

Implementation Efficiency: BRC-20’s three-step process is a workaround for Bitcoin’s rigid protocol, which was not designed to support L2 operations. Kasplex L2 benefits from Kaspa’s more cooperative L1, allowing data to be embedded in a single transaction payload, reducing complexity and overhead.

Performance Considerations: Bitcoin’s throughput is limited to approximately 7 TPS, with blocks produced every 10 minutes on average, making Inscriptions slow and costly. Kaspa’s 10 BPS upgrade provides a significant performance advantage, enabling Kasplex L2 to handle higher transaction volumes more efficiently.

Scope and Functionality: BRC-20 is narrowly focused on token issuance and transfers, whereas Kasplex L2 supports full EVM compatibility, allowing for complex smart contracts such as DeFi protocols or NFT marketplaces.

Protocol Flexibility: Bitcoin’s conservative design prioritizes immutability, requiring L2 solutions to work around its constraints. Kaspa’s L1, while still a UTXO system, is more flexible, enabling tighter integration with L2 solutions like Kasplex.

This comparison highlights a key insight: while the conceptual approach of using the L1 for data and sequencing is shared, Kasplex L2 leverages Kaspa’s architectural advantages to achieve greater efficiency and broader functionality compared to Bitcoin Inscriptions.

Evaluating Kasplex L2: Strengths and Limitations

From a technical research perspective, Kasplex L2 presents several notable strengths and limitations, which we evaluate below.

Strengths

Functional Expansion: Kasplex L2 successfully extends Kaspa’s capabilities by enabling EVM-compatible smart contracts, supporting use cases such as decentralized applications and tokenization that are otherwise infeasible on the L1.

Efficient Use of L1: By relying on Kaspa’s BlockDAG for sequencing and data availability, Kasplex L2 minimizes the computational burden on the L2, focusing solely on execution. This design aligns well with Kaspa’s high-throughput architecture.

Public Verifiability: Since all transactions are recorded on the L1, the execution of smart contracts on Kasplex L2 can be independently verified by re-running the EVM bytecode in the canonical order, ensuring transparency.

Limitations and Risks

Indexer Trust: The L2’s indexer plays a critical role in executing bytecode and maintaining state. However, there is a risk of indexer misbehavior, such as presenting an incorrect state (e.g., a falsified Merkle root) while maintaining a separate, hidden state. Mitigating this requires a decentralized indexer network, potentially with economic incentives or penalties, which has not yet been implemented.

Reorganization Challenges: Kaspa’s BlockDAG, while efficient, is susceptible to reorganizations in recent blocks due to its parallel block production. This can force the L2 to revert and re-execute transactions, introducing complexity.

Implications for UTXO-Based Blockchains

Kasplex L2 offers a case study in scaling programmability for UTXO-based blockchains, with potential lessons for systems like Bitcoin. Both Kaspa and Bitcoin face similar constraints in supporting smart contracts due to their UTXO models, but Kaspa’s higher throughput and more flexible L1 design provide a more favorable environment for L2 solutions.

For Bitcoin, Kasplex L2’s design suggests several areas of exploration:

Relayer Integration: The proxied submission mechanism demonstrates how EVM-compatible tools can be integrated with a UTXO blockchain, a concept that could be adapted for Bitcoin L2 solutions like BitVM.

Indexer-Based Execution: The use of an indexer to execute off-chain computations while anchoring data on the L1 aligns with Bitcoin’s Inscription model and could inspire new approaches to scaling programmability.

From a research perspective, Kasplex L2 serves as a valuable experiment, demonstrating how architectural differences between UTXO blockchains (e.g., throughput, protocol flexibility) impact the feasibility of L2 solutions. Its findings can inform the design of scaling solutions across the blockchain ecosystem, particularly for systems prioritizing decentralization and security over native programmability.

Conclusion

Kasplex L2 is a technically sound implementation of a based rollup, enabling EVM-compatible smart contracts on Kaspa by leveraging its L1 for sequencing and data availability. Our analysis highlights its efficiency in utilizing Kaspa’s high-throughput BlockDAG, as well as its ability to extend functionality through EVM compatibility. We view Kasplex L2 as a significant contribution to the study of L2 solutions for UTXO-based blockchains. Its comparison with Bitcoin Inscriptions reveals both shared principles and the impact of L1 design on L2 feasibility. For researchers and developers, Kasplex L2 offers a lens through which to explore the intersection of scalability, programmability, and decentralization in blockchain systems

Reference

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

A big shout-out to our researcher @ZorrotChen. Thank you for contributing to this article!