Timechain Wiki

Proposed scaling soft forks

25 min read

As of 2026, a cluster of proposed soft forks sits in active developer discussion. The covenant-class proposals — OP_CTV (BIP-119), OP_CAT (re-enablement), CHECKSIGFROMSTACK, and OP_VAULT (BIP-345) — would constrain how UTXOs can be spent in ways that unlock vault constructions, channel factories, more efficient Ark rounds, and trustless bridge primitives. The non-covenant proposals — ANYPREVOUT (BIP-118, the eltoo precondition) and the LNHANCE bundle combining CSFS, CTV, and APO — target Lightning-specific improvements including watchtower obsolescence for compliant channels. Alongside the scaling-enabler cluster sits the consensus-hardening BIP 54 / Great Consensus Cleanup as a janitorial-omnibus proposal addressing four long-known vulnerabilities; as of 2026 it carries the highest activation probability of any post-Taproot soft fork. None has activated since Taproot in 2021, and no clear successor to Speedy Trial has emerged. This note surveys what is proposed and what each would enable; the substantive political debate is sequestered in the covenants controversy note.

Why this note matters

Bitcoin’s base-layer scaling story since 2017 has been a story of base-layer upgrades that unlock off-chain construction. SegWit upgrade made deployable Lightning possible by fixing transaction malleability; Taproot upgrade (2021) extended the witness-discount accounting and introduced Schnorr signatures, enabling more compact multisig and the script-path-spend disjunction. The next generation of Layer-2 systems — improved Lightning channels, Ark protocol, channel factories, BitVM-style trustless bridges, sophisticated self-custody vaults — depends on base-layer primitives that have not yet activated.

The proposal landscape is unusually crowded for the post-Taproot era. Multiple covenant-class and non-covenant proposals are in active developer discussion, each with distinct authorship, design goals, and Layer-2 implications. Understanding what is on the table — and what each proposal would enable — is the precondition for engaging the broader protocol-evolution conversation.

The activation question is itself open. Speedy Trial worked for Taproot because miner and developer support was broad; no comparable consensus has formed around any specific proposal in this cluster, and no clear successor mechanism has been established for genuinely contested upgrades.

What this note covers

This note is a technical proposal-landscape survey — what is proposed, what each enables in the Layer-2 design space, and current activation status. The posture is survey-not-advocacy.

The primary focus is the scaling-enabler cluster — covenant-class and non-covenant proposals that would unlock new Layer-2 architecture. The note also covers the consensus-hardening cluster, currently a single live proposal — BIP 54 / the Great Consensus Cleanup. Hardening proposals are not scaling-enablers and do not change Bitcoin’s expressiveness; they are included here because they share the post-Taproot soft-fork landscape, compete for the same activation-mechanism bandwidth, and form part of the same calibrated question — what, if anything, should activate next on Bitcoin’s base layer. The survey-not-advocacy posture applies uniformly across both clusters.

The substantive political debate about whether Bitcoin should accept programmability of this kind — the digital-gold-purity vs richer-scripting question, the security-attack-surface concerns, the ossification-as-feature argument — lives in OP_CAT and the covenants programmability debate and Protocol-evolution constraints. This note defers to those notes for the contested cluster and does not duplicate their engagement.

BIP-300 and the Drivechains debate is adjacent but out-of-scope here — it is a different proposal mechanism (a sidechain construct rather than a base-layer scaling soft fork), and the controversy note carries that engagement. Generic soft-fork activation mechanism theory lives in Soft-fork activation mechanisms and How upgrades happen; this note touches activation only as it bears on the specific proposals surveyed.

The proposal landscape (2026 snapshot)

The active proposals cluster into three families. Covenant-class proposals constrain how UTXOs can be spent — committing in advance to spending templates or enabling script-level inspection of spending conditions. Non-covenant proposals modify signature semantics or transaction-reference behavior without introducing covenant primitives proper. Consensus-hardening proposals do not change Bitcoin’s expressiveness at all — they close known vulnerabilities in existing consensus rules.

