Overview

After witnessing the successes and failures of Ethereum’s scaling roadmap, Bitcoin is entering its own era of L2s. Unlike Ethereum, Bitcoin has never increased block sizes (though it has done so indirectly through Segwit) and was designed with an intentionally limited scripting language. This language, Script, was deliberately created as a non-Turing complete system to enhance security and prevent potential vulnerabilities like denial of service attacks. While this design choice restricts complex computations, it provides a secure foundation for basic transaction validation and simple smart contracts. This rigidity in the Bitcoin L1 has led it to embrace scalability through offchain solutions (L2s and sidechains) rather than fundamental protocol changes. This layered approach allows Bitcoin to maintain its core principles of security and decentralization while enabling faster, cheaper, and more programmable transactions through various offchain scaling solutions.

Currently, the Bitcoin L2s landscape has a variety of architectures, namely, sidechains, state channels, client-side validation, and rollups. Among this group, rollups offer the best security guarantees. However, the lack of expressivity in Script has made “trustless rollups” difficult to engineer. This also rings true for Ethereum despite the Turing complete nature of Solidity and years of research and engineering. An Ethereum-based L2 can be classified as a “trustless rollup” only at stage two (according to L2Beat’s naming convention), which no major L2 has yet to achieve. We show L2Beat’s stages for an Ethereum L2 below. 

Given the progress of development thus far and the existing roadmaps, it is expected that many L2s will reach stage two within two years. The same line of thinking exists for Bitcoin L2s, although there is no clear path forward for truly permissionless L2s. This is because even within the rollup architecture, there are two paths - optimistic rollups and validity rollups (less accurately known as zk rollups). 

For Bitcoin-based optimistic rollups, there have been advancements with BitVM and its iterations. However, as we’ve seen with Ethereum-based optimistic rollups, there are significant challenges centered around their fraud-proof systems. The original idea was that having just one honest participant who could challenge invalid transactions would be enough to keep the system secure, with set time periods for these challenges. However, this approach has revealed a significant weakness. Bad actors can exploit the system by continuously submitting invalid state information (resource exhaustion attacks), forcing honest participants to spend their resources challenging each invalid submission until they run out of funds.

This challenge creates a fundamental trilemma between keeping the system secure against attacks (safety), ensuring transactions are processed quickly (promptness), and maintaining a system where many people can participate without needing excessive resources (decentralization). Different projects like Arbitrum, Cartesi, and Optimism have tried to solve this problem in various ways, but each solution requires compromising on at least one of these aspects. A particular challenge is the mandatory 7-day waiting period needed to withdraw funds which can significantly slow down the process of finalizing some transactions. Essentially, Ethereum-based optimistic rollup frameworks are similar to BitVM combined with the Lightning Network (watchtower + peer). 

Fortunately, validity rollups have been heralded as the endgame for L2s and can overcome the limitations of optimistic rollups. Resource exhaustion attacks don't exist under a validity-proof construct, as every full node verifies the work through proofs with no challenge necessary. However, while Ethereum’s programming language has the capability to verify these proofs easily, Bitcoin does not. In order for Bitcoin to easily verify these validity proofs, an additional opcode is needed.

OP_CAT

Bitcoin consensus doesn’t change often, with its last upgrade, Taproot, coming in 2021. However, there have been many discussions about reinstating an opcode known as “OP_CAT” (operation concatenate). Opcodes are instructions that tell the processor what basic operation needs to be carried out. OP_CAT combines two pieces of information (aka concatenate) or it can split larger elements into smaller ones. OP_CAT was previously a part of Bitcoin but was removed by its creator over fears of Denial of Service attacks. If someone keeps sticking together data (using OP_CAT), they can make a script grow incredibly large, potentially exceeding one terabyte. While data size was previously a concern, a 200 opcode limit per transaction was introduced to limit the size. Furthermore, Tapscript's introduction also alleviated this by setting a limit of 520 bytes for each element on the script's stack. So there is now a proposal in the Bitcoin GitHub to turn it back on, but it begs the question, why?

