For the first time in over four years, a significant shift may be underway in the Bitcoin ecosystem—not driven by core developers, but by grassroots community support. Two Bitcoin Improvement Proposals (BIPs), BIP-119 (OP_CHECKTEMPLATEVERIFY or CTV) and BIP-348 (OP_CHECKSIGFROMSTACK or CSFS), are gaining momentum among developers and users alike. These proposals aim to introduce covenants—a powerful scripting feature that could expand Bitcoin’s functionality beyond simple transactions.
This potential upgrade might culminate in a user-led soft fork (UASF), marking a pivotal moment in Bitcoin's evolution where community consensus, rather than miner signaling alone, drives protocol change.
What Are Bitcoin Covenants?
Covenants are a proposed mechanism within Bitcoin’s scripting language that allows conditions to be placed on how bitcoins can be spent in future transactions. Think of them as programmable restrictions—like setting rules for how and when money can be moved—enabling more sophisticated use cases without altering Bitcoin’s base-layer security.
While covenants aren’t yet active on Bitcoin’s mainnet, they’ve long been discussed as a way to enhance:
- Smart contract capabilities
- Fund security (e.g., vaults)
- Network efficiency (lower fees, batch payments)
Two key BIPs—CTV and CSFS—are now at the forefront of bringing covenants closer to reality.
BIP-119: OP_CHECKTEMPLATEVERIFY (CTV)
Proposed by former Bitcoin Core contributor Jeremy Rubin, BIP-119 (CTV) introduces an opcode that locks future transaction outputs into a predefined template. In simpler terms, it ensures that when funds are spent, the resulting transaction must match a specific structure set in advance.
Key Benefits of CTV
- Batch payments: Combine multiple payouts into one transaction, significantly reducing fees.
- Decentralized exchanges (DEXs): Enable atomic swaps with guaranteed output structures.
- Secure vaults: Protect funds by requiring multi-step withdrawal processes.
- Lightweight design: Unlike complex smart contracts, CTV is minimal and focused—making it less risky to deploy.
Because of its narrow scope, CTV has gradually gained acceptance even among conservative developers who typically oppose major changes.
👉 Discover how next-gen Bitcoin scripting could unlock new financial tools
BIP-348: OP_CHECKSIGFROMSTACK (CSFS)
A newer proposal co-authored by Rubin and Brandon Black in late 2024, BIP-348 (CSFS) enables deeper introspection into transaction data. It allows scripts to verify signatures against arbitrary messages pulled directly from the stack—opening the door to dynamic, state-aware logic.
Practical Uses of CSFS
- Conditional spending rules: Verify that a transaction meets certain criteria before allowing it to proceed.
- Advanced vaults: Build multi-layer security systems where access depends on historical transaction patterns.
- Composable smart contracts: When combined with other opcodes, CSFS supports complex decentralized applications.
While more flexible than CTV, CSFS remains cautious in scope—designed to avoid bloating the script system while expanding expressiveness.
The Role of OP_CAT in Covenant Development
Although not directly a covenant opcode, OP_CAT (BIP-347) plays a crucial background role. Originally part of Bitcoin’s script in 2009, it was removed in 2010 due to concerns about DoS attacks from unbounded data concatenation.
However, recent discussions have revived interest in reintroducing OP_CAT under strict resource limits. Its ability to concatenate data strings makes it a foundational tool for building advanced logic when paired with CSFS or other opcodes.
Now officially merged into the BIPs repository as BIP-347, OP_CAT symbolizes a broader shift: the community is re-evaluating previously rejected ideas with modern safeguards.
Why Now? Shifting Developer Sentiment
Just a few years ago, CTV was seen as too radical. Critics like Adam Back and Jimmy Song voiced strong opposition, contributing to Rubin’s departure from active Bitcoin development. Today, however, sentiment is shifting.
Several factors explain this change:
- Growing interest in Bitcoin-based DeFi and NFTs (e.g., Ordinals, Runes) has increased demand for richer scripting.
- The advocacy around OP_CAT has reframed CTV and CSFS as relatively conservative upgrades.
- Developers increasingly recognize the need for modular, low-risk enhancements rather than sweeping changes.
As Coindesk reported, many Western Bitcoin developers have recently expressed public support for both BIPs on social platforms—an encouraging sign of growing consensus.
👉 Explore how emerging Bitcoin features could reshape digital ownership
How Does a Soft Fork Actually Happen?
Implementing any BIP requires navigating Bitcoin’s decentralized governance model—a process both technical and social. Here’s a simplified view of the lifecycle:
- Idea proposal: Discussed on mailing lists or forums.
- BIP drafting: Formalized on GitHub with community input.
- Code implementation: Built and tested by developers.
- Review & audit: Scrutinized by core contributors like Pieter Wuille.
- Merge into Bitcoin Core: Approved by maintainers (currently five trusted developers).
- Testnet trials: Deployed on Signet or Liquid sidechains.
- Activation signaling: Miners signal readiness via block headers (typically 95% threshold).
- Final deployment: Activated across the network.
But there's another path: User Activated Soft Fork (UASF).
UASF vs MASF: Who Controls the Upgrade?
| Type | Full Name | Activation Mechanism |
|---|---|---|
| MASF | Miner-Activated Soft Fork | Requires miner signaling (e.g., 95% of blocks) |
| UASF | User-Activated Soft Fork | Nodes enforce rules regardless of miner support |
UASFs carry higher risk—potential chain splits if miners resist—but offer a way for users to push progress when miner incentives lag behind innovation. Notably, SegWit succeeded in 2017 thanks to a UASF movement (BIP-148).
Cobra, the maintainer of Bitcoin.org, recently warned that a UASF for CTV could emerge in 2025 if core developers remain hesitant—potentially sparking tension between “purists” and “innovators.”
Frequently Asked Questions
Q: Are covenants the same as smart contracts?
A: Not exactly. Covenants add conditional spending rules to Bitcoin transactions but don’t enable Turing-complete logic like Ethereum. They’re simpler, safer extensions focused on specific use cases like vaults or batch payments.
Q: Will these changes make Bitcoin more centralized?
A: No. Both CTV and CSFS are backward-compatible soft forks. They don’t alter consensus rules in a way that requires everyone to upgrade immediately or compromise decentralization.
Q: Can covenants enable DeFi on Bitcoin?
A: Yes—limited forms of DeFi become possible, such as decentralized lending, escrow services, and automated market makers—all built using constrained scripting logic.
Q: Is OP_CAT dangerous? Could it bring back DoS risks?
A: Modern proposals suggest reintroducing OP_CAT with strict gas limits or execution caps, mitigating past vulnerabilities while preserving utility.
Q: What happens if miners reject CTV?
A: If user demand is strong enough, a UASF could activate CTV anyway. However, this risks temporary network instability unless broad consensus exists.
Q: How can I track the progress of these BIPs?
A: Follow discussions on the Bitcoin BIPs GitHub, developer forums, and conferences like BTC++ and TABConf. Mining signaling data is also monitored via blockchain analytics platforms.
👉 Stay ahead of Bitcoin’s evolving capabilities with real-time insights
Final Thoughts
The renewed push for CTV and CSFS reflects a maturing ecosystem—one that balances caution with innovation. After years of stagnation, we may finally be entering an era where user-driven upgrades shape Bitcoin’s future.
Whether through miner signaling or community-enforced activation, the next soft fork could mark a turning point: not just technically, but philosophically—affirming that Bitcoin evolves not just by code, but by collective will.
Core keywords: Bitcoin covenants, BIP-119, BIP-348, CTV, CSFS, OP_CAT, user-led soft fork, Bitcoin scripting