ProposalBIPClassPrincipal author(s)One-line summary
OP_CTVBIP-119CovenantJeremy RubinCommit to a specific transaction template; congestion control and vault constructions
OP_CATunassignedCovenantmultipleRe-enable concatenation; broad scripting unlock (most-debated)
CHECKSIGFROMSTACKunassignedCovenant-adjacentmultipleVerify signatures over arbitrary stack data; adaptor signatures and oracle constructions
OP_VAULTBIP-345CovenantJames O’BeirneExplicit primitives for time-delayed vault spending
ANYPREVOUTBIP-118Non-covenantChristian Decker, AJ TownsSignature variant that doesn’t commit to specific prevout; eltoo precondition
LNHANCE bundle—MixedLightning developersCSFS + CTV + APO bundle advocated for Lightning improvements
Consensus CleanupBIP 54Consensus-hardeningAntoine Poinsot and collaboratorsJanitorial-omnibus closing four long-known vulnerabilities — timewarp, poison blocks, 64-byte transaction malleability, duplicate-transaction handling

None of these has activated on mainnet, and none has reached the broad consensus that preceded Taproot. As of 2026-05-17 two have nonetheless moved beyond pure debate: OP_CTV is the subject of a contested third-party activation attempt — a BIP-9 signaling client released in February 2026 (see below) — and BIP 54 is the furthest along the test-network proving pipeline.

Covenant-class proposals

A covenant, in the Bitcoin-scripting sense, is a spending condition that constrains how the resulting UTXO can subsequently be spent. Bitcoin Script today supports limited covenant-like behavior — time-locks via CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY constrain when a UTXO can be spent — but does not natively support template-level constraints on how it can be spent. Covenant-class proposals would change this.

The Layer-2 motivation is direct. Many of the most attractive Layer-2 architectures — Ark’s vUTXO recycling, channel factories that batch many Lightning channels into a shared outer construction, sophisticated vault designs with multi-step approval — require the base layer to enforce that funds can only move along pre-committed paths. Without covenant primitives, these architectures either cannot be built or require federated trust assumptions that defeat the purpose. See Bitcoin Script and opcodes for the underlying scripting framework.

OP_CTV / CHECKTEMPLATEVERIFY (BIP-119)

OP_CTV is the most-mature covenant proposal. Proposed by Jeremy Rubin in 2020, it allows a transaction to commit to a specific output template — the hash of a future transaction’s structure, including outputs, sequences, and other elements. A UTXO encumbered with OP_CTV can only be spent by a transaction whose template matches the committed hash.

The principal use cases:

  • Congestion control. A high-fee-environment user can commit on-chain to a single transaction that pays many recipients, with the actual fan-out happening later in lower-fee conditions. This reduces blockspace consumption during fee spikes.
  • Vault constructions. A user can encumber funds with OP_CTV so that spending requires a specific multi-step path — for example, a delayed-spend transaction with an emergency-clawback path. The base layer enforces that no other spending path is possible.
  • Ark rounds. The cleanest Ark architecture uses OP_CTV to commit ASP round transactions to specific output structures, ensuring the ASP cannot redirect pooled funds. See Ark protocol for the full treatment.
  • Channel factories. Multiple Lightning channels can share a single outer on-chain transaction with covenant-enforced spending structure, reducing per-channel on-chain footprint.

OP_CTV is the most-conservative covenant proposal in active discussion — it does not enable arbitrary script-level inspection; it only constrains spending templates. The technical-security analysis is the most mature of the covenant proposals. The political-debate substance lives in OP_CAT and the covenants programmability debate.

The 2026 activation attempt. In February 2026 a third-party activation client was released encoding OP_CTV as a BIP-9 deployment — an approximately 90% miner-signaling threshold, a signaling window opening 30 March 2026, and a one-year timeout (March 2027, with earliest activation around May 2027). The move deliberately echoes Jeremy Rubin’s April-2022 Speedy-Trial client, which was called off within weeks for lack of consensus; the 2026 client has likewise not been merged into Bitcoin Core and has not achieved the broad developer-and-community agreement that preceded Taproot, with developers still divided over whether CTV alone is the right primitive or a more expressive covenant should be adopted instead. The attempt sharpens rather than resolves the activation-mechanism question treated below — opponents argue that a Speedy-Trial-style client is inappropriate for a still-contested change, precisely because that mechanism was designed for proposals that had already reached overwhelming agreement. Whether the signaling window draws meaningful miner support remains open.

