Kasplex L2: Expanding the Capabilities of UTXO Blockchains with Rollup-Based Smart Contracts

As blockchain technology develops, scalability and programmability remain key challenges, especially for blockchains that adopt the UTXO model.

As blockchain technology develops, scalability and programmability remain key challenges, especially for blockchains that adopt the UTXO model. Kaspa, being a layer-one public blockchain with a BlockDAG structure, manages to achieve 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 integrates 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 a security and research institution. Our goal is to provide a tangible assessment of its design, technical implementation, and its implications for 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 contribute to a broader discussion of scalability solutions for the UTXO model blockchain.

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 difficulties 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 motivated the development of second-layer solutions to expand its capabilities.

Kasplex L2: Rollup-based blockchain for smart contract execution

The Kaspa ecosystem is exploring three Layer 2 (L2) solutions: Sparkle, Igra L2, and Kasplex L2. Among them, Sparkle is still in the theoretical stage, and Igra L2 is still in the development stage. Our analysis will focus on Kasplex L2 because it is the closest to mature implementation so far.

Among the three L2 solutions being explored by the Kaspa ecosystem—Sparkle, Igra L2, and Kasplex L2—Sparkle is still in the theoretical stage, Igra L2 is still in the development stage, and Kasplex L2 is the closest to mature implementation, so this article will focus on analyzing it in detail.

Kasplex L2 is a Rollup-based second-layer scaling solution that relies on the first-level chain for transaction ordering and data availability, 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 performs the task of executing EVM bytecode to realize 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:

1. Transaction submission: A user submits a transaction to the Kaspa primary chain, and the payload of this transaction contains EVM bytecode. For example, this payload may encode a call to the HelloWorld() smart contract function.

2. First-level chain orders transactions: Kaspa's BlockDAG orders these transactions within its DAG structure, providing a deterministic transaction sequence.

3. Layer 2 performs efficient 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

Currently, Kasplex L2 supports two transaction submission methods, each having different effects:

1) 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.

2) 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