Bitcoin has crossed multiple important bridges over the past few years. 

Each has marked a significant technological and cultural evolution in both the network and the asset, expanding the properties and possibilities of Bitcoin.

Today, the world’s first blockchain stands ready to cross another significant bridge—unlocking a new era of scalability and expressiveness.

This piece will explore the bridges Bitcoin has crossed to reach this point and those still ahead.

‍

Bridge #1: Austerity → Abundance

From earning my first salary to lending, borrowing, and "making markets" on Uniswap, Ethereum offered me a platter of playful applications right from the start of my journey. As a result, my introduction to crypto entirely bypassed Bitcoin, which I always saw as a monastery intent on maintaining its austere simplicity.

However, I cautiously armed myself with an Xverse wallet (not affiliated, just a great Bitcoin wallet) earlier this year and crossed the bridge to Bitcoin. 

While I expected pretty barren lands, the journey has been filled with adventure: trading animal coins with local merchants, arduously trekking into Stacks, attending sermons led by Ordinals priests on Twitter, and engaging in fierce MEV battles in the mempool.

Traveling across the Bitcoin ecosystem feels like hopping between huts, all under construction and nested within an inhospitable environment. Inside the huts, travelers bond over their esoteric experiences. On any given day, you might find a group reminiscing about their quest for a rare Ordinal tied to a satoshi issued right after this season's difficulty adjustment. Many likely lost their prized possessions to cunning snipers from above. Others gossip about the introduction of new token standards by powerful factions, speculating on their likelihood of earning the allegiance of BRC-20 whale lords that control trade routes out East. The buzz is palpable, and the conversations are strange but exciting.

Outside, the land is often desolate, and the routes across it are slow and confusing. There's no signage, no cars, but quite a few people looking to sell some suspicious-looking snake oil. Yet, these historic and precious grounds are attracting a rapidly growing wave of travelers and entrepreneurs who are set to lead Bitcoin into a new industrial age. Bitcoin’s bridges are still being built, but the excitement of being early continues to fuel crypto's most significant inflection points. For the entrepreneurs leading the charge, this feels like the dawn of another one of those junctures.

‍

Bridge #2: Taproot → Tokens

Much of Bitcoin’s most recent evolution can be pinpointed back to two critical infrastructure upgrades—SegWit and Taproot. Through these upgrades, the Bitcoin community constructed and crossed a bridge that enabled inscriptions and, eventually, tokens.

Inscriptions are arbitrary data embedded within Bitcoin transactions, stored in the witness data field, and linked to individual satoshis (the smallest units of Bitcoin) spent in a particular UTXO (unspent transaction output). 

SegWit was a critical enabler of inscriptions, as it introduced the witness data field, a separate area within Bitcoin transactions where additional data could be stored without increasing the block size. This separation allowed for the inclusion of extra data in transactions while preserving the blockchain's efficiency.

The Taproot upgrade, which included the implementation of Tapscript, removed the previous 10,000-byte limit on script size, enabling up to 4MB of data to be embedded within a single transaction. This made it feasible to inscribe substantial amounts of data onto individual satoshis, creating what we know now as inscriptions.

With inscriptions in place, the only remaining requirement for creating tokens on Bitcoin was a standardized method for creating and tracking them. Ordinals quickly became one of the most popular ways to do so. 

Ordinals is a protocol for assigning unique identifiers to individual satoshis based on their issuance order, from satoshi 0 in the genesis block to satoshi 2.1 quadrillion (representing the total supply of 21 million bitcoins with 100 million satoshis per bitcoin). Ordinals achieve this by using a specific script sequence—OP_FALSE, OP_IF, and OP_PUSH—to embed data in a transaction without executing it as a script. This data is then associated with a satoshi spent in a particular UTXO, enabling the creation and transfer of inscribed satoshis.

Built on top of Ordinals, the BRC-20 protocol uses inscriptions to create, define, and manage semi-fungible tokens. A BRC-20 token is deployed by submitting a transaction with an inscription that defines its properties, such as protocol name (BRC-20), operation (deploy), ticker symbol, maximum supply, and mint limits. Minting new tokens involves creating inscriptions to update the token supply in subsequent transactions. Transferring tokens adjusts balances, generates new UTXOs for recipients, and updates the ledger by modifying the metadata linked to the satoshis involved.