OP_CAT (re-enabling; BIP unassigned)

OP_CAT would re-enable the data-concatenation opcode disabled by Satoshi in 2010, opening Bitcoin Script to substantially more sophisticated spending conditions than the other proposals in this cluster — covenants, trustless bridges, advanced vault constructions, and broader scripting patterns become expressible. OP_CAT is the most-debated of the covenant-class proposals; the dispute is fundamentally about how much smart-contract functionality should be native to Bitcoin. Substantive engagement with the digital-gold-vs-programmability divide, the security-attack-surface arguments, and the ossification framing lives in OP_CAT and the covenants programmability debate — this note defers to that engagement.

CHECKSIGFROMSTACK (CSFS)

CSFS would allow a Bitcoin Script to verify a signature over arbitrary data placed on the stack, rather than only over the spending transaction itself. The combination of CSFS with existing primitives unlocks several constructions:

  • Adaptor signatures. CSFS enables more flexible adaptor-signature patterns useful in Lightning’s eventual move to point-time-locked contracts (PTLCs) and in DLC (Discreet Log Contract) constructions.
  • Oracle attestation verification. DLCs and other oracle-dependent constructions can verify oracle signatures directly in script, simplifying the attestation flow.
  • More flexible covenant emulation. CSFS combined with other primitives can emulate some covenant behaviors without a dedicated covenant opcode.

CSFS is less controversial than OP_CAT — it does not enable the broad scripting unlock OP_CAT does — but it is also less ambitious. It frequently appears in proposal bundles alongside other primitives rather than standalone.

OP_VAULT (BIP-345)

OP_VAULT, proposed by James O’Beirne, provides explicit vault primitives at the protocol level rather than emulating them via more-general covenant opcodes. A vault output enforces a delay between when a spend is initiated (“unvaulting”) and when the spend completes, with a clawback path available during the delay window if the unvault was unauthorized.

The use case is explicit: high-value self-custody and institutional custody. A compromised hot key can initiate an unvault, but the legitimate owner has the delay window to detect the attempt and clawback to a cold recovery path. Vault constructions can be approximated with OP_CTV plus additional logic, but BIP-345 provides the primitive directly with cleaner semantics and smaller witness footprint.

BIP-345 is less broadly discussed than OP_CTV but has substantial support from the self-custody-focused developer community.

Non-covenant proposals

Not all proposed soft forks in this cluster introduce covenants. Two adjacent proposals modify signature semantics or transaction-reference behavior to enable specific Layer-2 improvements without crossing into covenant territory.

ANYPREVOUT / SIGHASH_ANYPREVOUT (BIPs 118, related)

ANYPREVOUT (APO) is a new signature hash flag that allows a signature to be valid for any previous output with a matching script, rather than committing to a specific prevout. The change is narrow — it adds a new SIGHASH variant — but the implications are substantial.

The principal use case is eltoo, Christian Decker and Rusty Russell’s proposed Lightning channel update mechanism. Today’s Lightning channels use a penalty-based design: an old channel state, if broadcast by a misbehaving counterparty, can be punished by the honest party’s claim of all channel funds. The penalty design requires the honest party (or a Watchtowers service acting on their behalf) to be online and watching the chain during the channel’s lifetime.

Eltoo replaces the penalty design with a layered-update design: each new channel state simply supersedes the previous, with the most-recent state winning any settlement race. There is no penalty, and there is no need for a Watchtowers service for compliant channels — a misbehaving counterparty cannot extract funds from an honest counterparty even if the honest party is offline. APO is the signature-semantics precondition that makes the layered-update design possible.

The non-Lightning use cases include simplified channel-factory constructions, more flexible payment-channel designs, and various adaptor-signature applications.

The LNHANCE bundle

LNHANCE is a proposal bundle advocated by several Lightning developers that groups CSFS, CTV, and APO into a single coordinated upgrade. The argument: these three primitives together enable a substantial step-change in Lightning’s design space — eltoo channels via APO, channel factories via CTV, and improved PTLCs and DLC integration via CSFS — and activating them together is more efficient than activating each separately.