This seemingly simple change would allow developers to create new functions and expand the capabilities of Bitcoin further. For example, “vaults'' with customized rules - e.g., no more than 0.05 BTC can be moved from the vault per day. This can add an extra layer of security if, for instance, one’s private key is compromised. Other possibilities include Lamport Signatures (quantum attack resistant), Non-Equivocation Contracts (prevents double spending in channels), and Replicating CheckSigFromStack (more efficient transactions).

Perhaps most significantly, it would provide a general-purpose way to concatenate stack values to allow the construction and evaluation of complex data structures, such as Merkle trees and hashed structures, within Tapscript. This would allow for permissionless bridges that could move Bitcoin assets (BTC, ordinals, runes, etc.) onto L2 chains through the use of validity proofs. Validity proofs often rely on verifying Merkle tree paths and combining data elements, which requires concatenating stack elements. With OP_CAT, the part of validity proof computation related to Merkle trees can be performed directly on the Bitcoin script by concatenating stack elements. This would allow L2s to be secured by the Bitcoin network directly and potentially allow for trustless withdrawals from an L2 to the Bitcoin L1.

It should be noted that there are alternative opcodes being discussed though OP_CAT has the community’s mindshare at the moment. 

Starknet’s role

Starknet employs a robust computational model built on STARKs (Scalable Transparent ARguments of Knowledge), which are a type of zk proof. At its core, the system converts program execution into polynomial constraints, allowing for the verification of complex computations without revealing the underlying data. The Cairo programming language serves as the foundation, translating high-level logic into algebraic intermediate representations that can be efficiently proven. STARKs achieve their scalability through the use of Fast Reed-Solomon Interactive Oracle Proofs (FRI), which enables logarithmic verification time while maintaining computational soundness. This architecture allows Starknet to process ~1K transactions per second while inheriting the security guarantees of the L1, though the proof generation process requires significant computational resources.

As mentioned earlier, this performance and security are made possible by Starknet’s custom language, Cairo. Cairo is a high-level programming language specifically designed for writing provable programs and smart contracts on StarkNet, featuring Rust-like syntax and built-in support for zk proofs. Cairo has been used for years in Starknet and Starkex chains, making it relatively battle-tested. This is where Shinigami plays an important role. 

Shinigami represents a significant improvement in Bitcoin transaction compression and verification. By implementing a Bitcoin Script VM in Cairo, Shinigami enables the generation of validity proofs that can verify hundreds of thousands of transactions. It achieves this by employing several compression techniques: replacing transaction IDs with block height and index references, using variable-length integers instead of fixed 4-byte values for transaction data, and reconstructing public keys from signatures rather than including them directly. It should be noted that Starknet already does this for the EVM with Kakarot, highlighting the performant capabilities of Cairo and Starknet. 

 

What’s more, with Shinigami, verification of proofs allows for fast and secure initial block downloads (IBD). Traditionally, starting a Bitcoin full node requires running all transactions from genesis up to the current state to verify the current state trustlessly. As shown in the image below, verifying validity proofs makes it possible to instantly know that all the consensus & execution rules were followed and that the latest state corresponds with the one on the Bitcoin mainnet. This would make “syncing” a full node logarithmically faster than what’s possible today. The only inputs needed are the blocks, proof of the previous chain state, and “utreexo” proofs. Utreexo proofs are a clever innovation that allows Bitcoin nodes to verify transactions without storing the entire UTXO (Unspent Transaction Output) set. Instead of keeping track of all unspent outputs, nodes only maintain a small cryptographic accumulator, while users provide compact proofs (under 1KB) that their coins exist. This system significantly reduces storage requirements for Bitcoin nodes while maintaining the same security guarantees, effectively replacing expensive disk storage operations with efficient hash computations.

 

These proofs can also be used to create zk clients nested in chains to facilitate bridging. The STARK proof of chain state n can be passed to an onchain STARK verifier and the L1/L2 can use this to update the bridge’s state. Shinigami and hence IBD and zk clients are all possible without OP_CAT. It should be noted that Shinigami is used for Bitcoin script verification, whereas Starkware’s Raito aims to verify Bitcoin consensus.   

