KASmedia recently sat down with the team behind Igra Labs, primarily Pavel and Dennis. We wanted this interview to cover the overall future of L2 scaling, not just for Kaspa but for proof-of-work in general, particularly Bitcoin. First, we cover core Bitcoin scaling issues with the possible future of Bitcoin BIP-420 or OP_CAT and how Bitcoin L2 scaling might lead to a quasi-fractional reserve system. Moreover, we cover how Kaspa solves Bitcoin’s scaling issues as an ultimate global sequencer system. Lastly, we cover the history of Igra Labs and their technical solutions (via based rollups, zero knowledge proofs, and composability) to a Kaspa L2 future. 

Nicholas: Thank you, Pavel and Dennis, for taking the time to answer some important questions regarding Bitcoin’s scaling hurdles and Kaspa’s L2 future. I would like to start the interview by discussing Bitcoin’s possible L2 solutions and how they might compare to Kaspa.

Starknet recently announced its L2 support for Bitcoin as an execution layer via BitVM and a Federated (multisig) model. Starknet will also be integrated through the Lightning Network. Can you explain the pros and cons of Starknet’s support? Will this create further centralization and key-man risks for Bitcoin?

Pavel and Dennis: First of all, this is a very positive development, as it’s about time EVM L2s start improving their security models. Bitcoin's security and degree of decentralization remain unmatched, so settling there is definitely an improvement. 

Essentially, Starknet is building a ZK rollup, batching transactions using their sequencer and sending proofs of these batches to the Bitcoin chain. From a security perspective, using BitVM for trust-minimized bridging is better than standard multisig-based solutions as it requires only one honest operator.

To our knowledge, Starknet still relies on a centralized sequencer, which is common among rollups, because Bitcoin and Ethereum chains aren't performant enough for sequencing. Having a centralized sequencer reduces system security and censorship resistance, so this is an area for improvement. Nevertheless, this represents a positive advancement for the industry.

Nicholas: If I'm not mistaken, there will also be an option to bridge from Bitcoin to Starknet via their federated multisig model, as announced here: https://www.starknet.io/blog/starknet-bitcoin-scaling/

Do you think users will gravitate towards one over the other based on security principles or just go with the cheaper route? It seems like Starknet's bridge would be cheaper. Any other thoughts on this?

Pavel: It's up to users I think. There are always trade-offs; those valuing decentralization and security may opt for the BitVM bridge, for lower fees and ease of use might prefer the federated multisig bridge.

Nicholas: What are the pros and cons of enabling OP_CAT, i.e., Bitcoin BIP-420?

Pavel and Dennis: First, we invite readers to explore BIP-420. It's a top-notch drama involving both technical and political aspects, showing in concentrated form the struggles the Bitcoin ecosystem faces.

Short version: OP_CAT, which at first sight simply enables two stack elements to be concatenated, can with some computational magic be used for complex calculations, transaction introspection, and Merkle Root verification. This unlocks numerous use cases, including covenants, generic programmability on Bitcoin, and verification of ZK proofs.

The challenge lies in predicting specific side effects of this opcode. Computations could become resource-intensive and overload the chain, effectively stalling it. A key argument against implementation is that Satoshi himself removed it 15 years ago, raising concerns about inherent risks. And now, with the US government holding Bitcoin reserves, we doubt significant code changes would receive support from major stakeholders.

Nicholas: Are there issues with using Bitcoin as a data availability layer? If so, what are they?

Pavel and Dennis: It was never designed as such. Bitcoin's low throughput, small blocks, slow finality, and peak-time fee spikes make Bitcoin a poor fit for DA compared to specialized solutions like Celestia.

If we dig a little deeper into DA tradeoffs, if you move DA off Ethereum, you’re betting your security on a much smaller, newer network.  If they get attacked or censored, you could lose access to your data, even if your settlement layer (like Ethereum) is fine.

Kaspa takes a very different approach. It uses pure Proof-of-Work in a BlockDAG structure, so data availability and settlement happen together, without depending on a separate network.

Pros: stronger censorship resistance, no reliance on another validator set, fast finality.

Cons: storing all transaction data on-chain means node storage grows faster over time and requires smart pruning solutions. 

Nicholas: Currently, all rollup L2s utilize a centralized sequencing model, requiring the trust of one single node to validate transactions. L2s with centralized sequencers include Starknet, Optimism, Abritrum One, Base, zkSync Era, Linea, Polygon zkEVM, and Scroll. However, many of these companies are conducting research to implement decentralized sequencers or shared sequencer models.

If L2s successfully decentralize their sequencer models, do you consider this a threat to Kaspa? For example, if OP_CAT is enabled and L2s can offer decentralized sequencing, why not use Bitcoin with an L2 instead of Kaspa with an L2?

Pavel and Dennis: Several significant hurdles exist:

First, Implementing OP_CAT requires massive coordination from Bitcoin Core developers, facing both technical and political challenges.

Secondly, even with OP_CAT, ZK verification would still be very costly on Bitcoin.

Third, Bitcoin’s DA limitations would still require major performance improvements.

Lastly, Bitcoin won’t be fast enough to sequence every transaction, meaning L2s would still require off-chain sequencing and batching, reintroducing centralized risks.