The bundling argument cuts both ways. Proponents argue that a coordinated bundle reduces activation overhead and lets Lightning developers plan the next-generation architecture coherently. Skeptics argue that bundling makes the activation decision harder — opponents of any one primitive become opponents of the whole bundle — and that smaller separate activations preserve more deliberation room.

Consensus-hardening proposals

Not every active soft-fork proposal in the post-Taproot landscape is a scaling-enabler. A separate cluster targets consensus hygiene — closing known vulnerabilities in Bitcoin’s existing consensus rules without changing what the protocol can express. As of 2026 the cluster is small enough to be a single proposal — BIP 54 / the Great Consensus Cleanup — but it is included in this survey because BIP 54 is the most-active soft-fork proposal of the moment, carries the highest current activation probability of anything in the post-Taproot landscape, and competes for the same activation-mechanism bandwidth as the scaling-enabler proposals above.

BIP 54 — The Consensus Cleanup

BIP 54, authored by Antoine Poinsot with collaboration from several long-standing Bitcoin Core contributors, bundles four distinct fixes to long-known weaknesses in Bitcoin’s consensus rules. The vulnerabilities all date to the original 2009 codebase — they have been documented for years in developer-discussion archives — and the cleanup proposal aggregates them into a single soft-fork upgrade rather than addressing each separately.

What BIP 54 bundles. The four fixes:

  • Timewarp attack mitigation. The current difficulty-adjustment algorithm permits a miner controlling substantial hashrate to manipulate block timestamps across a difficulty period in ways that artificially lower the difficulty target — accelerating block production and disturbing the issuance schedule. BIP 54 requires that the first block of each difficulty period carry a minimum timestamp derived from its predecessor, closing the exploit window. The mechanism is narrow; see Difficulty adjustment for the underlying retargeting framework and the BIP-54 specification for the timewarp specifics.
  • Block-validation-cost caps — the “poison block” class. Certain combinations of script-validation operations let a miner construct blocks that take pathologically long to validate — ten or more minutes on a high-end node, ten or more hours on a Raspberry Pi class machine — without exceeding any existing protocol limit. The mechanism abuses the asymmetric cost between block construction and block validation. BIP 54 introduces a cap on the relevant operations, bounding worst-case validation cost and protecting the smaller-node validation tier that underwrites Bitcoin’s decentralization properties. See Bitcoin Script and opcodes for the scripting context.
  • 64-byte transaction / Merkle malleability fix. A transaction whose serialized form is exactly 64 bytes can be confused with an interior node of the Merkle tree by an SPV verifier — see Full nodes vs pruned vs SPV for the light-client framework — enabling forged-transaction proofs against light clients. BIP 54 disallows the malleable form, closing the SPV-proof attack vector. The fix is narrow; SPV theory proper lives elsewhere.
  • Duplicate-transaction handling simplification. The current rules around what happens when a transaction with an identical txid to a prior transaction is mined require computationally expensive defensive code paths. BIP 54 simplifies the handling by disallowing the duplicate-txid case at the consensus layer, eliminating the special-case validation logic.

2026 deployment status. BIP 54 is unusually far along the test-network proving pipeline for a soft fork that has not yet activated:

  • Bitcoin Inquisition. The proposal went live on Bitcoin Inquisition — the experimental signet-derived test network maintained for evaluating proposed soft forks under consensus-enforced conditions — in February 2026. Inquisition deployment is the canonical first proving ground for any modern post-Taproot soft-fork candidate.
  • Signet demonstration. A full Signet test-network demonstration of the cleanup rules under load executed in March 2026, confirming the rule changes behave as specified and produce no unexpected interactions with existing relay or wallet software.
  • Mining-pool readiness signals. Major mining pools MARA and ViaBTC have publicly signaled readiness to support BIP 54 activation. While signaling readiness is not the same as committing to a specific activation mechanism — see Soft-fork activation mechanisms for the distinction — early pool engagement is a precondition for any mechanism that involves miner signaling.

The deployment pattern — Inquisition first, Signet demonstration second, pool-readiness signaling third — is itself becoming the canonical sequence for post-Taproot soft-fork proposals. Future scaling-enabler proposals that reach the activation conversation are expected to follow the same path.