An alternative approach, the Runes protocol, uses OP_RETURN outputs for token creation. This method can store up to 80 bytes of arbitrary data without executing it as a script, preventing UTXO bloat since OP_RETURN outputs don't create spendable UTXOs. Runes manage token operations through messages stored in transaction outputs, with minting and transferring following predefined rules encoded in these outputs.

Like on Ethereum, Bitcoin citizens fight and gossip about their favorite standards and their relative adoption, and the complexity of the discussion is magnified by the historical alliances and allegiances of miners, purists, tourists, and exchanges. Tokens on Bitcoin exist in ways that significantly defy one’s understanding of tokens from Ethereum. 

Still, their unique nature has resulted in several exciting and esoteric patterns for trading Bitcoin-native assets based on their inherent value. Today, you can create Ordinals associated with specific historical moments—from inscribing a sat associated with the first "Bitcoin pizza" transaction to minting a memecoin on top of the last satoshi mined by Satoshi. For example, EPIC•EPIC•EPIC•EPIC is the first rune inscribed on an epic satoshi, an extremely rare satoshi generated during Bitcoin halvings, bought this April for 33.3 BTC. Only four epic sats exist, with 34 to be released via future halvings.

‍

Bridge #3: Data → Programs

Taproot enabled tokenization, but Bitcoin holders don’t just want new ways to speculate; they want programs to use their existing Bitcoin more expressively. In that ideal world, users can unilaterally redeem their IOUs on L2s for mainchain sats, while guarantees around redemption are enforced by mainchain consensus rules (meaning users can always transact on Bitcoin to get their money out). 

Conveniently, tokens are just one of the many pieces of data that can be embedded into a Bitcoin inscription. From this standpoint, Ordinals are just a particular type of sovereign rollup built on Bitcoin—but other types of sovereign rollups can extend our ability to reach consensus on a token’s supply and distribution to the state of different blockchains. 

A quick refresher on sovereign rollups—they’re a type of rollup that uses a layer 1 blockchain for data availability (DA) but not for settlement. Nodes in a sovereign rollup verify if state changes are correct, then can verify that execution was done correctly by reading an inscription of a validity proof containing a state change on Bitcoin’s DA layer.

Still, sovereign rollups only solve part of the problem. They can inherit the re-org resistance of Bitcoin, as well as Bitcoin’s censorship resistance and data availability. However, because there is no way to write a node (or a verifier for its circuit-based form) for the sovereign rollup on Bitcoin, the liveness and safety of native Bitcoin cannot be guaranteed. Suppose a Bitcoin user wants to use their Bitcoin to take a loan or pay on a sovereign rollup application. In that case, the Bitcoin nodes cannot verify that state transitions have happened correctly, meaning there is no way to decide how to honor withdrawals unilaterally.

Still, we can use Bitcoin’s properties as a DA layer to improve the trust-minimization properties of existing bridges by leveraging BitVM—a system to expand Bitcoin's computational capabilities. 

BitVM enables computation that extends Bitcoin’s limited scripting capabilities while minimizing the additional trust assumptions Bitcoin users need to make. 

At the core of BitVM are bit-value commitments, where a prover commits to a binary value (0 or 1) without revealing it immediately. These commitments are integrated into Boolean circuits, which carry out logical operations offchain. The results of these computations are securely linked to Bitcoin’s blockchain through Taproot's Taptree, a specialized Merkle tree structure that provides efficient, private data storage with minimal onchain impact.

To ensure the integrity of these offchain computations, BitVM utilizes a challenge-response protocol. If a dispute arises, a verifier can challenge the prover to disclose specific parts of the computation by revealing the relevant leaves in the Taptree. If the disclosed information matches the prover's original commitments, the computation is validated; if not, a fraud-proof is generated, resulting in penalties for dishonest behavior.