On Ethereum, L2s provide scalability; with OP_CAT enabled, smart contracts on Bitcoin L2s will also gain scalability and unprecedented expressivity through Starknet's infrastructure, enabling complex financial applications. This includes BTC-backed stablecoins, private payments, and the advanced DeFi protocols seen on other chains, all while maintaining Bitcoin's security guarantees. This enhanced functionality doesn't require users to trust intermediaries, as the STARK proofs allow for verifying computation integrity directly on Bitcoin's base layer. Privacy-preserving computations represent another transformative advancement for Bitcoin's ecosystem. Through zk proofs (vs validity proofs), users can execute confidential transactions and complex computations without revealing sensitive details about transaction amounts, wallet balances, or computational inputs. These advancements would be particularly significant for institutional adoption, as they enable compliance with regulatory requirements while preserving the confidentiality of sensitive business operations. 

Just as seen on Ethereum, the L2 (like Starknet) is responsible for execution while the L1 (like Bitcoin) is responsible for settlement. However, in the future Starknet intends to differ in a couple of ways. Firstly, Starknet is introducing staking to its network using a phased approach. Initially, validators will focus on running full nodes and testing the economic incentives and smart contract components. By the time validators assume their complete role in producing, attesting, and proving blocks, there will be an established group of sequencers with proven reliability in block production and attestation. This means that Starknet will be responsible for its own consensus through its own validator set. This is important if Starknet wants to become an execution layer for multiple L1s, but it does add an additional trust assumption (honest majority of the new validator set). Secondly, unlike Ethereum Blobs, Bitcoin does not have a separate market for data availability. This means that DA on Bitcoin can become materially expensive during periods of high congestion, even on an L2. Fortunately, there is a novel solution for this that retains the scaling benefits of offchain data availability, while removing all trust assumptions for any willing user.

Adamantium

Adamantium is an interactive DA solution that builds upon the foundation of a Validium while eliminating its core trust requirements. The protocol introduces a novel approach to data availability that preserves scaling benefits while offering users complete autonomy over their funds. At its core, Validium relies on a Data Availability Committee (DAC) composed of reputable blockchain entities who maintain offchain copies of account balances and attest to state availability by signing Merkle roots after batch processing. While functional, this system requires users to trust DAC members, particularly during withdrawal scenarios where operator censorship might occur.

Adamantium resolves this trust dependency by introducing the concept of Power Users (PUs). These participants operate in a fully trustless manner by maintaining direct custody of their funds through regular cryptographic signatures confirming access to their offchain data. If a Power User fails to provide timely signatures, their funds automatically return to Layer 1 through a mechanism called Protective Withdrawal – the protocol's key innovation. The protocol offers flexibility in user participation. Regular users aren't forced to become Power Users. Instead, they can choose between continuing to trust the DAC, becoming Power Users themselves, or following one or more Power Users who act as watchtowers (a similar role to those used for the Lightning Network). This follower system allows users to delegate trust to multiple PUs, reducing the risk of service disruption while maintaining security.

Power Users must meet specific technical and financial requirements. They need to maintain a consistent online presence and respond to signature requests within minutes. The system includes economic incentives, as PUs can offer watchtower services to followers for a fee. 

The Protective Withdrawal mechanism ensures system security by automatically moving funds to Layer 1 when required. This process is optimized through transaction batching, with operators only paying gas fees for users who go offline during a given cycle. This design creates a balanced system where operators have incentives to maintain service quality, as repeated unwarranted withdrawals would likely cause users to switch to competing applications.

Through this comprehensive design, Adamantium achieves a remarkable balance between scalability, security, and user autonomy. It demonstrates how L2 solutions can evolve to eliminate trust requirements while maintaining their fundamental scaling benefits.

 

It should be noted that Adamantium isn’t currently a live solution and is still undergoing research and development.

Challenges

The implementation of OP_CAT on Bitcoin represents a significant yet technically manageable change to the protocol. The proposal, now formally known as BIP-347, would be implemented through a soft fork, ensuring backward compatibility with existing Bitcoin software. This approach is particularly important as it prevents network fragmentation and allows older versions of Bitcoin to continue operating without disruption. The actual code change is relatively straightforward, involving only a few lines of code to reactivate the opcode. However, the simplicity of the code belies the complexity of its implications. The implementation would require extensive testing and validation to ensure network stability. Node operators would need to update their software to support the new functionality, though the impact on node operations is expected to be minimal due to the soft fork approach. 