Why BIP 54 stands apart from the covenant debate. The covenant-class proposals surveyed above are politically contested because they would change what Bitcoin Script can express — and the question of how much programmability should be native to Bitcoin’s base layer is the substantive divide animating the post-Taproot soft-fork discussion. BIP 54 sidesteps this debate entirely. It does not add an opcode, does not modify signature semantics, does not enable a new Layer-2 architecture. It closes documented vulnerabilities in rules that have existed since 2009 — vulnerabilities that essentially everyone in the technical community agrees should be closed.

The strongest case for BIP 54 is therefore narrow and almost uncontroversial: the vulnerabilities are real, the fixes are minimal, the test-network exposure is mature, and the protocol is meaningfully more robust afterward. Skeptics — to the extent any exist — argue principally on ossification grounds: that even minimal consensus changes accumulate, that the precedent of activating “small janitorial” bundles makes future activation easier, and that for a global monetary asset the appropriate posture is to live with known minor vulnerabilities rather than touch the consensus rules at all. The ossification argument has genuine philosophical merit but is unusually weak in BIP 54’s specific case — the vulnerabilities include validation-cost attacks that could degrade node-operator economics and SPV-proof forgery that compromises light-client security.

As of 2026 the activation probability for BIP 54 is the highest of any post-Taproot soft fork. The combination of mature test-network exposure, early pool readiness, lack of political controversy, and clear vulnerability-driven motivation distinguishes it from the covenant proposals — which remain stalled principally on the programmability question rather than on technical-readiness grounds.

What BIP 54 is not. It is critical to be precise about what BIP 54 does not do, because the proposal’s relatively-high activation probability invites mischaracterization in adjacent discussions:

  • Not a scaling-enabler. BIP 54 does not increase block size, does not change witness-discount accounting, does not enable any new Layer-2 architecture, does not reduce per-transaction on-chain footprint. Anyone reading the proposal hoping for scaling gains will be disappointed.
  • Not a programmability change. BIP 54 does not add any opcode, does not modify Bitcoin Script’s expressiveness, does not enable any spending pattern that wasn’t possible before. The covenants debate is entirely orthogonal to BIP 54.
  • Not an activation-mechanism choice. The proposal text specifies what the rule changes are; the question of how the soft fork activates — Speedy Trial, BIP8 LOT=true, UASF, or a successor mechanism — is a separate decision deferred to the activation-mechanism discussion. See Soft-fork activation mechanisms and How upgrades happen for the procedural framework.
  • Not a precedent for unilateral covenant activation. The relatively-uncontroversial nature of BIP 54 should not be taken to mean that activation precedent transfers to contested upgrades. The activation mechanism that works for BIP 54 may not generalize.

Cross-references and further reading. Activation-mechanism theory lives in Soft-fork activation mechanisms and How upgrades happen; the substantive engagement with whether Bitcoin should accept richer scripting at all lives in OP_CAT and the covenants programmability debate and Protocol-evolution constraints; the upgrade-mechanism framework generally lives in Soft forks and hard forks; the BIP framework itself lives in Bitcoin Improvement Proposals. The canonical sources for BIP 54 specifically are bip54.org (the proposal site), bips.dev/54 (the canonical BIP text), and the Bitcoin Optech consensus-cleanup-soft-fork topic page (status tracking and weekly discussion summary). Bitcoin Magazine’s The Core Issue: Consensus Cleanup and Blockspace Media’s Bitcoin’s next upgrade won’t be quantum. It could be the Great Consensus Cleanup (BIP 54) are useful editorial framings for the 2026 activation context.

What each enables

