Bitcoin covenant proposals are drawing renewed attention as developers revisit ways to expand Bitcoin’s functionality, but implementing them may be difficult amid governance and client-diversification challenges. According to Cointelegraph, covenants could support applications such as trustless and scalable layer-2 systems, fully non-custodial vaults with more complex spending logic, and more efficient payment channels, yet most approaches would require a soft fork of Bitcoin’s consensus rules, a process likely to trigger community debate. With consensus clients increasingly split between Core and Knots nodes, the article says agreement on such changes appears less likely. It adds that despite Knots proponents pushing their own soft fork proposal, BIP-110, that side generally favors protocol ossification and seems less supportive of base-layer scaling efforts. The controversy surrounding Bitcoin Core, described as both technical and governance-related, is also cited as reducing the near-term prospects for covenant adoption.
The article outlines why covenants matter by explaining Bitcoin’s transaction validation model. Bitcoin locking conditions are written in Bitcoin Script, a stack-based, non-Turing-complete language. A sender sets spending conditions via a locking script (scriptPubKey), and a recipient later spends the output by providing an unlocking script (scriptSig) that satisfies those conditions. Script can verify signatures, enforce timelocks, check hash preimages, and combine conditions with propositional logic. However, once a valid unlocking script is provided, the spender can send funds to any arbitrary new locking script, meaning current rules do not let the original sender restrict where coins can be sent afterward. Covenants aim to change that by enabling restrictions on future spending. The concept was introduced by Gregory Maxwell in 2013 and later popularized by Möser, Eyal, and Sirer in 2016, with Maxwell initially proposing zk-SNARK-based restrictions. The article distinguishes basic covenants, which constrain only the next spend but can be chained into predefined sequences, from general covenants, which would allow recursive rules to persist indefinitely but face major technical hurdles and would require significant protocol updates. It also groups proposals into four categories: direct covenant opcodes such as OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT; supporting opcodes like OP_CHECKSIGFROMSTACK and OP_CAT; specialized vault-focused opcodes including OP_VAULT, OP_UNVAULT, and OP_EVICT; and approaches that approximate covenant behavior without a soft fork, such as ColliderScript, Bitcoin PIPE, and FE-based covenants. The article notes that if mainnet fees spike again and the spam wars are resolved, debate around these proposals could regain momentum, while also citing public support for ossification from figures including Michael Saylor.
Catherine
