Bitcoin’s November 2026 OPCAT reactivation explained

The technical shift in Bitcoin Script

The Bitcoin network reactivated the OP_CAT opcode in November 2026 following the deployment of Bitcoin Core’s BIP-347 testnet-4. This development follows a period where 23% of Taproot script developers adopted the new functionality. I see this reactivation as a response to the limitations of the current Bitcoin Script. The current language lacks the ability to store a global state or perform arithmetic operations for large numbers. It can only perform non-trivial computations on values up to 32 bits. This 32-bit limitation silos computationally intensive commands that use cryptographic functions. The Bitcoin Script also has a stack size limit of 1000 elements and individual items have a global maximum limit of 520 bytes. OP_CAT solves this by taking the top two data items on the stack and concatenating them. This operation allows the construction and verification of Merkle trees directly on the stack. It also enables covenant emulation through the use of Schnorr signatures. By using these "weird" signatures, the script can access the transaction hash on the stack. This allows a script to check individual pieces of a transaction against predefined hashes using OP_EQUAL. This functionality enables full granular introspection because every field of the transaction can be independently committed to. This upgrade follows historical changes like SegWit, which moved signature data to the witness field to allow up to 4m weight units of transaction data, and Taproot, which introduced Schnorr signatures to improve key aggregation. The consensus process for such changes is often contentious. The block size wars of 2015-2017 divided the community between stakeholders who wanted to alter the block size and those who did not. That debate resulted in a permanent chain split and the creation of Bitcoin Cash. Bitcoin Core v31.0rc4 provides improved privacy through Tor and I2P networks to hide user IP addresses. The update also increases the default database cache from 450 MB to 1,024 MB for systems with 4 GB of RAM. It also reorganizes transactions into clusters with a default limit of 64 transactions per cluster and 101 kB size.

BitVM and the quest for trust-minimized bridges

The reactivation of OP_CAT drives the competition between different scaling solutions, most notably BitVM and Botanix. BitVM recently demonstrated a trust-minimized bridge demo. The BitVM framework uses a pre-signed Bitcoin transaction graph to enforce protocol rules. In this system, a user locks BTC in a BitVM smart contract and mints wrapped BTC on a secondary system. When a user requests a withdrawal, a bridge operator provides liquidity by transferring BTC to the user. If a dispute occurs, the operator must reveal all intermediate values from the verifier computation. The challenger then runs the verifier off-chain to find any invalid chunk and submits a transaction to replay that chunk on Bitcoin. BitVM2 improves this by using permissionless challenge mechanisms. Bitlayer, a member of the BitVM Alliance, contributed to reducing the Groth16 verifier size. Because Bitlayer implemented a batched Multiple Scalar Multiplication technique and a new MSM algorithm using affine coordinates, they successfully reduced the monolithic Groth16 verifier size from 5.6 GB down to 1 GB. They also contributed the first feasible chunker implementation that splits the verifier into logical parts like the Miller loop accumulation. This chunked verifier consists of fewer than 1,000 chunks, making it feasible for deployment. The verifier relies on primitives like BIGINT arithmetic, BLAKE3 hashing, BN254 elliptic curve pairing, and Winternitz signatures. The BitVM process follows three steps: Peg-in, where a user locks BTC and mints wrapped BTC; Peg-out, where an operator provides liquidity for a withdrawal; and Claim, where the operator retrieves funds if no one challenges the claim.

Botanix and the EVM sidechain integration

Botanix offers an alternative via its Spiderchain EVM sidechain integration. Botanix uses the Ethereum Virtual Machine to execute smart contracts, which allows developers to use Solidity, Hardhat, and Remix. You likely realize that this allows developers to port dApps from Ethereum to Botanix with minimal changes. The Botanix network is a 16-node founding federation including Galaxy, Fireblocks, Alchemy, Antpool, XBTO, Kiln, and Chorus One. This federation ensures the network is decentralized from the start. Botanix also provides a "Bitcoin 2100" experience where players explore a world built on Bitcoin.

The Botanix mainnet launched on July 1, 2025, and the testnet completed over 26M transactions since its launch in December 2024. The network includes applications like Arch, Bitzy, Palladium, and Rover. Users can trade, lend, borrow, stake, and pay in bitcoin on the network. The federation expects to expand beyond 100 nodes in 2026.

The verdict on Bitcoin programmability

The choice between BitVM and Botanix depends on whether a user prioritizes absolute decentralization or developer speed. BitVM focuses on a framework for advanced computation that stays true to Bitcoin’s security. Botanix focuses on providing an environment that leverages the mature smart contract ecosystem of Ethereum. I find the Botanix integration more practical for immediate use because it allows the use of familiar tools like Web3.js and ethers.js. The ability to use Solidity means developers do not have to learn new languages to build on Bitcoin. However, the BitVM approach offers a more native feel for those who want to avoid sidechains. While Solana uses Rust and Starkware uses Cairo, Botanix chose Solidity to attract its developer base. The BitVM framework remains an engineering effort to bring advanced computation to Bitcoin while staying true to its principles. Botanix attempts to bridge the gap by using the most mature smart contract ecosystem in crypto. I favor the Botanix approach for users who want to access Uniswap-style DEXs or Aave-style lending protocols with ease. Will the consensus on OP_CAT lead to a wider shift in Bitcoin development?