Since Bitcoin can’t handle sequencing, L2s will need their own decentralized sequencers — mini-chains sitting between users and Bitcoin itself.

Nicholas: Could you expand on this more? Does this mean L2s to further sequence L2s (L2s all the way down)? Or maybe fractional reserve methods from centralized custodians/banks? I'm extremely curious about this. 

Also, any chance you could go into the basic technical details on how L2s still face scalability hurdles with Bitcoin's base layer sequencing? 

Pavel and Dennis: At some point, you do risk recursion — "L2s on L2s" — stacking layers to patch previous weaknesses. This adds latency, complexity, and new centralization risks at every level.

It’s very similar to how fractional reserve banking evolved. The base layer (gold) was slow and costly to move, so banks created IOUs (paper money), leading to layered financial systems like loans, derivatives, etc.

And common standards would require major social coordination among L2 teams — something we’re skeptical about.

Currently, the Ethereum community leans toward specialized sequencers like Espresso. But these specialized sequencers have decentralization and security levels far below Ethereum or Bitcoin L1 — and they’re still years away from reaching comparable decentralization.

Nicholas: Can L2s solve the blockchain trilemma for Bitcoin?

L2s can improve Bitcoin scalability to a degree. However, if an L2 doesn’t sequence on the base layer, its decentralization drops.We trust the Starkware team to minimize security tradeoffs, and we’ll be closely monitoring developments here. 

Nicholas: How about transaction batching - can Bitcoin scale L2 batching? Will L2 batching congest Bitcoin?

Pavel and Dennis: Not at real scale.

Even batching thousands of transactions, Bitcoin’s 1MB blocks every 10 minutes cap throughput at just 7–10 transactions per second. If many L2s try to settle proofs, Bitcoin blockspace would become ultra-scarce — driving fees up and delaying settlements.

Bitcoin won’t be able to sequence or settle serious L2 activity without massive congestion or new centralization risks.

Nicholas: What do you think about Kaspa solving the L2 centralizing problem if OP_CAT is enabled? For example, Kaspa could serve as a side-chain sequencer for Bitcoin (I.e., a middleman between Bitcoin and other L2s) to merge the best of both worlds - all of the world’s hash power with the abstract realm of DeFi. Moreover, Kaspa could provide PoW security and MEV protection to PoS settlement layers, such as Ethereum.

Are these efforts worth pursuing? Or should Kaspa focus only on its own development? 

Pavel and Dennis: Ironically, by focusing purely on its own development, Kaspa may naturally become that: an ultimate performance sequencer with Bitcoin-grade security, helping overcome the hard constraints of Ethereum L2s.

One possible design is to use Kaspa’s BlockDAG as a sequencer — achieving scalable 5,000 TPS with sub-second probabilistic finality — while settling on a base layer with ZK verification support, inheriting its security. This is already possible today with Ethereum.

Igra aims to do exactly this: using Kaspa as a sequencer and settling L2 transactions as ZK proofs on Ethereum, combining Ethereum’s security with BlockDAG’s.

From a product perspective, this enables a canonical bridge from Ethereum assets to Igra, improving economic interoperability and user experience.

A History of Igra Labs and its L2 Technology

Nicholas: Give us a short history of Igra Labs: How did you meet? What are your backgrounds? Why the name Igra Labs? Why did you decide to work on Kaspa compared to other L1s?

Pavel and Dennis: We're all crypto veterans with engineering backgrounds who've built distributed, high-load systems. We've all led teams and built products end-to-end. We've been in the DLT industry since around 2016.

Denis and Mike worked at DAGLabs, which delivered Kaspa’s BlockDAG. Pavel co-founded several companies in the Ethereum ecosystem. Roman, our tech advisor, is Kaspa’s core ZK architect. Maya, our strategy advisor, led ZK applications with financial institutions and global crypto policy.

Last summer, Denis realized that Kaspa’s BlockDAG roadmap, with 10BPS and ZK opcode support could finally enable a new type of programmable layer. He brought in Pavel and Maya, and Igra Labs was born.

The name "Igra" has a dual meaning — in Aramaic, it means "Rooftop," fitting for an L2; in many Slavic languages, it means "Game" or "Play."

Many of us are musicians: Denis graduated from Musrara, the well-known school for new music studies, and Mike Zak is an accomplished classical composer, so the element of play is vital in our work.

Kaspa’s BlockDAG is currently the only L1 offering fast, secure sequencing. We compared several BlockDAGs and technologies like HotShot and Lachesis, but none match GhostDAG’s leaderless design and >33% adversary tolerance.

We especially appreciate Kaspa’s core team’s transparency and professionalism, including fully open-sourced code, open Discord and Telegram communities, easy for anyone to get involved. This aligns perfectly with the crypto builder ethos we respect.

Nicholas: Igra Labs is a Kaspa L2 that utilizes Based ZK rollups and atomic composability. Can you explain Based ZK rollups and synchronous atomic composability for our beginner readers? Moreover, how does atomic composability allow for interoperability between any type of VM? Can you explain the basic technology behind this?