The Layer-2 design space implications cluster around several use cases:

  • Ark efficiency. Native Ark depends on OP_CTV or equivalent covenant primitives. Without them, only “Clark” variants — covenant-light Ark with additional operational complexity — are deployable on mainnet. See Ark protocol for the full treatment of the covenant dependency.
  • Channel factories. Multiple Lightning channels sharing a single outer on-chain transaction reduce per-channel on-chain footprint substantially. Construction depends on OP_CTV-style template commitments to bound the spending paths of the shared outer output. See The Lightning Network and Lightning channels for the Lightning architecture.
  • Improved Lightning channels. APO enables eltoo channels, obsoleting Watchtowers for compliant channels and simplifying the layered-update model. CSFS enables more flexible PTLC and DLC constructions. The LNHANCE bundle packages these together with CTV-enabled channel factories.
  • Sophisticated vaults. OP_VAULT provides explicit vault primitives; OP_CTV plus additional logic can emulate vaults with somewhat larger witnesses. Both target high-value self-custody and institutional custody.
  • Trustless bridges and BitVM constructions. BitVM and adjacent trustless-bridge proposals depend on covenant primitives for the strongest constructions. With OP_CAT specifically, much broader bridge designs become expressible; with OP_CTV alone, more limited but still useful constructions are possible.
  • More compact multisig and complex spending conditions. The combination of Taproot’s script-path-spend disjunction with covenant primitives reduces witness overhead for sophisticated spending policies, lowering on-chain costs.

The Layer-2 design space is meaningfully constrained by which (if any) of these proposals activate. Some Layer-2 architectures are deployable today with weaker properties; others are not deployable without one or more covenant activations.

Activation mechanics — the post-Taproot question

Taproot upgrade activated cleanly in November 2021 via Speedy Trial, a fixed-window LOT=false mechanism with strict timeout. Speedy Trial succeeded because miner and developer support for Taproot was broad and the upgrade was uncontroversial. No comparable consensus has formed around any of the proposals surveyed here, and no clear successor mechanism has been established for the post-Taproot era.

The activation-mechanism question is itself open. Several positions are visible in current discussion:

  • Some developers favor Speedy Trial repetition — the same fixed-window LOT=false mechanism — on the basis that it worked once and the political-economic dynamics that would force a more aggressive mechanism have not materialized.
  • Some favor BIP8 LOT=true on the basis that the post-2021 community-governance environment may not produce miner-signaling consensus for contested upgrades, and a mandatory-activation deadline is needed to break stalls.
  • Some favor UASF-style mechanisms — the BIP148 precedent generalized — for any upgrade that miner signaling stalls, on the basis that economic-node consensus is the ultimate decision-making mechanism.
  • Some argue that no contested upgrade should activate at all under any mechanism — the ossification position discussed below.

The mechanism choice for each specific upgrade is itself a substantive governance decision; the empirical answer for OP_CTV, OP_CAT, APO, and the others depends on the specific dynamics around each proposal. Among current candidates, BIP 54 is the leading contender for the next activation — its lower political-controversy profile relative to the covenant cluster means activation-mechanism debate around it is less likely to become the proxy battlefield for the broader programmability question. The full activation-mechanism framework lives in Soft-fork activation mechanisms and How upgrades happen; this note flags the open question and defers to those notes.

Tradeoffs and design choices

Programmability vs simplicity tension. The covenant-class proposals expand Bitcoin Script’s expressiveness, enabling Layer-2 architectures that are not deployable on current Bitcoin. The cost is additional complexity in the base layer — more opcodes, more analysis surface, more interaction patterns to reason about. The simplicity argument: Bitcoin’s stable cryptography is in part a function of its minimal attack surface, and adding script primitives invites unforeseen interaction patterns. The expressiveness argument: the Layer-2 designs that covenants enable are themselves the scaling story, and Bitcoin without them cedes the useful design space to less-secure platforms.

Bundling vs separate activation. The LNHANCE bundle and the broader question of whether to activate covenant proposals together or separately is a live design choice. Bundling reduces coordination overhead but raises the bar for any specific activation. Separate activation preserves deliberation room but extends the timeline and may produce sub-optimal outcomes if related primitives end up activating piecemeal.

Ossification arguments. A position in the community holds that Bitcoin should not change further — that the protocol is sufficient as it stands, that any additional features add complexity and attack surface without commensurate benefit, and that the appropriate posture for a global monetary asset is calcification. The ossification position takes the strongest case for not activating any of these proposals: Bitcoin’s monetary properties do not depend on richer scripting; the use cases that covenants enable are speculative or can be served via federated alternatives; and the long-run security model benefits from minimizing protocol changes. Substantive engagement with the ossification debate lives in Protocol-evolution constraints.