Building on the principles of BitVM, Citrea developed Clementine, a trust-minimized system designed to enable secure cross-chain transfers between Bitcoin and Citrea, a ZK rollup on BItcoin. Traditional Bitcoin bridges typically require locking BTC into multi-signature contracts, which introduce significant trust and liquidity risks. Clementine mitigates these issues by leveraging BitVM’s challenge-response mechanism, eliminating the need for trusted intermediaries.

Clementine’s security framework relies on Connector UTXOs and Connector UTXO Trees which govern the bridge operator’s access to Bitcoin funds and ensure the proper processing of withdrawals. The operator fronts Bitcoin from their reserves to process withdrawals on Citrea and subsequently publishes a corresponding preimage on the blockchain. These preimages are stored within the Connector UTXO Tree, a binary structure that controls access to these funds. Each node in the tree offers two paths: one allows the operator to reclaim Bitcoin after a 7-day timelock, and the other permits anyone with the correct preimage to spend the UTXO. 

If a verifier suspects dishonesty, they can challenge the operator by submitting the relevant Bitcoin block header and cumulative PoW. The operator must prove that their PoW exceeds the verifier’s, ensuring that all transactions were processed correctly. If the verifier’s challenge is valid, the operator must also provide zero-knowledge proofs (ZKPs) to confirm the correct processing of withdrawals and reveal the corresponding preimages. Failure to do so allows the verifier to burn the Connector UTXO, thereby preventing the operator from accessing the funds and protecting the system from potential fraud. If the operator fails to meet these conditions, the Connector UTXO is burned, revoking the operator's access to the funds and enforcing honest behavior.

While Clementine offers significant security improvements, its reliance on BitVM introduces the need for a bridge operator to take on liquidity risks. A key disadvantage of BitVM-based bridges is that, unlike Ethereum’s rollup bridges, users’ withdrawals do not directly come from deposits. Operators must maintain sufficient liquid Bitcoin to cover all withdrawal requests before they can reclaim any funds. This requirement can create liquidity challenges, especially during high withdrawal demand. To manage these risks, careful consideration must be given to the design of BitVM-based systems, including mechanisms like withdrawal throttling, multiple operators' involvement in distributing liquidity demands, and contingency plans for handling liquidity shortfalls. 

While these risks can be mitigated, they cannot be eliminated for users without returning to an M-of-N trust assumption for Bitcoin users. As a result, we need programs on Bitcoin that allow users to bridge their Bitcoin in a more trust-minimized fashion. So, we need better opcodes, like OP_CAT. 

OP_CAT is an opcode in Bitcoin Script that allows concatenating two items on the stack into a single item. While this operation might seem elementary, it is a powerful tool for creating complex transaction logic to compare and carry forward transaction data from one stage to another. For instance, in a vault construction, OP_CAT can enforce a timelock by constructing a transaction that checks whether outputs from a previous transaction match specific criteria (like amount and script) in the current transaction. By building the transaction on the stack, OP_CAT ensures that these criteria are strictly enforced, preventing unauthorized access to funds.

OP_CAT also plays a critical role in verifying Merkle trees that represent the state of external protocols. OP_CAT allows Bitcoin Script to progressively build a Merkle tree root from individual leaf nodes by concatenating and hashing data on the stack. This process involves taking pairs of data elements, hashing them together, and repeating this operation until the root is formed and compared against a known hash. 

Introduced by the Taproot Wizards, CatVM leverages OP_CAT to extend Bitcoin Script’s capabilities to handle dynamic, multi-stage transactions that allow conditions to be checked and enforced dynamically as transactions progress.

CatVM is crucial in managing shared UTXOs, where multiple users claim a single output. It allows any user to withdraw their share of the funds without affecting the others. This is achieved by embedding a Merkle root—a cryptographic summary of the entire tree—in the transaction, representing all users' balances. When users want to withdraw their funds, they provide a Merkle branch as proof of their balance. Using OP_CAT, CatVM concatenates and verifies this proof against the transaction data, ensuring the withdrawal is legitimate and meets all predefined conditions.