Furthermore, historical concerns about DoS attacks and exponential memory requirements that led to its original removal in 2010 have been carefully addressed. Introducing Taproot's limited stack size has helped address the DoS vulnerabilities. While advancements in Bitcoin's technology have mitigated these original concerns, new potential attack vectors including MEV, need thorough examination. 

Lastly, achieving network consensus presents perhaps the most significant hurdle. As exciting as these potential OP_CAT-enabled rollups seem, Bitcoin is a slow-moving, semi-ossified ecosystem. The Bitcoin community is known for its cautious approach to protocol changes, prioritizing security and stability. There is no formal or standardized process for adding opcodes or creating soft forks on Bitcoin, a process that takes years (at best). This includes years of deliberation and community awareness, then more time for nodes to opt into running it, and then years for developers to start widely using them before the first true Bitcoin L2 is live. The offchain governance is by design, so soft forks on Bitcoin aren’t taken lightly. The final architecture will depend on the combination of opcodes implemented and the security considerations involved. To bring back OP_CAT it is likely that:

1. it would only be activated in Tapscript;
2. activation would use OP_SUCCESS for a soft fork, and
3. it would utilize the same opcode as the original.

Similarly, on the Ethereum side, it’s been over 4 years since Vitalik first wrote about Ethereum’s rollup-centric roadmap and the end game still doesn’t seem close. This is not an insult to either ecosystem but rather a result of the nature of the world’s most decentralized projects protecting what’s at stake.

Alternatives

It should be noted that there exists an alternative theoretical approach to implementing Bitcoin covenants without requiring protocol changes. This method, known as ColliderScript, leverages 160-bit hash collisions to enable covenant functionality within Bitcoin's existing framework, though current implementation costs are estimated to be millions of dollars per transaction due to intensive computational requirements. This novel approach was created by a group of four researchers including two from Starkware. While practically challenging in its present form, ColliderScript's methodology proves that covenants are technically feasible on Bitcoin today, with the potential for significant optimization through improved hardware and algorithms. Drawing parallels to BitVM's evolution from costly prototype to practical solution, ColliderScript demonstrates how grassroots experimentation can advance Bitcoin's development ecosystem, regardless of whether it achieves mainstream adoption.

Bitcoin PIPEs (Polynomial Inner Product Encryption) represent another approach to implementing covenants and advanced spending rules without requiring soft forks or protocol changes. PIPEs enhance Bitcoin's functionality by emulating missing opcodes, facilitating validity proofs, and supporting efficient batch transactions. PIPEs operate on a 1/N trust assumption, meaning the system remains secure and functional as long as at least one participant out of many behaves honestly - however, a trusted setup is required. There is also considerable complexity in the underlying cryptography and offchain processing of encrypted transaction signing keys.

Looking Forward

The future of Bitcoin's Layer 2 scaling solutions stands at a pivotal juncture, with the potential reintroduction of OP_CAT serving as a catalyst for revolutionary developments. The combination of Starkware’s proven STARK-based infrastructure and OP_CAT could transform Bitcoin's capabilities, enabling private payments, bridging, and DeFi at scale while maintaining core security principles. While the implementation timeline remains uncertain due to Bitcoin's characteristically cautious approach to protocol changes, the groundwork being laid through proposals like BIP-347 and innovative solutions like Adamantium suggests a thoughtful evolution toward more scalable, secure, and feature-rich Bitcoin applications. The journey ahead may be gradual, but it represents a careful balance between technological advancement and the preservation of Bitcoin's and Starkware’s fundamental values.
 

 

 

The information contained in this report and by Blockworks Inc. and related affiliates is for general informational purposes only and is not intended to provide legal, financial, or investment advice. The report should not be construed as an offer or solicitation to buy or sell any security, token, or financial instrument and does not represent any recommendation or endorsement of any investment or financial product or service. Blockworks Inc. and related affiliates are not registered as a securities broker-dealer or an investment advisor in any jurisdiction or country.