Pavel and Dennis: For based rollups, we invite readers to check out our article: https://x.com/Igra_Labs/status/1898368135767494965.

In short, a based rollup is a system that uses another blockchain as a sequencer to derive liveness and security from it. A based ZK rollup, in addition to sequencing, periodically posts proofs of rollup state changes to the base layer, enabling canonical exit from rollup to the base layer and light clients (nodes with pruned state).

Atomic composability is an extremely important concept in smart contract platforms. It's the ability to execute multiple operations across separate smart contracts in a single transaction, atomically, without the risk of partial failure. In Ethereum, for example, we take for granted that several contract calls can be composed as one. However, Ethereum EVM is constrained by gas limits and can hardly scale.

Yonathan Sompolinsky's research suggests that if an L2 uses Kaspa BlockDAG as a sequencer, regardless of the VM used to build a specific smart contract, it can invoke and compose contracts written in other languages. Even more, different L2s on the same sequencer can interoperate. This can finally make a scalable world distributed computer—the vision behind Ethereum—possible.

Further materials: 

In which we’ll bе reduced to a spectrum of gray* | by Yonatan Sompolinsky

https://research.kas.pa/t/atomic-composability-and-other-considerations-for-l1-l2-support/193

Nicholas. Thank you for the additional resources. You mention how Igra Labs will create a Solana-like unified defragmented state on your site. Can you explain what you mean by this?

Pavel and Dennis: We're envisioning a unified token standard that can be shared across all L2s. Unlike smart contracts, which don't make sense to implement at the Layer 1 level, a token standard can be established using L1 payloads and opcodes and then utilized by L2s. This creates a unified state similar to Solana’s asset layer, where all tokens follow the same standard across all L2s.

In Solana, there’s one unified SPL Token Program everyone integrates with. We envision the same thing for Igra and other L2s built over Kaspa, using the same token definitions directly with no fragmentation.

As for bridging:

• L1 acts as the source of truth for asset states (mint, burn, balances).

• L2s interact with these standardized payloads to lock/mint/burn assets.

• Cross-L2 bridging becomes true state-passing — faster, simpler, and more secure.

Nicholas: How are Based ZK rollups different from zk-STARKS or zk-SNARKS? Also, what kind of zk proof system will Igra use?

Pavel and Dennis: zk-STARKs and zk-SNARKs are cryptographic proof systems used to prove correctness of computation, and a based ZK rollup is an architectural pattern—a way to build your rollup (L2) in which you put proofs of the transactions made onto the base layer. Today, no truly Based ZK rollups exist.

Right now, Igra doesn’t use zk-proofs yet — we’re focused first on scaling, fast settlement, and decentralized sequencing. In the future, we might integrate zk-STARKs or similar systems, but it’s not locked in yet. There are many factors to consider: circuit efficiency, prover time, cost of verification — and importantly, we’ll need to align with whatever zk-proof systems Kaspa’s L1 might support down the line.

Nicholas: In your opinion, why is it important to keep Kaspa's core tech, Layer 1, untouched? Why not integrate applications and smart contracts onto the base layer chain instead (i.e., like Ethereum or Solana)?

Pavel and Dennis: From a technological standpoint, building a VM on Kaspa is definitely possible—all the necessary tech exists. However, Kaspa's core team opted to pursue something bigger and more unique: an ultimate decentralized sequencer.

As Michael Sutton from the Kaspa core team puts it, “...I imagine Kaspa as a ~terabyte/day-magnitude stream of (securely pruned) data mined in consensus by thousands of solo-asics across the globe, providing world-wide linear ordering/conflict resolution and censorship-resistance.”
(https://x.com/MichaelSuttonIL/status/1890198419333083217)

This vision is much bigger and more interesting than building yet another L1. 

On the surface, there's a similar story to Ethereum's roadmap, where Vitalik decided to focus on making Ethereum the best possible infrastructure while delegating monetary value and user experience to L2s. But this was a forced move, as Ethereum lacked proper tech and rollups were the only viable choice. 

Kaspa's core team had options and decided to go with rollups not for scaling, but as a clean separation of concerns between building a world sequencer (what Kaspa will become) and a best-in-class programmable chain (what Igra aims to be). 

Nicholas: One last question: How does Igra Labs further Satoshi's vision of a trustless digital economy?

Satoshi dreamed of a P2P, irreversible, affordable, trustless electronic payment system. Sure, we have DeFi, a parallel financial infrastructure. But we lack throughput comparable to TradFi. We lack fairness, real decentralization, and true censorship resistance.

Satoshi understood the fundamental weakness of trust-based models. 

We believe PoS has inherent, unsolvable problems. Bitcoin was specifically designed as a P2P system without intermediaries. Yet today’s DeFi and programmable chains rely heavily on MEV — extracting value from users.

This is why Igra focuses on scalable high throughput with sub-second finality, while maintaining Bitcoin-grade PoW security. 

By inheriting MEV resilience and atomic composability from Kaspa’s BlockDAG, we empower builders to create unstoppable, real-time, censorship-resistant, and infinitely composable applications — expanding Satoshi’s vision from trustless electronic money into a truly trustless and scalable digital economy.