To secure the withdrawal process, CatVM implements a staging mechanism with a timelock. After initiating a withdrawal, the funds are temporarily restricted by a timelock, during which other users can challenge the withdrawal if they detect fraud. OP_CAT is critical in verifying whether a specific Merkle branch has already been used in a prior withdrawal, preventing double-spending, and ensuring the remaining UTXO is accurately updated and securely managed. As a result, with OP_CAT, users can withdraw funds directly, bypassing the need for peg operators and reducing concerns around trust and liquidity risks. 

Despite these advancements, CatVM’s implementation of OP_CAT has limitations, particularly in managing offchain state updates. While OP_CAT can enable secure and verifiable withdrawals from a committed state, it does not facilitate the trustless update of a Merkle tree root representing user balances offchain.

To address this, Starkware has developed a method for trustlessly updating a Merkle tree root on Bitcoin by leveraging zk-STARKs and OP_CAT. In this system, user balances are maintained offchain within a Merkle tree, while the Merkle root is stored onchain as a commitment to the state of all balances. When these balances are updated offchain, a new Merkle root is computed. To ensure this new root is valid and correctly derived from the previous one, a zk-STARK proof is generated offchain. This proof confirms that the state transition adhered to predefined rules, such as preventing unauthorized changes.

Verifying this zk-STARK proof onchain is made possible by OP_CAT’s ability to concatenate two elements on the stack within Bitcoin’s script. This operation is crucial for assembling the necessary data elements—such as the old Merkle root, the new Merkle root, and components of the zk-STARK proof—into a single, structured format. The Bitcoin script then uses this concatenated data to reconstruct the transaction in a manner that mirrors the zk-STARK proof’s original generation. Once the data is correctly assembled, the script performs cryptographic hashing operations to validate the proof, ensuring that the hash of the concatenated data matches the expected result provided by the STARK proof and confirming that the new Merkle root was derived correctly from the old one. If the proof is verified successfully, the Bitcoin script updates the onchain Merkle root to reflect the latest state of user balances, doing so without relying on a centralized intermediary. 

By increasing Bitcoin’s capability to embed data, Bitcoin has the fundamental structure to support verification of offchain computation, and a functioning DA layer, positioning Bitcoin to be used in more programmable, trust-minimized ways.

‍

Bridge #4: Structure → Sustainability

While Bitcoin has the fundamental structures to cross this bridge into a new era, it remains to be seen if the path ahead will lead to an equilibrium that all market participants are happy with.

We've figured out how to use Bitcoin as a data availability layer and now as a verification layer with BitVM, making it ready to host various scaling solutions from Validiums and Optimiums to full-scale rollups. However, given the importance of security and Bitcoin alignment across stakeholders, rollups will likely want to leverage Bitcoin itself for settlement and DA rather than using an external DA layer.

Bitcoin's blockspace is inherently scarce, with a hard cap of 4,000,000 weight units (WU) per block, equivalent to 4MB of data. This scarcity poses a significant challenge for rollups leveraging Bitcoin as a DA layer. ZK-rollups, for instance, plan to post ZK-proof outputs and state differences to Bitcoin every 6-8 blocks, which can consume up to 400KB, or 10% of an entire Bitcoin block (h/t @hiroto_btc for these numbers).

To understand the implications, we need to dive into the weeds of Bitcoin's transaction weight system (h/t bitconrollups.org for the numbers below). In Bitcoin, transaction sizes are measured in weight units, where one byte of witness data counts as 1 WU and one byte of non-witness data counts as 4 WU. A standard 1-input-2-output P2WPKH transaction weighs 561 WU. Rollups, however, can compress transaction data significantly. For example, each rollup transaction can be reduced to as little as 12 WU in an account model with address reuse. This is achieved by assigning public keys to account numbers on the rollup, which can be referenced in a highly compressed format rather than including the full public key or address in each transaction.

By leveraging these compression techniques, a rollup on top of Bitcoin using an account-based data structure could theoretically handle up to 250,000 rollup transactions per block, compared to around 7,130 standard transactions, making for a 35x throughput increase. However, as the following diagrams illustrate, this pales in comparison to the throughput improvements promised by rollups on Ethereum.