The “Bitcoin should not change” position is not unanimous. Within the conservative camp, distinctions exist between full ossification (no further upgrades of any kind), pragmatic conservatism (upgrades only when the case is overwhelming and the security analysis is mature), and Lightning-aligned moderation (upgrades that specifically improve Lightning are acceptable; broader covenant expansion is not). The taxonomy matters because aggregate “conservative” opposition often disguises substantively different positions.

Substantive analytical critique lives in OP_CAT and the covenants programmability debate (the event-level dispute about specific covenant BIPs) and Protocol-evolution constraints (the analytical critique of structural calcification).

Counter-arguments and tensions

The strongest case for these proposals: Bitcoin’s monetary properties don’t depend on minimalist scripting, and the Layer-2 architectures that covenants enable substantively improve user experience and security. Without them, much of the interesting Layer-2 development either stalls or migrates to architectures with weaker trust assumptions. The strongest case against: even well-analyzed cryptographic primitives have produced unexpected vulnerabilities over time, the post-2021 community-governance environment cannot reliably produce consensus on contested changes, and the ossification position has genuine merit for a global monetary asset whose security depends on minimal protocol change.

As of 2026, no clear consensus has formed in either direction. The debate is more philosophical than rhetorical — more constructive than the Ordinals dispute, less polarized than the Block Size Wars. See OP_CAT and the covenants programmability debate and Protocol-evolution constraints for the substantive engagement; this note’s posture is survey-not-advocacy.

Open questions for further development

  • Which proposal (if any) activates first? OP_CTV’s narrower scope and more mature security analysis make it the most-likely-first candidate among the covenant-class proposals. APO has Lightning-developer support but limited momentum outside that community. OP_CAT remains the most-debated and least-likely-imminent.
  • Does the LNHANCE bundling approach win out, or do proposals activate separately? The bundling argument cuts both ways; the empirical answer depends on Lightning-developer coordination and broader community reception.
  • What activation mechanism applies to genuinely contested upgrades? Speedy Trial worked for Taproot because consensus was broad; no comparable consensus exists here. The mechanism-choice question is itself an open debate.
  • What is the long-run trajectory for Ark and channel factories if covenant activation is delayed indefinitely? Clark variants and other covenant-light constructions are deployable but with weaker properties. The Layer-2 design space narrows materially without covenant primitives.
  • How does the post-quantum migration interaction work? Future post-quantum signature schemes will require their own soft-fork upgrades; the activation pipeline for covenant proposals interacts with that longer-horizon question.
  • Does the ossification position prevail by default? Even without explicit rejection, indefinite non-activation effectively decides the question against any of these proposals. The post-Taproot quiet period may itself be the answer.

Canonical sources for this note

Specifications

  • BIP-119 — CheckTemplateVerify (OP_CTV), Jeremy Rubin (2020): github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
  • BIP-118 — SIGHASH_ANYPREVOUT, Christian Decker / AJ Towns (revised 2021): github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
  • BIP-345 — OP_VAULT, James O’Beirne / Greg Sanders / Anthony Towns (2023): github.com/bitcoin/bips/blob/master/bip-0345.mediawiki
  • OP_CAT — re-enablement proposal (BIP unassigned as of 2026); active discussion on Delving Bitcoin and bitcoin-dev mailing list
  • CHECKSIGFROMSTACK — discussion across bitcoin-dev mailing list and Delving Bitcoin; no single canonical BIP

Proposal-author writings and engagement

  • Jeremy Rubin — OP_CTV: a covenant proposal and adjacent writings; utxos.org
  • Christian Decker and Rusty Russell — eltoo: A Simple Layer2 Protocol for Bitcoin (2018 paper) and subsequent discussion
  • AJ Towns — extensive writing on covenant tradeoffs and activation-mechanism design across Delving Bitcoin
  • Antoine Riard — analytical writings on covenant interactions and Layer-2 design
  • James O’Beirne — OP_VAULT motivation writings
  • Lightning developer writings on LNHANCE — Bitcoin Optech and Delving Bitcoin threads

Discussion venues

  • Delving Bitcoin forum — primary technical-discussion venue for current proposals
  • bitcoin-dev mailing list — historical and current discussion archive
  • Bitcoin Optech newsletter — weekly coverage of proposal status and developer discussion
  • BTC++ and adjacent technical conferences — proposal-author presentations

Reference texts

Graph View

Backlinks