Any additional demand for blockspace will increase competition for inclusion, driving up transaction costs as miners prioritize transactions with higher fees. Ultimately, this will lead to a bidding war among users and rollups. As rollups compete for the same limited blockspace, the cost of posting data on Bitcoin will escalate, potentially making it economically unfeasible for many rollups to operate. If rollups are unable to coordinate around the usage of Bitcoin as a DA layer—which is the likely scenario—the situation could further deteriorate. If multiple rollups simultaneously attempt to post data to Bitcoin, the cumulative demand for blockspace will exceed what the network can sustainably provide.

‍

The Bridges Ahead

Scaling Bitcoin sustainably will require careful consideration of the technical limitations, economic incentives, and social dynamics within the Bitcoin ecosystem. 

In the coming years, the community will likely engage in intense debate and experimentation as it grapples with these challenges, as we’ve already seen with the potential introduction of OP_CAT and covenants. There’s even a possibility that OP_CAT could create a game-theoretical equilibrium where competition over blockspace reignites the blocksize wars within Bitcoin. Major players, such as providers of scalable Bitcoin-based dapps, might resist giving up blockspace to rivals. Whereas miners, seeking to increase revenue, could align with these players to reshape the network in ways that favor their interests. This could lead to a second blocksize war as stakeholders push for increased capacity to accommodate the growing demands of rollups and other layer 2 solutions.

For those developing Bitcoin scaling infrastructure, pioneering research and solutions that shift trust assumptions from m/n to 1-of-N could greatly enhance their chances of market dominance. This isn’t necessarily because end users fully grasp or care about the technical implications, but because scalability solutions must position themselves as the most faithful extensions of Bitcoin’s base layer to project long-term legitimacy. This legitimacy is critical for developers aiming to minimize platform risk and for product distributors like wallet providers. Currently, the competition has evolved into a race to rally M-of-N key influencers in the Bitcoin ecosystem around—or against—rival designs, a pattern already familiar to builders on Ethereum.

Alternatively, an opportunity lies in adopting an application-specific strategy, which could capitalize on revenue concentration in high-value applications for programmable Bitcoin while better controlling costs. Given the conservative nature of Bitcoin users, financial activity is likely to center around core tasks such as asset swapping, yield generation, and borrowing. As we've discussed in this piece, whether employing BitVM or using Bitcoin for DA, numerous explicit and implicit risks and costs are involved in operationalizing these systems. Vertical integration may offer builders better control over unit economics, a cohesive brand in an ecosystem fraught with legitimacy issues, and the ability to throttle economic activity as needed to scale under the trust assumptions of BitVM-based bridges.

As far as users go, bands of eager explorers are always ready to jump into any new hut in development on Bitcoin’s harsh landscape. TVL ranges for new scalability solutions on Bitcoin, ranging from 100M to 900M in Bitcoin deposits. On BoB, one user recently contributed ~$2.4M worth of wBTC/tBTC to the liquidity pool on Sovryn’s new AMM. 

However, existing data is likely a poor signal of what might come, as most Bitcoin-based TVL comes from assets with trust assumptions that have existed for many years, like WBTC and tBTC. Once we have implemented solutions that meaningfully incorporate improvements that BitVM and OP_CAT can bring, these explorers, and maybe a few more, will come to chase new opportunities. Still, it will likely take a few years of fighting and battle-testing for the Lindy effect to occur and for a second wave of more conservative Bitcoiners to settle on these new foundations. 

While the opportunity for Bitcoin is clear, the future is more uncertain than some optimists might believe. Bitcoin’s success will require balancing technical ingenuity with political and market dynamics that are already showing initial signs of tension.

There’s an exciting future on the horizon for Bitcoin, but the army of people entering and developing on its lands will have to face the difficult challenge of coordinating around the right bridges to cross.

—

Thank you to the Archetype team, Trace, and Walt Smith for the feedback, as well as the helpful learnings and content from Blockspace Media, Taproot Wizards, Bitcoin Magazine, and Citrea.

—

Disclaimer:

This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment or legal matters. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Archetype. This post reflects the current opinions of the authors and is not made on behalf of Archetype or its affiliates and does not necessarily reflect the opinions of Archetype, its affiliates or individuals associated with Archetype. The opinions reflected herein are subject to change without being updated.