Introduction
Bitcoin has not activated a consensus change since Taproot in November 2021. Every other major smart-contract chain has iterated on its execution layer several times over in the same window. Bitcoin, by design, has not — and the frustration this has produced inside the BTCFi builder community is now surfacing as an organized push for a specific, minimal upgrade: the pairing of OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS).
The pitch is narrow. CTV lets a coin commit, in advance, to the exact shape of the transaction that spends it. CSFS lets a script verify a signature over arbitrary data pulled from the stack. Neither introduces recursion. Neither enables the fully general programmability that OP_CAT proponents want. Together, they would nonetheless unlock a class of constructions — non-custodial vaults, more efficient joinpools and channel factories, cheaper discreet log contracts, and simpler paths for Lightning and Ark — that BTCFi builders have been emulating with increasingly fragile presigned-transaction machinery.
The interesting question for us is not whether CTV+CSFS is technically sound. That debate is largely exhausted; the proposal has been in the open for years. The interesting question is why an upgrade this narrow has stalled, and what the mid-2025 open letter and the proposed 2026~2027 out-of-Core activation timeline mean for how Bitcoin makes consensus decisions going forward. If activation succeeds through a client that is not Bitcoin Core, it will be the first such precedent since the SegWit UASF era, and it will reshape how future protocol changes are negotiated. If it fails, it will confirm that Bitcoin’s upgrade path is, functionally, frozen — and that BTCFi builders should plan accordingly.
What a covenant actually is
A covenant, in Bitcoin script terms, is a spending condition that constrains not just whether a UTXO can be spent, but what the spending transaction must look like. Today, script answers a single-tense question: given the witness data, is this spend authorized right now? A covenant extends the tense: given this spend, does the transaction it produces match a shape we committed to earlier?
CTV, specified as BIP-119, implements this in the most restrictive way possible. When a UTXO is locked to a CTV script, the opcode hashes a specific set of fields from the spending transaction and compares them to a template hash embedded in the script. Per Bitcoin Optech, the committed fields are: transaction version, locktime, the scriptsigs, the number of inputs, the sequence values, the number of outputs, the outputs themselves, and the index of the spending input. If any of these differ from the template, the spend fails.
Two properties of this design are worth pausing on. First, CTV commits to outputs but not to inputs — specifically, not to the txids of the inputs. This is what allows the same template to be reused across different funding transactions, which is what makes vaults and congestion-control constructions practical. Second, CTV is non-recursive by construction. The template hash is a fixed value in the script; it cannot itself be computed from the spending transaction. A CTV output can force its next hop, but that next hop is a concrete, pre-specified transaction — it cannot in turn be a CTV output whose template is derived from something on the stack. This structural non-recursion is the entire basis of the argument that CTV cannot produce permanently restricted coins.
CSFS is a different primitive. Where Bitcoin’s existing OP_CHECKSIG verifies a signature over the current transaction, CSFS verifies a signature over arbitrary data that a spender places on the stack. That data can be anything — a message about a future price, an oracle attestation, a commitment produced by a counterparty in a channel protocol. On its own, CSFS is not a covenant; it is a delegation and attestation primitive. Its power in this pairing comes from what it lets scripts do in combination with CTV: verify that an off-chain party has authorized a specific piece of state, then use CTV to constrain the on-chain settlement of that state.
We have to be honest about a research gap here. The precise mechanics of how CSFS composes with CTV to produce, say, an LN-Symmetry-style channel or a more efficient Ark round were not fleshed out in the source material we worked from. What is clear is that CSFS is included in the “first step” package specifically because CTV alone does not close the design gap that Lightning and Ark builders care most about. Readers who want to trace those constructions in detail should go to the Delving Bitcoin thread and the referenced BIPs directly.
What CTV unlocks for BTCFi
The clearest way to see why builders are pushing this is to walk through the concrete constructions that CTV materially improves.
Vaults
A Bitcoin vault, in the sense the term has come to acquire, is a cold-storage scheme where any spend from cold must first pass through a time-locked intermediate address. During the delay window, the vault owner can observe the pending spend and, if it is unauthorized, invoke a recovery clawback that redirects funds to a safer key. This is the closest thing Bitcoin has to a native answer to key compromise.
Today, vaults are built with ephemeral keys and presigned transactions. The owner generates a temporary keypair, signs the vault’s spend paths with it, and then destroys the private key. The security of the vault then rests on the assumption that the ephemeral key was in fact deleted and never leaked before deletion. Bitcoin Optech describes this construction as “fragile at best,” which is the polite version of the practitioner view. Verifying key deletion in a way that is auditable and repeatable is a real operational problem, and the class of people willing to run such a scheme with meaningful capital is small.
With CTV — and BIP-345’s OP_VAULT builds on CTV for exactly this reason — the presigned-transaction dance is replaced by a covenant. The vault output commits to the shape of the delayed-spend transaction directly in consensus. No ephemeral key exists to leak. No trusted deletion is required. The vault becomes a stateless, replicable construction that a wallet can produce deterministically from public parameters.
Joinpools and channel factories
Constructions that pool many users’ funds into a single UTXO and let them exit or restructure independently — joinpools, channel factories, and their variants — depend on being able to renegotiate off-chain state without going through two full rounds of interactive signing every time. Optech notes that CTV cuts the signing rounds required for state transitions in these constructions from two to one. That sounds like an implementation detail; it is actually a scaling and liveness change. A construction that requires all N participants to be online for two rounds fails half as often, in the limit, if it only requires one — and the failure modes of these constructions are usually worse than the happy path suggests.
Discreet log contracts
DLCs are how Bitcoin does oracle-attested contracts today. A single DLC with, say, BTC/USD payoffs rounded to the nearest dollar can involve more than ten thousand potential outcomes, per Optech, each requiring its own signature adaptor that the counterparties must create, exchange, verify, and store. CTV replaces that per-outcome adaptor with a template. The setup cost of a large DLC drops by roughly the size of the outcome space, which for practical contracts is one to two orders of magnitude.
Congestion control and batching
CTV also enables a specific fee-market construction: an exchange or custodian can commit onchain to a single template output that, when later unrolled, pays out to many recipients. During congestion, the commitment is cheap; the unroll happens when fees permit. This does not create new capacity, but it lets large actors decouple the timing of user-facing settlement from the timing of onchain confirmation, which changes the demand curve for blockspace during spikes.
The BitVM path is worth mentioning separately. BitVM2 is already live in production, powering Citrea’s mainnet bridge without any soft fork. What covenants would offer is not enablement but cost reduction: current BitVM constructions burn substantial script bytes emulating primitives that CTV+CSFS would provide directly. The claim from proponents is that covenants make trust-minimized bridges cheaper, not that they make them possible for the first time.
The minimalist bet versus OP_CAT’s design space
CTV+CSFS is not the only covenant proposal on the table. The most-discussed alternative is OP_CAT, a four-byte opcode that simply concatenates the top two items on the stack. It was part of the original Bitcoin scripting language and was disabled in 2010 over denial-of-service concerns tied to unbounded stack growth. OP_CAT was assigned BIP number 347 in 2024, which is a signal that it has cleared the process bar of technical seriousness, not a signal that it is close to activation.
The design philosophy gap between the two camps is real. CTV is a specific, purpose-built opcode: it does one thing (commit to a template hash), and it does it in a way that structurally rules out recursion. OP_CAT is a primitive: it does one very small thing (concatenate bytes), but that primitive, combined with Taproot’s Schnorr signatures, enables script introspection — the ability of a script to reason about the transaction that contains it — which in turn enables recursive covenants and general state machines. StarkWare has published a proof-of-concept OP_CAT bridge covenant demonstrating trust-minimized Bitcoin-to-L2 bridging without a federated multisig. That kind of construction is not available under CTV+CSFS.
The tradeoff, then, is between two positions that are both internally coherent.
The CTV+CSFS position is that covenants should be added in the smallest possible increments, that recursion is a distinct escalation, and that the fungibility concern raised against recursive covenants — the theoretical possibility of coins permanently locked into restrictive scripts — is severe enough that it should be handled as its own debate, not tucked inside a general-purpose primitive. Proponents accept that this means several BTCFi constructions will remain out of reach.
The OP_CAT position is that the recursive-covenant concern is largely theoretical, that weaker forms of restriction already exist (multisig, timelocks, hashlocks), and that adding general introspection is a one-time protocol change that opens far more design space than a series of narrow opcodes ever will. The DoS concerns that motivated OP_CAT’s disabling in 2010, this camp argues, no longer apply given the script size limits Taproot introduced. We flag the “no longer apply” claim as contested; it is asserted more often than it is proven in the material we reviewed.
There is a third position, held mostly by Bitcoin Core contributors who have been vocal skeptics: that the covenant debate as a whole is premature, that neither proposal has accumulated the review-years that a consensus change warrants, and that Bitcoin’s scripting culture — which treats every new opcode as attack surface — should default to no unless the case for yes is overwhelming. This position does not require a technical objection to CTV specifically. It requires only a high prior against consensus changes.
The June 2025 letter and the 2026 activation plan
In June 2025, according to reporting we could not fully verify from primary sources within our research pack, an open letter was published calling for the activation of CTV+CSFS. The topic brief cites approximately 66 signatories including named cryptographers and Lightning developers, but the specific list, exact wording, and full argument of the letter are not directly accessible from the sources we worked with. We are naming this as a gap rather than reciting a list of signatories we cannot verify. What we can say is that the letter existed, that it was covered as a significant industry event, and that its purpose was to demonstrate developer consensus around the minimal covenant package as a first step.
The response from Bitcoin Core contributors, per the topic brief, was pushback rather than endorsement. Again, we do not have direct access to the specific technical objections raised — the Delving Bitcoin thread that hosts the substantive debate was only partially readable in our source material — and we are not going to invent them. What is clear from the shape of the debate is that no faction inside Core has moved to merge CTV+CSFS activation logic into the Core codebase itself.
This is where the 2026 timeline gets interesting. According to a synthesis published in April 2026, the concrete deployment parameters being proposed for an out-of-Core activation client are:
- Start time: March 30, 2026
- Timeout: March 30, 2027
- Minimum activation height: approximately May 2027
- Signaling threshold: 90% of miners over a 2016-block period
We treat these numbers as proposed parameters from a secondary source, not finalized consensus. But if they hold, this would be the first concrete soft-fork timeline Bitcoin has produced since Taproot. The mechanism is BIP9-style miner signaling: over each 2016-block window, miners can set a bit in their block versions to signal readiness. If 90% signal within the window, the fork locks in and activates at the minimum activation height.
The out-of-Core dimension is the load-bearing part of the plan. Because Core has not merged the activation logic, the signaling and activation code would ship in an alternative client — a Bitcoin implementation that follows all existing consensus rules but adds CTV+CSFS as a new rule at the minimum activation height, provided the miner signaling threshold has been met. Nodes running Core would remain valid so long as no CTV transaction is mined. If CTV activates and Core nodes reject a CTV-committing block, a chain split occurs.
Governance stakes: what an out-of-Core activation would signal
Bitcoin’s consensus process has no formal governance body. In practice, the norm has been that Bitcoin Core’s maintainers hold a soft veto: changes that Core will not merge do not activate. The SegWit UASF of 2017 was the last serious challenge to that norm, and even it ultimately routed through Core’s codebase; the UASF client (BIP148) was a fork of Core with modified activation logic, and SegWit was already in Core by the time the UASF pressure peaked.
An out-of-Core activation for CTV+CSFS would be a stronger challenge to the Core-veto norm than SegWit UASF was. The alternative client would carry activation code that Core maintainers have explicitly declined to adopt. If miners signal above 90% and the fork activates, either Core would need to merge CTV+CSFS to keep its users on the majority chain — which would establish a precedent that a sufficiently coordinated developer coalition plus miner supermajority can force Core’s hand — or Core would need to explicitly reject the fork and accept a chain split, which is a much larger break with the assumption that Bitcoin has a single canonical implementation.
There is a legitimate argument that this is healthy. Bitcoin’s upgrade process being effectively frozen since 2021 is not a design outcome anyone chose; it is an equilibrium that emerged from the difficulty of coordinating consensus changes without formal governance. Forcing the question — either activate or explicitly reject — produces information that a permanent stalemate does not.
There is also a legitimate argument that this is dangerous. The 90% miner signaling threshold is a floor, not a proof of user consent. Taproot’s activation had far broader visible support across users, businesses, and developers than CTV currently does. A soft fork that activates on a bare miner supermajority against Core objection could set a precedent that is exploitable by future coalitions with narrower aims — and covenants are exactly the class of change where the space of “narrower aims” is large.
Neither argument is decisive on its own. The empirical question is whether the developer coalition behind the letter can produce enough surrounding infrastructure — economic node support, wallet integration commitments, exchange readiness — to make the 90% miner signal look like ratification rather than a captured signal. As of the sources we reviewed, that surrounding infrastructure was still being assembled.
Remaining objections
We would be dishonest to imply the technical objections have been resolved. Three are worth naming even without full sourcing.
The first is the TxWithhold concern, explored by Gleb Naumenko in a BitMEX article referenced in the Delving Bitcoin thread. Covenants can be used to construct scripts that pay miners to withhold specific transactions from blocks. The severity depends on how easy such constructions become and how tolerant the fee market is; the concern is not that covenants introduce transaction withholding, but that they may make it substantially cheaper to bribe for. This has not, to our knowledge, been formally analyzed in the specific CTV+CSFS context in a way that resolves the debate.
The second is the complexity budget critique. Every new opcode expands the surface area of consensus code and creates new interactions with existing script primitives. Bitcoin’s development culture treats this expansion as costly by default. The CTV+CSFS package is narrow, but it is not free, and the reviewer-hours required to audit interactions with Taproot, sighash flags, and future proposals are non-trivial.
The third is the first-step problem. If CTV+CSFS activates, does that make the OP_CAT debate easier or harder? Proponents argue easier: the community will have proved it can ship a soft fork, and the design space beyond CTV can be evaluated on its own merits. Skeptics argue harder: activation of a narrow covenant will consume the political capital that would otherwise be available for a more ambitious proposal, and Bitcoin will be left with a partial covenant that is inadequate for the constructions OP_CAT would have enabled. Both are plausible. The historical evidence is thin because Bitcoin has not shipped an upgrade since 2021.
Implications for BTCFi
For BTCFi builders, the practical question is how to plan capital and roadmap allocation against the uncertainty. Three orientations seem defensible.
The first is to build against the current script set. BitVM2 in production on Citrea shows that meaningful trust-minimization is achievable without any new opcode, at the cost of substantially higher onchain footprint. Teams that need to ship in 2026~2027 cannot condition their roadmap on activation.
The second is to build against CTV+CSFS as a soft target. Vault products, channel-factory-based venues, and DLC-heavy applications benefit disproportionately from activation, and their designs can be structured so that a covenant-aware version is a clean upgrade from a presigned-transaction version. The downside is that the presigned-transaction version remains fragile, and users bear that fragility until activation.
The third is to build against the deeper OP_CAT design space, on the assumption that once one covenant activates the second becomes politically easier. This is a longer bet. It also depends on a chain of counterfactuals — CTV activation, subsequent OP_CAT debate, activation of OP_CAT itself — each of which is contingent.
The open questions we would watch through the rest of 2026 and into 2027 are narrow and answerable. Does the alternative client ship, and does Core respond with its own signaling logic or with explicit rejection? What is miner signaling behavior in the first 2016-block window after the March 2026 start? Do the specific technical objections from Core contributors get published in a form that can be evaluated, or does the debate remain diffuse? And does the surrounding coalition — wallets, exchanges, custodians — publicly commit before the signaling window opens, or after?
If the answer to those questions is “the alternative client ships, miners signal above 90%, and Core merges the change in response,” Bitcoin will have discovered a new upgrade path, and BTCFi will have a substantially different design space to build against within eighteen months. If the answer is “the client ships, signaling fails, and the debate resets,” we will have confirmed that Bitcoin’s upgrade process is not merely conservative but structurally blocked, and BTCFi’s roadmap will need to assume script stasis for the foreseeable future. Both outcomes are informative. The one that would be worst is the third: the client ships, miners signal, and the resulting chain split reveals that Bitcoin’s governance was less coherent than any faction assumed. That outcome is not the most likely, but it is the one that most rewards paying attention to now.
들어가며
비트코인은 2021년 11월 탭루트(Taproot) 이후 단 한 차례의 컨센서스 변경도 이루어지지 않았다. 같은 기간 동안 다른 주요 스마트 컨트랙트 체인들은 실행 레이어를 수차례 개선해왔다. 비트코인은 설계상 그러지 않았고, 이로 인해 BTCFi 빌더 커뮤니티 내부에 쌓인 불만이 이제 구체적이고 최소한의 업그레이드를 요구하는 조직적인 움직임으로 표출되고 있다. 바로 OP_CHECKTEMPLATEVERIFY(CTV)와 OP_CHECKSIGFROMSTACK(CSFS)의 조합이다.
제안의 범위는 좁다. CTV는 코인이 지출될 트랜잭션의 정확한 형태를 사전에 커밋할 수 있게 한다. CSFS는 스크립트가 스택에서 꺼낸 임의의 데이터에 대한 서명을 검증할 수 있게 한다. 둘 다 재귀(recursion)를 도입하지 않으며, OP_CAT 지지자들이 원하는 완전한 범용 프로그래밍 기능을 제공하지도 않는다. 그럼에도 불구하고 이 둘을 결합하면, BTCFi 빌더들이 점점 더 불안정한 사전서명 트랜잭션 방식으로 구현해왔던 구조물들 — 비수탁형 볼트, 더 효율적인 조인풀과 채널 팩토리, 더 저렴한 이산 로그 컨트랙트, 그리고 라이트닝과 Ark를 위한 더 간결한 경로 — 을 가능하게 한다.
우리에게 흥미로운 질문은 CTV+CSFS가 기술적으로 건전한가가 아니다. 그 논쟁은 이미 충분히 소진됐고, 제안은 수년간 공개 상태였다. 흥미로운 질문은 이처럼 범위가 좁은 업그레이드가 왜 멈춰 있는지, 그리고 2025년 중반의 공개서한과 제안된 2026~2027년 Core 외부 활성화 타임라인이 비트코인의 컨센서스 의사결정 방식에 무엇을 의미하는지다. 만약 비트코인 Core가 아닌 클라이언트를 통해 활성화가 성공한다면, SegWit UASF 시대 이후 최초의 선례가 되며 향후 프로토콜 변경이 협상되는 방식을 근본적으로 바꿀 것이다. 실패한다면, 비트코인의 업그레이드 경로가 사실상 동결되어 있음을 확인하는 것이며 BTCFi 빌더들은 이에 맞게 계획을 세워야 한다.
코브넌트란 무엇인가
비트코인 스크립트 맥락에서 코브넌트(covenant)란, UTXO를 지출할 수 있는지 여부뿐만 아니라 지출 트랜잭션이 어떤 형태여야 하는지까지 제약하는 지출 조건이다. 오늘날 스크립트는 단일 시제의 질문에 답한다: 주어진 위트니스 데이터로 이 지출이 지금 승인되었는가? 코브넌트는 시제를 확장한다: 이 지출이 만들어내는 트랜잭션이 우리가 이전에 커밋한 형태와 일치하는가?
BIP-119로 명세된 CTV는 이를 가능한 한 가장 제한적인 방식으로 구현한다. UTXO가 CTV 스크립트에 잠기면, 해당 옵코드는 지출 트랜잭션의 특정 필드들을 해시하여 스크립트에 내장된 템플릿 해시와 비교한다. Bitcoin Optech에 따르면, 커밋되는 필드는 트랜잭션 버전, 록타임, 스크립트시그, 인풋 수, 시퀀스 값, 아웃풋 수, 아웃풋 자체, 그리고 지출 인풋의 인덱스다. 이 중 하나라도 템플릿과 다르면 지출은 실패한다.
이 설계의 두 가지 특성은 짚고 넘어갈 만하다. 첫째, CTV는 아웃풋에는 커밋하지만 인풋에는 커밋하지 않는다 — 구체적으로는 인풋의 txid에 커밋하지 않는다. 이 덕분에 동일한 템플릿을 서로 다른 자금 트랜잭션에 재사용할 수 있으며, 이것이 볼트와 혼잡 제어 구조를 실용적으로 만드는 핵심이다. 둘째, CTV는 구조적으로 비재귀적이다. 템플릿 해시는 스크립트 내의 고정값이므로, 지출 트랜잭션으로부터 계산될 수 없다. CTV 아웃풋은 다음 홉을 강제할 수 있지만, 그 다음 홉은 구체적으로 사전 명세된 트랜잭션이다 — 스택의 무언가에서 파생된 템플릿을 가진 CTV 아웃풋이 될 수 없다. 이 구조적 비재귀성이 CTV가 영구적으로 제한된 코인을 만들 수 없다는 주장의 전체 근거다.
CSFS는 다른 종류의 프리미티브다. 비트코인의 기존 OP_CHECKSIG가 현재 트랜잭션에 대한 서명을 검증하는 반면, CSFS는 지출자가 스택에 올려놓은 임의 데이터에 대한 서명을 검증한다. 그 데이터는 무엇이든 될 수 있다 — 미래 가격에 관한 메시지, 오라클의 증명, 채널 프로토콜에서 거래상대방이 생성한 커밋먼트. CSFS 자체는 코브넌트가 아니라 위임 및 증명 프리미티브다. 이 조합에서 그 힘은 CTV와 결합했을 때 스크립트가 할 수 있는 것에서 나온다: 오프체인 당사자가 특정 상태를 승인했음을 검증하고, CTV를 통해 그 상태의 온체인 정산을 제약하는 것이다.
여기서 우리가 인지하는 연구 공백에 대해 솔직해야 한다. CSFS가 CTV와 어떻게 결합하여 LN-Symmetry 스타일의 채널이나 더 효율적인 Ark 라운드를 만들어내는지의 정확한 메커니즘은, 우리가 참고한 자료에서 충분히 다루어지지 않았다. 분명한 것은 CSFS가 “첫 번째 단계” 패키지에 포함된 이유가 CTV만으로는 라이트닝과 Ark 빌더들이 가장 중요하게 여기는 설계 격차를 해소하지 못하기 때문이라는 점이다. 이러한 구조를 상세히 추적하고 싶은 독자는 Delving Bitcoin 스레드와 참조된 BIP를 직접 확인하길 권한다.
CTV가 BTCFi에 열어주는 것
빌더들이 이 제안을 밀어붙이는 이유를 가장 명확하게 이해하려면, CTV가 실질적으로 개선하는 구체적인 구조물들을 하나씩 살펴보는 것이 좋다.
볼트
이 용어가 갖게 된 의미에서 비트코인 볼트란, 콜드 스토리지에서의 모든 지출이 먼저 타임락이 걸린 중간 주소를 거쳐야 하는 콜드 스토리지 방식이다. 지연 시간 동안 볼트 소유자는 대기 중인 지출을 관찰하고, 만약 승인되지 않은 것이라면 자금을 더 안전한 키로 돌려보내는 클로백(clawback)을 발동할 수 있다. 이것이 키 탈취에 대한 비트코인의 네이티브 답변에 가장 가까운 것이다.
현재 볼트는 임시 키와 사전서명 트랜잭션으로 구축된다. 소유자는 임시 키쌍을 생성하고, 볼트의 지출 경로에 서명한 뒤 개인 키를 폐기한다. 볼트의 보안은 임시 키가 실제로 삭제되었고 삭제 전에 유출되지 않았다는 가정에 전적으로 의존한다. Bitcoin Optech은 이 구조를 “기껏해야 취약하다”고 묘사하는데, 이는 실무자 관점을 정중하게 표현한 것이다. 감사 가능하고 반복 가능한 방식으로 키 삭제를 검증하는 것은 실제 운영상의 문제이며, 상당한 자본으로 이런 방식을 운용하려는 사람의 수는 매우 적다.
CTV를 사용하면 — 그리고 BIP-345의 OP_VAULT가 바로 이 이유로 CTV를 기반으로 구축된다 — 사전서명 트랜잭션의 복잡한 과정이 코브넌트로 대체된다. 볼트 아웃풋이 지연 지출 트랜잭션의 형태를 컨센서스 차원에서 직접 커밋한다. 유출될 임시 키가 존재하지 않으며, 신뢰 기반의 삭제도 필요하지 않다. 볼트는 공개 파라미터로부터 결정론적으로 생성할 수 있는 무상태(stateless)의 재현 가능한 구조물이 된다.
조인풀과 채널 팩토리
여러 사용자의 자금을 하나의 UTXO에 통합하고 독립적으로 출금하거나 재구성할 수 있게 하는 구조 — 조인풀, 채널 팩토리, 그리고 그 변형들 — 는 매번 두 번의 완전한 인터랙티브 서명 라운드 없이도 오프체인 상태를 재협상할 수 있어야 한다. Optech는 CTV가 이러한 구조에서 상태 전환에 필요한 서명 라운드를 두 번에서 한 번으로 줄인다고 지적한다. 구현 세부사항처럼 들리지만, 실제로는 확장성과 라이브니스(liveness)의 변화다. N명의 참여자 전원이 두 라운드 동안 온라인 상태여야 하는 구조는 한 라운드만 필요하다면 극한적으로 절반 빈도로 실패하며 — 이러한 구조의 실패 양상은 일반적으로 정상 경로가 시사하는 것보다 훨씬 나쁘다.
이산 로그 컨트랙트
DLC(Discreet Log Contract)는 현재 비트코인이 오라클 증명 컨트랙트를 처리하는 방식이다. 예를 들어 BTC/USD 페이오프를 1달러 단위로 반올림한 단일 DLC는 Optech에 따르면 만 개 이상의 잠재적 결과를 가질 수 있으며, 각각 거래상대방들이 생성, 교환, 검증, 저장해야 하는 고유한 서명 어댑터가 필요하다. CTV는 이 결과별 어댑터를 템플릿으로 대체한다. 대형 DLC의 설정 비용이 결과 공간의 크기만큼 감소하는데, 실제 컨트랙트의 경우 이는 1~2자릿수 규모의 감소다.
혼잡 제어와 배치 처리
CTV는 특정 수수료 시장 구조도 가능하게 한다: 거래소나 커스터디언이 나중에 펼쳐지면 여러 수신자에게 지급되는 단일 템플릿 아웃풋을 온체인에 커밋할 수 있다. 혼잡 시에는 커밋이 저렴하고, 수수료가 허용할 때 펼침이 이루어진다. 이것이 새로운 용량을 만들어내지는 않지만, 대형 참여자들이 사용자 대면 정산의 타이밍을 온체인 확인 타이밍에서 분리할 수 있게 하여, 급등 시 블록스페이스에 대한 수요 곡선을 변화시킨다.
BitVM 경로는 별도로 언급할 가치가 있다. BitVM2는 이미 프로덕션에서 라이브이며, 어떠한 소프트 포크 없이 Citrea의 메인넷 브릿지를 구동하고 있다. 코브넌트가 제공하는 것은 가능성이 아니라 비용 절감이다: 현재 BitVM 구조는 CTV+CSFS가 직접 제공할 프리미티브를 에뮬레이션하는 데 상당한 스크립트 바이트를 소모한다. 지지자들의 주장은 코브넌트가 신뢰 최소화 브릿지를 더 저렴하게 만든다는 것이지, 처음으로 가능하게 한다는 것이 아니다.
최소주의적 접근 대 OP_CAT의 설계 공간
CTV+CSFS가 테이블 위의 유일한 코브넌트 제안은 아니다. 가장 많이 논의되는 대안은 OP_CAT으로, 스택의 상위 두 항목을 단순히 연결하는 4바이트 옵코드다. 이것은 원래 비트코인 스크립팅 언어의 일부였으나 무제한 스택 증가와 관련된 서비스 거부(DoS) 우려로 2010년에 비활성화되었다. OP_CAT은 2024년에 BIP 번호 347을 부여받았는데, 이는 기술적 심각성의 프로세스 기준을 통과했다는 신호이지 활성화에 가깝다는 신호가 아니다.
두 진영 간의 설계 철학 차이는 실재한다. CTV는 특정 목적을 위해 설계된 옵코드다: 하나의 일(템플릿 해시에 커밋)을 하되, 재귀를 구조적으로 배제하는 방식으로 한다. OP_CAT은 프리미티브다: 매우 작은 한 가지 일(바이트 연결)을 하지만, 이 프리미티브는 탭루트의 슈노르 서명과 결합되어 스크립트 인트로스펙션 — 스크립트가 자신을 포함하는 트랜잭션에 대해 추론하는 능력 — 을 가능하게 하며, 이는 재귀적 코브넌트와 범용 상태 머신으로 이어진다. StarkWare는 연합 멀티시그 없이 신뢰 최소화 비트코인-L2 브릿징을 보여주는 OP_CAT 브릿지 코브넌트 개념 증명을 발표했다. 이런 종류의 구조는 CTV+CSFS로는 불가능하다.
따라서 트레이드오프는 각자 내부적으로 일관성이 있는 두 입장 사이에 있다.
CTV+CSFS 입장은 코브넌트를 가능한 한 작은 단위로 추가해야 하며, 재귀는 별개의 에스컬레이션이고, 재귀적 코브넌트에 제기된 대체가능성(fungibility) 우려 — 코인이 제한적 스크립트에 영구히 잠길 이론적 가능성 — 는 범용 프리미티브 안에 묻어버리지 않고 독자적인 논쟁으로 다뤄야 할 만큼 심각하다는 것이다. 지지자들은 이것이 여러 BTCFi 구조를 여전히 도달 불가능한 상태로 남겨둔다는 점을 인정한다.
OP_CAT 입장은 재귀적 코브넌트 우려가 대체로 이론적이며, 더 약한 형태의 제한(멀티시그, 타임락, 해시락)이 이미 존재하고, 범용 인트로스펙션 추가는 일련의 좁은 옵코드들이 결코 열지 못할 훨씬 더 넓은 설계 공간을 열어주는 일회성 프로토콜 변경이라는 것이다. 2010년 OP_CAT 비활성화를 촉발한 DoS 우려는 탭루트가 도입한 스크립트 크기 제한으로 인해 더 이상 적용되지 않는다고 이 진영은 주장한다. “더 이상 적용되지 않는다”는 주장은 논쟁의 여지가 있다고 우리는 표시한다; 우리가 검토한 자료에서 이것은 증명되기보다 더 자주 단정적으로 주장된다.
세 번째 입장이 있는데, 주로 목소리 큰 회의론자였던 비트코인 Core 기여자들이 취하는 것이다: 코브넌트 논쟁 전체가 시기상조이며, 어느 제안도 컨센서스 변경이 마땅히 받아야 할 수년간의 검토를 축적하지 못했고, 새로운 옵코드를 모두 공격 표면으로 취급하는 비트코인의 스크립팅 문화는 찬성 사례가 압도적이지 않은 한 기본적으로 반대해야 한다는 것이다. 이 입장은 CTV에 대한 기술적 이의를 필요로 하지 않는다. 컨센서스 변경에 대해 높은 사전 거부 성향만 필요로 한다.
2025년 6월 서한과 2026년 활성화 계획
우리 연구 자료 내에서 1차 출처로 완전히 검증하지 못한 보도에 따르면, 2025년 6월에 CTV+CSFS 활성화를 촉구하는 공개서한이 발표되었다. 토픽 브리프에는 이름이 명시된 암호학자들과 라이트닝 개발자들을 포함해 약 66명의 서명자가 언급되어 있으나, 구체적인 명단, 정확한 문구, 서한의 전체 논거는 우리가 작업한 자료에서 직접 접근할 수 없었다. 검증할 수 없는 서명자 명단을 그대로 인용하는 대신 이것을 공백으로 명시한다. 우리가 말할 수 있는 것은 서한이 존재했고, 중요한 업계 이벤트로 다뤄졌으며, 그 목적이 최소 코브넌트 패키지를 첫 번째 단계로 삼는 것에 대한 개발자 컨센서스를 보여주기 위함이었다는 것이다.
토픽 브리프에 따르면 비트코인 Core 기여자들의 반응은 지지가 아닌 반박이었다. 역시 우리는 제기된 구체적인 기술적 이의에 직접 접근하지 못했다 — 실질적인 논쟁이 이루어지는 Delving Bitcoin 스레드는 우리 자료에서 부분적으로만 확인 가능했다 — 그리고 우리는 이것을 만들어내지 않을 것이다. 논쟁의 형태로부터 명확한 것은, Core 내부 어떤 진영도 CTV+CSFS 활성화 로직을 Core 코드베이스 자체에 병합하는 방향으로 나아가지 않았다는 것이다.
이 지점에서 2026년 타임라인이 흥미로워진다. 2026년 4월에 발표된 종합 보고서에 따르면, Core 외부 활성화 클라이언트에 제안된 구체적인 배포 파라미터는 다음과 같다:
- 시작 시간: 2026년 3월 30일
- 만료 시간: 2027년 3월 30일
- 최소 활성화 높이: 약 2027년 5월
- 시그널링 임계값: 2016-블록 기간 동안 채굴자 90%
우리는 이 수치들을 2차 출처의 제안된 파라미터로 취급하며, 확정된 컨센서스로 보지 않는다. 그러나 이 수치들이 유지된다면, 이것은 비트코인이 탭루트 이후 처음으로 내놓은 구체적인 소프트 포크 타임라인이 될 것이다. 메커니즘은 BIP9 스타일의 채굴자 시그널링이다: 각 2016-블록 창에서 채굴자들은 블록 버전의 비트를 설정하여 준비 완료를 신호할 수 있다. 창 내에서 90%가 신호하면 포크가 잠기고 최소 활성화 높이에서 활성화된다.
이 계획의 핵심은 Core 외부라는 점이다. Core가 활성화 로직을 병합하지 않았기 때문에, 시그널링 및 활성화 코드는 대안 클라이언트로 출시될 것이다 — 기존 컨센서스 규칙을 모두 따르지만, 채굴자 시그널링 임계값이 충족된 경우 최소 활성화 높이에서 CTV+CSFS를 새로운 규칙으로 추가하는 비트코인 구현체다. Core를 실행하는 노드는 CTV 트랜잭션이 채굴되지 않는 한 유효하게 남는다. CTV가 활성화되어 Core 노드가 CTV를 커밋하는 블록을 거부하면 체인 분리가 발생한다.
거버넌스 쟁점: Core 외부 활성화가 시사하는 것
비트코인의 컨센서스 프로세스에는 공식적인 거버넌스 기구가 없다. 실질적으로는 비트코인 Core 관리자들이 소프트 거부권을 쥔다는 관행이 자리잡고 있다: Core가 병합하지 않는 변경은 활성화되지 않는다. 2017년 SegWit UASF는 그 관행에 대한 마지막 심각한 도전이었는데, 그조차 결국 Core 코드베이스를 통해 라우팅되었다; UASF 클라이언트(BIP148)는 수정된 활성화 로직을 가진 Core 포크였고, SegWit은 UASF 압력이 정점에 달했을 때 이미 Core에 있었다.
CTV+CSFS에 대한 Core 외부 활성화는 SegWit UASF보다 더 강한 Core 거부권 관행에 대한 도전이 될 것이다. 대안 클라이언트는 Core 관리자들이 채택하기를 명시적으로 거부한 활성화 코드를 담게 된다. 채굴자들이 90% 이상 신호하고 포크가 활성화된다면, 두 가지 중 하나가 발생한다: Core가 사용자들을 다수 체인에 유지하기 위해 CTV+CSFS를 병합해야 하는데, 이는 충분히 조율된 개발자 연합과 채굴자 초다수결이 Core를 강제할 수 있다는 선례를 세우거나 — 혹은 Core가 명시적으로 포크를 거부하고 체인 분리를 감수해야 하는데, 이는 비트코인에 단일한 정식 구현체가 있다는 가정과의 훨씬 더 큰 단절이다.
이것이 건전하다는 합당한 주장이 있다. 비트코인의 업그레이드 프로세스가 사실상 2021년 이후 동결된 것은 누군가가 의도한 설계 결과가 아니라, 공식 거버넌스 없이 컨센서스 변경을 조율하는 어려움에서 비롯된 균형이다. 문제를 정면으로 제기하는 것 — 활성화하거나 명시적으로 거부하거나 — 은 영구적인 교착 상태가 제공하지 않는 정보를 생산한다.
또한 이것이 위험하다는 합당한 주장도 있다. 90% 채굴자 시그널링 임계값은 최저선이지, 사용자 동의의 증명이 아니다. 탭루트의 활성화는 CTV가 현재 갖고 있는 것보다 사용자, 기업, 개발자 전반에 걸쳐 훨씬 더 광범위하고 가시적인 지지를 받았다. Core의 반대를 무릅쓰고 채굴자 초다수결만으로 활성화된 소프트 포크는 더 좁은 목적을 가진 미래의 연합들이 악용할 수 있는 선례를 세울 수 있으며 — 그리고 코브넌트는 정확히 “더 좁은 목적”의 공간이 큰 변경의 종류다.
어느 주장도 단독으로는 결정적이지 않다. 경험적 질문은 서한 뒤에 있는 개발자 연합이 90% 채굴자 신호가 포획된 신호가 아닌 비준처럼 보이게 하는 충분한 주변 인프라 — 경제적 노드 지지, 지갑 통합 약속, 거래소 준비성 — 를 만들어낼 수 있느냐이다. 우리가 검토한 자료 기준으로, 그 주변 인프라는 여전히 조립 중이었다.
남은 이의들
기술적 이의들이 해결되었다고 암시하는 것은 솔직하지 못한 일이다. 충분한 출처 없이도 세 가지는 언급할 가치가 있다.
첫 번째는 TxWithhold 우려로, Delving Bitcoin 스레드에서 참조된 BitMEX 기사에서 Gleb Naumenko가 탐구했다. 코브넌트는 채굴자들에게 블록에서 특정 트랜잭션을 보류하는 대가를 지급하는 스크립트를 구성하는 데 사용될 수 있다. 심각성은 이러한 구조가 얼마나 쉬워지는지와 수수료 시장이 얼마나 관용적인지에 달려있다; 우려는 코브넌트가 트랜잭션 보류를 도입한다는 것이 아니라 이에 대한 뇌물 비용을 실질적으로 낮출 수 있다는 것이다. 우리가 아는 한, 이것은 논쟁을 해소하는 방식으로 CTV+CSFS의 맥락에서 공식적으로 분석된 적이 없다.
두 번째는 복잡성 예산 비판이다. 새로운 옵코드는 컨센서스 코드의 표면적을 확장하고 기존 스크립트 프리미티브들과의 새로운 상호작용을 만든다. 비트코인의 개발 문화는 이 확장을 기본적으로 비용으로 취급한다. CTV+CSFS 패키지는 좁지만 무비용이 아니며, 탭루트, 시그해시 플래그, 미래 제안들과의 상호작용을 감사하는 데 필요한 검토자-시간은 적지 않다.
세 번째는 첫 번째 단계 문제다. CTV+CSFS가 활성화된다면, OP_CAT 논쟁이 더 쉬워질까 어려워질까? 지지자들은 더 쉬워진다고 주장한다: 커뮤니티가 소프트 포크를 출시할 수 있음을 증명했을 것이고, CTV 너머의 설계 공간은 그 자체의 장점으로 평가될 수 있다. 회의론자들은 더 어려워진다고 주장한다: 좁은 코브넌트의 활성화는 더 야심찬 제안에 사용될 수 있었던 정치적 자본을 소진하게 되고, 비트코인은 OP_CAT이 가능했을 구조들에 부적합한 부분적 코브넌트를 갖게 될 것이라고. 둘 다 그럴듯하다. 역사적 증거는 빈약한데 비트코인이 2021년 이후 업그레이드를 출시한 적이 없기 때문이다.
BTCFi에 대한 시사점
BTCFi 빌더들에게 실질적인 질문은 불확실성에 맞서 자본과 로드맵 배분을 어떻게 계획할 것인가다. 세 가지 방향이 타당해 보인다.
첫 번째는 현재의 스크립트 집합을 기반으로 구축하는 것이다. Citrea에서 프로덕션 중인 BitVM2는 어떤 새로운 옵코드 없이도, 실질적으로 더 높은 온체인 풋프린트를 감수하면서 의미 있는 신뢰 최소화가 달성 가능함을 보여준다. 2026~2027년에 출시해야 하는 팀들은 로드맵을 활성화에 조건 지을 수 없다.
두 번째는 CTV+CSFS를 소프트 타겟으로 삼아 구축하는 것이다. 볼트 상품, 채널 팩토리 기반 플랫폼, DLC 중심 애플리케이션은 활성화로부터 불균형적으로 이익을 얻으며, 코브넌트 인식 버전이 사전서명 트랜잭션 버전으로부터의 깔끔한 업그레이드가 되도록 설계를 구조화할 수 있다. 단점은 사전서명 트랜잭션 버전이 취약한 채로 남으며, 활성화 전까지 사용자들이 그 취약성을 부담한다는 것이다.
세 번째는 하나의 코브넌트가 활성화되면 두 번째가 정치적으로 더 쉬워진다는 가정 하에 더 깊은 OP_CAT 설계 공간을 목표로 구축하는 것이다. 이것은 더 긴 베팅이다. 또한 각각이 조건부인 반사실들의 연쇄 — CTV 활성화, 이후 OP_CAT 논쟁, OP_CAT 자체의 활성화 — 에 의존한다.
2026년 나머지와 2027년에 걸쳐 우리가 주시할 열린 질문들은 좁고 답할 수 있다. 대안 클라이언트가 출시되는가, 그리고 Core는 자체 시그널링 로직으로 응답하는가 아니면 명시적 거부로 응답하는가? 2026년 3월 시작 이후 첫 2016-블록 창에서 채굴자 시그널링 행동은 어떠한가? Core 기여자들의 구체적인 기술적 이의가 평가 가능한 형태로 발표되는가, 아니면 논쟁이 계속 확산된 채로 남는가? 그리고 주변 연합 — 지갑, 거래소, 커스터디언 — 이 시그널링 창이 열리기 전에 공개적으로 약속하는가, 아니면 후에 하는가?
이 질문들에 대한 답이 “대안 클라이언트가 출시되고, 채굴자들이 90% 이상 신호하며, Core가 이에 응하여 변경을 병합한다”라면, 비트코인은 새로운 업그레이드 경로를 발견한 것이고 BTCFi는 18개월 이내에 구축할 수 있는 실질적으로 다른 설계 공간을 갖게 될 것이다. 답이 “클라이언트가 출시되고, 시그널링이 실패하며, 논쟁이 리셋된다”라면, 비트코인의 업그레이드 프로세스가 단순히 보수적인 것이 아니라 구조적으로 막혀 있음을 확인하게 되며, BTCFi의 로드맵은 예측 가능한 미래 동안 스크립트 정체를 가정해야 할 것이다. 두 결과 모두 유용한 정보를 제공한다. 가장 최악의 시나리오는 세 번째다: 클라이언트가 출시되고, 채굴자들이 신호하며, 결과적인 체인 분리가 어떤 진영도 가정했던 것보다 비트코인의 거버넌스가 덜 일관성 있었음을 드러내는 것이다. 이 결과가 가장 가능성 높은 것은 아니지만, 지금 당장 주의를 기울이는 것이 가장 중요한 결과다.
はじめに
ビットコインは、2021年11月のTaprootを最後にコンセンサスの変更を一切行っていない。同じ期間に、他のスマートコントラクト系主要チェーンは実行レイヤーを何度も刷新してきた。ビットコインは設計上そうしてこなかった。そしてこの状況に対するBTCFiビルダーコミュニティ内の苛立ちが、今や具体的な形を帯びた動きとして表面化している。それが、OP_CHECKTEMPLATEVERIFY（CTV）とOP_CHECKSIGFROMSTACK（CSFS）という最小限のアップグレードをペアで求める組織的な働きかけだ。
提案の内容は絞り込まれている。CTVはコインが使われる際のトランザクションの形状を、あらかじめスクリプト上にコミットできるようにする。CSFSはスタックから取り出した任意のデータに対する署名を、スクリプト側で検証できるようにする。どちらも再帰を導入しない。OP_CATの支持者が求める完全な汎用プログラマビリティも実現しない。にもかかわらず、両者を組み合わせることで、BTCFiビルダーがこれまで不安定なプリサインドトランザクションの仕組みで代替してきた一連の構成——ノンカストディアルのボールト、より効率的なジョインプールやチャネルファクトリー、安価なDiscreet Log Contract、LightningやArkのためのシンプルな実装経路——が解放される。
私たちにとって興味深い問いは、CTV+CSFSが技術的に正当かどうかではない。その議論はほぼ出尽くしており、提案は何年も前から公開されている。真に興味深いのは、これほど限定的なアップグレードがなぜ停滞しているのか、そして2025年中頃の公開書簡と2026~2027年に向けたCore外でのアクティベーション計画が、ビットコインのコンセンサス決定プロセスに何をもたらすのかという点だ。もしCoreではないクライアントを通じてアクティベーションが成功すれば、SegWit UASFの時代以来初めての先例となり、将来のプロトコル変更の交渉様式を塗り替えることになる。失敗すれば、ビットコインのアップグレード経路は事実上凍結されており、BTCFiビルダーはそれを前提に計画を立てるべきだということが確認される。
コベナントとは何か
ビットコインスクリプトの文脈では、コベナントとはUTXOを使えるかどうかだけでなく、使用するトランザクションがどのような形でなければならないかをも制約する使用条件を指す。現在のスクリプトが答えるのは単純な現在形の問いだ——「このwitness dataを前提にすると、この使用は今この瞬間に承認されているか？」コベナントはその問いを拡張する——「この使用によって生成されるトランザクションは、以前にコミットした形状と一致しているか？」
BIP-119として策定されたCTVは、この仕組みを可能な限り制限された方法で実装する。UTXOがCTVスクリプトにロックされると、そのオペコードは使用トランザクションから特定のフィールド群をハッシュ化し、スクリプトに埋め込まれたテンプレートハッシュと照合する。Bitcoin Optechによれば、コミット対象のフィールドはトランザクションバージョン、ロックタイム、scriptsigs、インプット数、sequence値、アウトプット数、アウトプット自体、そして使用インプットのインデックスだ。これらのいずれかがテンプレートと異なれば、その使用は失敗する。
この設計には、立ち止まって考えるべき特性が二つある。第一に、CTVはアウトプットにコミットするがインプットにはコミットしない——具体的には、インプットのtxidにはコミットしない。これにより同一テンプレートを異なるファンディングトランザクションにわたって再利用できる。ボールトや輻輳制御の構成が実用的になるのはこのためだ。第二に、CTVは構造上、非再帰的である。テンプレートハッシュはスクリプト内の固定値であり、使用トランザクション自体から計算されることはない。CTVアウトプットは次のホップの形を強制できるが、そのホップは具体的にあらかじめ指定されたトランザクションだ。スタック上の何かから導出されるテンプレートを持つCTVアウトプットにはなり得ない。この構造的な非再帰性こそが、CTVは永続的に制限されたコインを生み出せないという主張の根拠全体を成している。
CSFSは別のプリミティブだ。ビットコインの既存のOP_CHECKSIGが現在のトランザクションに対する署名を検証するのに対し、CSFSは使用者がスタックに置いた任意のデータに対する署名を検証する。そのデータは何でもよい——将来の価格に関するメッセージ、オラクルの証明、チャネルプロトコルにおいてカウンターパーティが生成したコミットメントなど。単独では、CSFSはコベナントではなく委任・証明のプリミティブだ。このペアリングにおけるCSFSの威力は、CTVと組み合わせることでスクリプトにできることの中にある——オフチェーンの当事者が特定の状態を承認したことを検証し、CTVでそのオンチェーン決済を制約する。
ここで一つのリサーチギャップを正直に認めなければならない。CSFSがCTVとどのように組み合わさって、たとえばLN-Symmetryスタイルのチャネルやより効率的なArkラウンドを生み出すのか、その正確なメカニズムは私たちが参照した資料には詳述されていない。明らかなのは、CTVだけではLightningやArkのビルダーが最も重視する設計上のギャップを埋められないため、CSFSが「第一ステップ」のパッケージに含まれているということだ。これらの構成の詳細を追いたい読者は、Delving Bitcoinのスレッドと参照されているBIPを直接参照してほしい。
CTVがBTCFiに解放するもの
ビルダーたちがこれを推進している理由を最も明確に理解するには、CTVが具体的に改善する構成を順に見ていくのがよい。
ボールト
現在この言葉が獲得してきた意味でのビットコインボールトとは、コールドストレージからの使用がすべて、タイムロックされた中間アドレスを必ず経由しなければならないスキームだ。遅延ウィンドウの間、ボールトの所有者は保留中の使用を監視し、もし無許可であれば、資金をより安全な鍵に転送するリカバリーのクローバックを発動できる。これはビットコインが鍵の漏洩に対して持つ最もネイティブな答えに近いものだ。
現在、ボールトは一時鍵とプリサインドトランザクションで構築されている。所有者は一時的な鍵ペアを生成し、ボールトの使用経路をその鍵で署名し、その後秘密鍵を破棄する。ボールトのセキュリティは、一時鍵が実際に削除されており、削除前に漏洩していないという前提に依存する。Bitcoin Optechはこの構成を「よくて脆弱」と表現しているが、これは実務家の見解を丁重に言い換えたものだ。監査可能かつ再現可能な形で鍵の削除を証明することは現実の運用上の問題であり、相当の資金でこのようなスキームを運用しようとする人々の層は狭い。
CTVを使えば——BIP-345のOP_VAULTがまさにこれを目的としてCTVの上に構築されているのだが——プリサインドトランザクションのやり取りはコベナントに置き換えられる。ボールトアウトプットが遅延使用トランザクションの形状を直接コンセンサス上にコミットする。漏洩する一時鍵は存在しない。信頼に基づく削除も不要だ。ボールトは、ウォレットが公開パラメータから決定論的に生成できる、ステートレスで再現可能な構成になる。
ジョインプールとチャネルファクトリー
多くのユーザーの資金を単一のUTXOにプールし、それぞれが独立して退出・再編できるようにする構成——ジョインプール、チャネルファクトリー、およびそれらの派生形——は、毎回インタラクティブな署名の全ラウンドを二往復こなすことなく、オフチェーンの状態を再交渉できることに依存している。Optechによれば、CTVはこれらの構成における状態遷移に必要な署名ラウンドを2回から1回に削減する。実装上の細部のように聞こえるが、実際にはスケーリングと活性度（liveness）に関わる変化だ。N人の参加者全員が2ラウンドの間オンラインである必要がある構成は、1ラウンドしか必要でなければ、極限的には半分の頻度でしか失敗しない——しかもこれらの構成の失敗モードは、ハッピーパスが示唆するよりも通常はずっと悪い。
Discreet Log Contract
DLC（Discreet Log Contract）は、ビットコインが今日オラクル証明付きコントラクトを行う方法だ。たとえばBTC/USDのペイオフを1ドル刻みで切り捨てた単一のDLCは、Optechによれば1万以上の潜在的な結果を含む場合があり、それぞれにカウンターパーティが作成・交換・検証・保存しなければならない署名アダプタが必要になる。CTVはそのアウトカムごとのアダプタをテンプレートに置き換える。大規模なDLCのセットアップコストは、結果空間の大きさに比例して削減される——実用的なコントラクトでは1〜2桁の削減になる。
輻輳制御とバッチ処理
CTVはまた、特定の手数料市場向けの構成も可能にする。取引所やカストディアンは、後で展開すると多数の受取人に支払いが行われる単一のテンプレートアウトプットを、オンチェーンにコミットできる。輻輳時はコミットが安く、展開は手数料が許す時に行う。これは新たなキャパシティを生み出すわけではないが、大規模なアクターがユーザー向けの決済タイミングをオンチェーン確認のタイミングから切り離せるようになり、スパイク時のブロックスペース需要曲線が変わる。
BitVMの経路については別途触れておく価値がある。BitVM2はすでに本番環境で稼働しており、ソフトフォークなしにCitreaのメインネットブリッジを動かしている。コベナントがもたらすのは実現可能性ではなくコスト削減だ。現在のBitVM構成は、CTV+CSFSが直接提供するプリミティブをスクリプトバイトで模倣するために相当のバイト数を消費している。支持者の主張は、コベナントがトラストミニマイズされたブリッジを安価にするということであって、初めて可能にするということではない。
ミニマリストの賭けとOP_CATの設計空間
CTV+CSFSはテーブルに並ぶ唯一のコベナント提案ではない。最も議論されている代替案はOP_CAT——スタック上の上位2つのアイテムを単純に連結する4バイトのオペコードだ。これはもともとビットコインのスクリプト言語の一部だったが、2010年に無制限のスタック成長に関連するサービス拒否の懸念から無効化された。OP_CATは2024年にBIP番号347が割り当てられたが、これは技術的な真剣さというプロセスのハードルをクリアしたというシグナルであり、アクティベーションが近いというシグナルではない。
両陣営の設計哲学の差は本物だ。CTVは特定の目的に作られたオペコードだ——一つのこと（テンプレートハッシュへのコミット）をし、それを構造的に再帰を排除する形で行う。OP_CATはプリミティブだ——非常に小さな一つのこと（バイト列の連結）をするが、そのプリミティブはTaprootのSchnorr署名と組み合わさることでスクリプトのイントロスペクション——スクリプトがそれを含むトランザクションについて推論する能力——を可能にし、それが再帰コベナントと汎用ステートマシンを可能にする。StarkWareはフェデレーテッドマルチシグなしにビットコインからL2へのブリッジングをトラストミニマイズする、OP_CATブリッジコベナントの概念実証を公開している。そうした構成はCTV+CSFSでは実現不可能だ。
トレードオフは、どちらも内部的に整合している二つの立場の間にある。
CTV+CSFSの立場は、コベナントは可能な限り小さな増分で追加されるべきであり、再帰は明確にレベルが上がった話であり、再帰コベナントに対して提起される代替不可能性への懸念——コインが制限的なスクリプトに永久にロックされる理論的な可能性——は、汎用プリミティブの中に紛れ込ませるのではなく、それ独自の議論として扱われるべきほど深刻だというものだ。支持者は、このことでいくつかのBTCFiの構成が手の届かないところに留まることを受け入れている。
OP_CATの立場は、再帰コベナントへの懸念は主に理論的なものであり、より弱い制限の形（マルチシグ、タイムロック、ハッシュロック）はすでに存在し、汎用イントロスペクションを追加することは一度限りのプロトコル変更であり、一連の個別オペコードよりもはるかに広い設計空間を開くというものだ。2010年のOP_CAT無効化の動機となったDoSの懸念はTaprootが導入したスクリプトサイズ制限によってもはや適用されない、とこの陣営は主張する。「もはや適用されない」という主張については異論があることを注記しておく——これは私たちが検討した資料の中で、証明されるよりも主張される頻度のほうが高かった。
第三の立場がある。主にBitcoin Coreのコントリビューターの中にいる声高な懐疑論者が持つもので、コベナントの議論全体が時期尚早であり、どちらの提案もコンセンサスの変更に値するレビュー年数を積み重ねていないという立場だ。あらゆる新しいオペコードを攻撃対象として扱うビットコインのスクリプト文化は、賛成の理由が圧倒的でない限りデフォルトで否定に向かうべきだ、というものだ。この立場はCTVへの具体的な技術的異議を必要としない。コンセンサスの変更に対する高い事前確率（prior）さえあればよい。
2025年6月の書簡と2026年アクティベーション計画
2025年6月、私たちの調査資料内で一次ソースを完全に確認できなかった報道によれば、CTV+CSFSのアクティベーションを求める公開書簡が発表された。トピックブリーフには著名な暗号研究者やLightning開発者を含む~66人の署名者が挙げられているが、具体的なリスト、正確な文言、書簡の全論旨は私たちが参照した資料から直接アクセスできなかった。これを事実として述べるのではなく、ギャップとして明示する。確認できることは、書簡が存在したこと、重要な業界イベントとして報じられたこと、そしてその目的が最小限のコベナントパッケージを第一ステップとすることに関する開発者コンセンサスを示すことにあったということだ。
トピックブリーフによれば、Bitcoin Coreコントリビューターからの反応は支持ではなく反発だった。ここでも、提起された具体的な技術的異議には直接アクセスできない——実質的な議論が行われているDelving Bitcoinのスレッドは、私たちのソース資料では一部しか確認できなかった——ので、それを作り上げることはしない。議論の形から明らかなのは、Core内のどの派閥もCTV+CSFSアクティベーションのロジックをCoreのコードベース自体にマージする動きを取っていないということだ。
ここで2026年のタイムラインが興味深くなる。2026年4月に公開されたある統合によれば、Core外アクティベーションクライアントのために提案されている具体的なデプロイパラメータは以下の通りだ：
- 開始時刻：2026年3月30日
- タイムアウト：2027年3月30日
- 最小アクティベーション高：~2027年5月
- シグナリング閾値：2016ブロック期間にわたるマイナーの90%
これらの数字はセカンダリソースからの提案パラメータとして扱い、確定したコンセンサスとは見なさない。しかしもし維持されれば、これはTaproot以来ビットコインが生み出した初めての具体的なソフトフォークタイムラインになる。メカニズムはBIP9スタイルのマイナーシグナリングだ。各2016ブロックのウィンドウにわたって、マイナーはブロックバージョンにビットを設定することで準備完了をシグナリングできる。ウィンドウ内で90%がシグナリングすれば、フォークはロックインし、最小アクティベーション高で有効化される。
Core外という側面がこの計画の核心だ。Coreがアクティベーションロジックをマージしていないため、シグナリングとアクティベーションのコードは代替クライアント——既存のコンセンサスルールをすべて踏襲しつつ、マイナーシグナリング閾値が満たされた場合に最小アクティベーション高でCTV+CSFSを新たなルールとして追加するビットコイン実装——として出荷されることになる。CTVトランザクションがマイニングされない限り、Coreを実行するノードは有効であり続ける。CTVがアクティベートされ、CoreノードがCTVコミットブロックを拒否すれば、チェーン分裂が発生する。
ガバナンスの賭け金：Core外アクティベーションが示すもの
ビットコインのコンセンサスプロセスには正式なガバナンス機関が存在しない。実際のところ、規範はBitcoin Coreのメンテナーがソフトな拒否権を持つというものだった——Coreがマージしない変更はアクティベートされない。2017年のSegWit UASFがその規範への最後の本格的な挑戦だったが、それでも最終的にはCoreのコードベースを経由した。UASFクライアント（BIP148）はアクティベーションロジックを変更したCoreのフォークであり、UASFの圧力がピークに達した時点でSegWitはすでにCore内にあった。
CTV+CSFSのCore外アクティベーションは、SegWit UASFよりもCoreの拒否権という規範への強い挑戦となる。代替クライアントは、Coreメンテナーが明示的に採用を断ったアクティベーションコードを持つことになる。マイナーが90%を超えてシグナリングしフォークがアクティベートされれば、Coreはユーザーを多数派チェーンに留めるためにCTV+CSFSをマージするか——これにより、十分に組織化された開発者連合とマイナーのスーパーマジョリティがCoreを動かせるという先例が確立される——あるいはCoreはフォークを明示的に拒否してチェーン分裂を受け入れるかのどちらかが必要になる。後者はビットコインが単一の正規実装を持つという前提との大きな決別だ。
これが健全だという正当な主張がある。2021年以来ビットコインのアップグレードプロセスが事実上凍結していることは、誰かが選んだ設計上の結果ではなく、正式なガバナンスなしにコンセンサスの変更を調整することの困難さから生まれた均衡だ。問いを強制すること——アクティベートするか明示的に拒否するか——は、永続的な膠着状態が生み出さない情報をもたらす。
これが危険だという正当な主張もある。マイナーシグナリングの90%という閾値はフロアであり、ユーザーの同意の証明ではない。TaprootのアクティベーションはCTVが現在持つよりも、ユーザー、企業、開発者にわたってはるかに広い可視的な支持を持っていた。Coreの反対を押し切ってベアなマイナースーパーマジョリティでアクティベートするソフトフォークは、より狭い目的を持つ将来の連合に利用可能な先例を生み出しかねない——そしてコベナントはまさに「より狭い目的」の空間が大きいクラスの変更だ。
どちらの議論もそれ単独では決定的ではない。経験的な問いは、書簡の背後にある開発者連合が、90%のマイナーシグナルを掌握されたシグナルではなく批准として見せるだけの周囲のインフラ——経済的なノードの支持、ウォレット統合のコミットメント、取引所の準備——を構築できるかどうかだ。私たちが確認したソースの時点では、その周囲のインフラはまだ組み立て中だった。
残る異議
技術的な異議が解決されたと示唆するのは不誠実だ。完全なソースなしでも名指しする価値のあるものが三つある。
一つ目はTxWithholdへの懸念で、Delving Bitcoinのスレッドで参照されているBitMEXの記事でGleb Naumenko氏が探求している。コベナントは、特定のトランザクションをブロックから保留するようマイナーに賄賂を払うスクリプトの構築に利用できる。深刻さはそのような構成がどれほど容易になるか、そして手数料市場がどれほど寛容かによる。懸念はコベナントがトランザクションの保留を導入するということではなく、賄賂のコストが大幅に低下しうるということだ。私たちの知る限り、これはCTV+CSFSの具体的な文脈で議論を解決する形で正式に分析されていない。
二つ目は複雑性バジェットへの批判だ。新しいオペコードは毎回コンセンサスコードの攻撃対象面積を拡大し、既存のスクリプトプリミティブとの新たな相互作用を生み出す。ビットコインの開発文化はこの拡大をデフォルトでコストとして扱う。CTV+CSFSのパッケージは限定的だが、タダではなく、Taproot、sighashフラグ、将来の提案との相互作用を監査するために必要なレビュー時間は非trivialだ。
三つ目はファーストステップ問題だ。CTV+CSFSがアクティベートされれば、OP_CATの議論は容易になるのか難しくなるのか。支持者は容易になると主張する——コミュニティはソフトフォークを出荷できることを証明し、CTVを超えた設計空間はそれ自体の価値で評価できるようになる。懐疑論者は難しくなると主張する——狭いコベナントのアクティベーションは、より野心的な提案に充てられたはずの政治的資本を消費し、OP_CATが可能にしていた構成には不十分なパーシャルなコベナントがビットコインに残ることになる。どちらも十分ありえる。歴史的な証拠は乏しい——ビットコインは2021年以来アップグレードを出荷していないのだから。
BTCFiへの示唆
BTCFiビルダーにとっての実践的な問いは、不確実性に対して資本とロードマップの配分をどう計画するかだ。三つの方針が合理的に見える。
一つ目は現在のスクリプトセットに基づいて構築することだ。CitreaでのBitVM2の本番運用は、新しいオペコードなしに意味のあるトラストミニマイゼーションが——オンチェーンフットプリントが大幅に増大するコストはあるにしても——達成可能であることを示している。2026~2027年に出荷する必要があるチームは、アクティベーションを前提にロードマップを組めない。
二つ目はCTV+CSFSをソフトターゲットとして構築することだ。ボールトプロダクト、チャネルファクトリーベースのベニュー、DLC中心のアプリケーションはアクティベーションから不均衡に恩恵を受け、それらの設計はコベナント対応バージョンがプリサインドトランザクションバージョンのクリーンなアップグレードになるように構造化できる。欠点は、プリサインドトランザクションバージョンが脆弱なままであり、アクティベーションまでユーザーがその脆弱性を負い続けることだ。
三つ目は、一つのコベナントがアクティベートされれば二つ目が政治的に容易になるという前提のもと、より深いOP_CATの設計空間に基づいて構築することだ。これは長期的な賭けだ。また、CTVのアクティベーション、その後のOP_CATの議論、OP_CAT自体のアクティベーションという連鎖した反事実に依存しており、それぞれが条件付きだ。
2026年の残りから2027年にかけて注目すべきオープンクエスチョンは、狭くかつ答えの出るものだ。代替クライアントは出荷されるか、そしてCoreは独自のシグナリングロジックで応答するか、それとも明示的な拒否で応答するか。2026年3月の開始後、最初の2016ブロックウィンドウにおけるマイナーのシグナリング行動はどうなるか。Coreコントリビューターからの具体的な技術的異議は評価可能な形で公表されるか、それとも議論は拡散したままか。そして、ウォレット、取引所、カストディアンからなる周囲の連合はシグナリングウィンドウが開く前に公式コミットするか、後にするか。
これらの問いへの答えが「代替クライアントが出荷され、マイナーが90%を超えてシグナリングし、Coreがそれへのレスポンスとしてマージする」であれば、ビットコインは新たなアップグレード経路を発見し、BTCFiは18ヶ月以内に大きく異なる設計空間で構築できるようになる。「クライアントが出荷され、シグナリングが失敗し、議論がリセットされる」であれば、ビットコインのアップグレードプロセスが単に保守的なだけでなく構造的にブロックされていることが確認され、BTCFiのロードマップは予見しうる将来にわたってスクリプトの停滞を前提とする必要が出てくる。どちらの結果も情報価値がある。最悪なのは三つ目——クライアントが出荷され、マイナーがシグナリングし、生じたチェーン分裂がビットコインのガバナンスがどの派閥も想定していたより一貫性に欠けることを露わにする——だ。この結果は最も起こりやすいわけではないが、今最も注意を払うことが報われるものだ。
引言
自2021年11月Taproot激活以来，比特币再未经历任何共识层面的变更。同一时期，其他主流智能合约公链均已多次迭代其执行层。比特币的设计哲学使然，这种局面本在意料之中——但这种停滞在BTCFi构建者社区中积累的挫败感，如今已化为一场有组织的推动，矛头指向一项具体而克制的升级提案：OP_CHECKTEMPLATEVERIFY（CTV）与 OP_CHECKSIGFROMSTACK（CSFS）的组合激活。
这一提案的切口很窄。CTV允许一枚币提前承诺消费它的交易必须呈现的确切结构；CSFS允许脚本验证一个针对栈上任意数据的签名。两者都不引入递归，也都不具备OP_CAT支持者所追求的完全通用可编程性。但两者结合，将解锁一类新的构造——非托管金库、更高效的联合池与通道工厂、成本更低的离散对数合约，以及更简洁的Lightning和Ark实现路径——而这些构造，BTCFi构建者们目前只能用越来越脆弱的预签名交易机制勉强模拟。
对我们而言，真正有趣的问题不是CTV+CSFS在技术上是否可靠——这场争论基本已经穷尽，该提案公开讨论已历多年。真正有趣的问题是：如此克制的升级为何迟迟搁置？2025年年中的公开信，以及拟议中的2026~2027年绕过Bitcoin Core的链外激活时间线，对比特币未来如何做出共识决策意味着什么？若激活通过一个非Bitcoin Core的客户端完成，这将是SegWit UASF时代以来的首个先例，并将重塑未来协议变更的协商方式。若激活失败，则将坐实比特币的升级路径在实践上已然冻结——BTCFi构建者应据此做好规划。
什么是契约
在比特币脚本的语境中，契约（covenant）是一种消费条件，它不仅约束一个UTXO能否被消费，还约束消费该UTXO的交易必须呈现什么形态。当前，脚本回答的是一个单一时态的问题：给定见证数据，当下这笔消费是否被授权？契约则将时态延伸：给定这笔消费，它所产生的交易是否符合此前承诺的结构？
CTV在BIP-119中被规范定义，以尽可能严格的方式实现了这一机制。当一个UTXO被锁定到CTV脚本时，该操作码会对消费交易中的一组特定字段进行哈希，并与脚本中嵌入的模板哈希进行比较。据Bitcoin Optech，承诺的字段包括：交易版本、锁定时间、scriptsigs、输入数量、sequence值、输出数量、输出本身，以及消费输入的索引。若其中任何字段与模板不符，消费即告失败。
此设计有两个特性值得停下来细想。其一，CTV承诺输出，但不承诺输入——具体而言，不承诺输入的txid。正因如此，同一模板可以跨不同资金交易复用，这也是金库和拥塞控制构造具有实用价值的关键所在。其二，CTV在结构上不具递归性。模板哈希是脚本中的固定值，无法从消费交易本身动态计算得出。一个CTV输出可以强制约束其下一跳，但那个下一跳是一笔具体的、预先指定的交易——它本身不能再是一个模板由栈上某值派生的CTV输出。这种结构性的非递归，正是”CTV不会产生永久性受限币”这一论据的全部基础。
CSFS是另一种原语。比特币现有的OP_CHECKSIG验证的是针对当前交易的签名，而CSFS验证的是消费者放置在栈上的任意数据上的签名。这些数据可以是任何内容——未来价格的消息、预言机的证明、通道协议中交易对手产生的承诺。单独来看，CSFS本身不是契约，而是一种委托与证明原语。它在这一组合中的价值，在于它与CTV结合后赋予脚本的能力：验证某链下方已授权了一段特定状态，再用CTV约束该状态的链上结算方式。
在此，我们必须坦承一处研究空白。CSFS与CTV如何组合，以产生——比如——LN-Symmetry风格的通道或更高效的Ark轮次，其精确机制在我们所参考的资料中并未得到详细阐述。可以确定的是，CSFS被纳入”第一步”方案，正是因为CTV单独无法弥合Lightning和Ark构建者最关注的设计缺口。希望追溯这些构造细节的读者，应直接查阅Delving Bitcoin上的相关讨论帖和所引用的BIP原文。
CTV为BTCFi解锁了什么
理解构建者为何力推此提案，最清晰的方式是逐一梳理CTV所能实质性改善的具体构造。
金库
比特币金库，就该术语已形成的含义而言，是一种冷存储方案：从冷端发起的任何消费，都必须先经过一个有时间锁的中间地址。在延迟窗口期间，金库持有人可以观察待处理的消费，若属未授权操作，则可触发恢复回收机制，将资金重定向至更安全的密钥。这是比特币目前最接近原生应对密钥泄露的解决方案。
当前，金库通过临时密钥与预签名交易构建。持有人生成一对临时密钥对，用其签署金库的各条消费路径，再销毁私钥。金库的安全性随即建立在一个假设之上：临时密钥确实已被删除，且在删除前从未泄露。Bitcoin Optech将这种构造描述为”充其量是脆弱的”——这是对从业者看法较为委婉的表达。以可审计、可重复的方式验证密钥删除，是一个真实存在的运营难题，愿意用真实资产运行此类方案的人少之又少。
引入CTV之后——BIP-345的OP_VAULT正是基于CTV构建——预签名交易的繁琐流程将被契约取代。金库输出直接在共识层承诺延迟消费交易的结构，无需临时密钥，也无需可信的密钥销毁。金库由此成为一种无状态、可复制的构造，钱包可从公开参数确定性地生成。
联合池与通道工厂
将多用户资金汇入单一UTXO、并允许各自独立退出或重组的构造——联合池、通道工厂及其变体——依赖于能够在不经历两轮完整交互式签名的情况下重新协商链下状态。Optech指出，CTV将这类构造中状态转换所需的签名轮次从两轮降至一轮。听起来像是实现层面的细节，实则是可扩展性与活性层面的变革。一个要求全部N个参与者在线两轮的构造，在极限情况下，若只需一轮，其失败频率将减半——而这类构造的失败模式，通常比乐观路径所呈现的更为严酷。
离散对数合约
DLC是比特币当前实现预言机证明合约的方式。一个以BTC/USD最近整数美元为结算单位的DLC，据Optech，可能涉及逾万种潜在结果，每种结果都需要交易对手双方创建、交换、验证并存储各自的签名适配器。CTV用一个模板替代了逐一结果的适配器。大型DLC的建立成本大致随结果空间的规模而下降，对于实际合约而言，这意味着一到两个数量级的缩减。
拥塞控制与批量处理
CTV还支持一种特定的费用市场构造：交易所或托管方可以在链上提交一个单一模板输出，待后续展开时再向多个接收方付款。拥塞期间，提交成本低廉；展开操作则等到费率合适时再进行。这并不创造新的容量，但让大型参与者能够将面向用户的结算时机与链上确认时机解耦，从而改变了费用高峰期区块空间的需求曲线。
BitVM路径值得单独提及。BitVM2已在生产环境中上线，支撑Citrea的主网桥接，且无需任何软分叉。契约所能带来的不是”使其成为可能”，而是”降低成本”：当前BitVM构造耗费了大量脚本字节来模拟CTV+CSFS本可直接提供的原语。支持者的主张是，契约让信任最小化的桥接更便宜，而非让其首次成为可能。
极简主义的赌注与OP_CAT的设计空间
CTV+CSFS并非桌上唯一的契约提案。讨论最为广泛的替代方案是OP_CAT——一个仅四字节的操作码，功能是将栈顶两个元素拼接。它是比特币原始脚本语言的组成部分，于2010年因无界栈增长引发的拒绝服务攻击隐患而被禁用。OP_CAT于2024年获得BIP编号347，这是一个信号，说明它已通过技术严肃性的流程门槛，而非说明它接近激活。
两个阵营之间的设计哲学分歧是真实存在的。CTV是一个特定用途的操作码：它只做一件事（承诺模板哈希），且以结构上排除递归的方式完成。OP_CAT是一个原语：它只做一件极小的事（拼接字节），但这个原语与Taproot的Schnorr签名结合，可以实现脚本内省——即脚本推理包含它的交易的能力——进而支持递归契约和通用状态机。StarkWare已发布基于OP_CAT的桥接契约概念验证，展示了无需联合多签的信任最小化比特币对L2桥接。这类构造在CTV+CSFS下无法实现。
两种立场之间的权衡，各自内部都是自洽的。
CTV+CSFS的立场认为，契约应以最小增量引入；递归是一次独立的升级跃迁；针对递归契约提出的可替代性顾虑——理论上存在币被永久锁入限制性脚本的可能性——足够严重，应作为独立议题处理，而不应包裹在通用原语中一并引入。支持者承认，这意味着若干BTCFi构造将继续无缘实现。
OP_CAT的立场则认为，递归契约的顾虑在很大程度上是理论性的；较弱形式的限制已然存在（多签、时间锁、哈希锁）；添加通用内省是一次性的协议变更，所开放的设计空间远超一系列窄范围操作码所能提供的总和。这一阵营主张，2010年促使OP_CAT被禁用的拒绝服务隐患，在Taproot引入脚本大小限制后已不再适用。我们将”不再适用”这一说法标注为存疑——在我们审阅的材料中，它被断言的频率远高于被论证的频率。
第三种立场主要由Bitcoin Core中持明确反对意见的贡献者持有：整个契约讨论还为时尚早；两个提案都尚未积累共识变更所应有的审查年限；比特币脚本文化——将每一个新操作码都视为攻击面——应默认为否，除非支持的理由压倒一切。这一立场不需要对CTV提出具体的技术异议，只需对共识变更持有较高的先验拒绝倾向即可。
2025年6月的公开信与2026年激活计划
据我们无法从研究资料中完全核实的一手来源报道，2025年6月，一封呼吁激活CTV+CSFS的公开信公开发布。主题简报援引约66位联署人，包括具名的密码学家和Lightning开发者，但公开信的具体名单、原文措辞及完整论点，均无法从我们参考的资料中直接获取。我们选择如实指出这一空白，而不去复述一份我们无法核实的联署人名单。可以确认的是：该信确实存在，被作为重要行业事件报道，其目的是展示开发者社区围绕极简契约方案作为第一步的共识。
Bitcoin Core贡献者对此的回应，据主题简报，是质疑而非背书。同样，我们没有直接获取具体技术异议的渠道——承载实质性讨论的Delving Bitcoin帖子在我们的资料中仅部分可读——我们不打算凭空捏造。但从争论的轮廓来看，Core内部没有任何派系推动将CTV+CSFS激活逻辑合并入Core代码库。
正是在这里，2026年时间线变得引人注目。根据2026年4月发布的一份综述，针对绕过Core的链外激活客户端，具体提议的部署参数如下：
- 起始时间：2026年3月30日
- 超时时间：2027年3月30日
- 最低激活高度：约2027年5月
- 信号阈值：在2016区块周期内矿工支持率达到90%
我们将这些数字视为来自二手来源的提议参数，而非已定稿的共识。但若这些参数成立，这将是比特币自Taproot以来首次产生具体的软分叉时间线。其机制是BIP9风格的矿工信号：在每个2016区块窗口内，矿工可在区块版本中设置一个比特位来表示就绪。若90%的矿工在窗口内完成信号，分叉锁定，并在最低激活高度处生效。
绕过Core这一维度，是整个计划的核心支撑。由于Core未合并激活逻辑，信号与激活代码将搭载于一个替代客户端中——一个遵循全部现有共识规则、但在最低激活高度新增CTV+CSFS规则（前提是矿工信号阈值已达成）的比特币实现。运行Core的节点只要没有CTV交易被挖出，即保持有效。若CTV激活，而Core节点拒绝包含CTV承诺的区块，则将发生链分裂。
治理赌注：绕过Core的激活将释放什么信号
比特币的共识流程没有正式的治理机构。实践中形成的惯例是：Bitcoin Core维护者持有一种软否决权——Core不愿合并的变更，就不会激活。2017年的SegWit UASF是对这一惯例最近一次严峻的挑战，即便如此，它最终仍通过Core的代码库完成激活；UASF客户端（BIP148）是修改了激活逻辑的Core分支，而SegWit在UASF压力达到顶峰之前就已进入Core代码库。
CTV+CSFS的绕Core激活，将比SegWit UASF更强烈地挑战这一Core否决惯例。替代客户端将携带Core维护者已明确拒绝采纳的激活代码。若矿工信号超过90%且分叉激活，Core要么必须合并CTV+CSFS以使其用户留在多数链上——这将确立一个先例：足够协调的开发者联盟加矿工超级多数，可以迫使Core就范——要么必须明确拒绝该分叉并接受链分裂，这将是与”比特币拥有单一权威实现”这一假设的更大决裂。
有一种观点认为，这是健康的。比特币升级进程自2021年起实际上陷入冻结，并非任何人刻意选择的设计结果，而是在缺乏正式治理机制的情况下协调共识变更极度困难所形成的均衡。强制摊牌——要么激活，要么明确拒绝——所产生的信息量，是长期僵局所无法提供的。
也有另一种观点认为，这是危险的。90%的矿工信号阈值是底线，而非用户同意的证明。Taproot激活时，在用户、企业和开发者中具有广泛且可见的支持，远超CTV目前的状况。若一个软分叉在Core反对的情况下，仅凭矿工裸多数激活，可能为未来目标更窄的联盟设立可被利用的先例——而契约恰恰是”更窄目标”的空间最大的那类变更。
两种论点单独来看都不具决定性。关键的实证问题是：公开信背后的开发者联盟，能否构建起足够的周边基础设施——经济节点支持、钱包整合承诺、交易所就绪声明——使90%的矿工信号看起来像是代表广泛认可，而非被捕获的信号。从我们审阅的资料来看，这一周边基础设施彼时仍处于组建之中。
尚存的异议
若暗示技术异议已然平息，我们将有失诚实。有三点值得点名，尽管无法完整溯源。
第一是TxWithhold问题，由Gleb Naumenko在Delving Bitcoin帖子所引用的一篇BitMEX文章中探讨。契约可被用于构造向矿工付费、以换取其将特定交易排除在区块之外的脚本。其严重性取决于此类构造的实现难度，以及费用市场的容忍程度；问题不在于契约引入了交易扣押，而在于契约可能大幅降低此类贿赂的成本。据我们所知，这一问题尚未在CTV+CSFS的具体语境下以能够终结争论的方式进行正式分析。
第二是复杂度预算批评。每个新操作码都会扩展共识代码的攻击面，并与现有脚本原语产生新的交互。比特币的开发文化默认将这种扩展视为代价。CTV+CSFS方案范围窄，但并非零成本，审计其与Taproot、sighash标志及未来提案交互所需的审查人时，绝非可以忽视。
第三是第一步问题。若CTV+CSFS激活，OP_CAT的讨论会变得更容易还是更难？支持者认为更容易：社区将证明自己能够推进软分叉，CTV之外的设计空间可以独立评估。怀疑者认为更难：窄范围契约的激活将消耗原本可用于更宏大提案的政治资本，比特币将止步于一个不足以支撑OP_CAT所能实现的构造的局部契约。两种判断都言之成理。历史依据稀缺，因为比特币自2021年以来尚未推进任何升级。
对BTCFi的影响
对BTCFi构建者而言，实际问题是如何在不确定性下规划资本配置与路线图。三种取向看来各有依据。
第一种是基于现有脚本集进行构建。BitVM2在Citrea上的生产部署表明，在无需任何新操作码的情况下，有意义的信任最小化是可以实现的，代价是显著更高的链上占用。需要在2026~2027年落地产品的团队，无法将路线图寄托于激活成功与否。
第二种是将CTV+CSFS作为软目标进行构建。金库产品、基于通道工厂的场所，以及重度使用DLC的应用，在激活后将获得不成比例的收益，其设计可以被构造为：契约感知版本是预签名交易版本的简洁升级。缺点在于预签名交易版本依然脆弱，在激活之前，用户须承担这种脆弱性。
第三种是基于更深层的OP_CAT设计空间进行构建，预设一旦某种契约激活，下一个将在政治上更容易推进。这是一个较长期的赌注，同时依赖于一连串反事实假设——CTV激活、随后的OP_CAT讨论、OP_CAT本身的激活——每一环都是条件性的。
在2026年余下时间及2027年，我们将持续关注的问题是具体而可验证的。替代客户端是否会上线，Core会以推出自身信号逻辑还是明确拒绝来应对？2026年3月起始日后第一个2016区块窗口内，矿工的信号行为如何？Core贡献者的具体技术异议是否会以可供评估的形式公开发布，抑或讨论仍将停留于弥散状态？周边联盟——钱包、交易所、托管方——会在信号窗口开启前还是开启后公开表态？
若这些问题的答案是”替代客户端上线，矿工信号超过90%，Core随即合并变更”，比特币将探索出一条新的升级路径，BTCFi将在十八个月内获得一个实质不同的设计空间。若答案是”客户端上线，信号失败，讨论重置”，则将坐实比特币的升级进程不仅保守，而且在结构上已然阻塞，BTCFi的路线图将需要在可预见的未来以脚本静止为前提进行规划。两种结果都具有信息量。最糟糕的是第三种：客户端上线，矿工信号达到阈值，但随之而来的链分裂揭示出，比特币的治理远比任何派系所预设的更加脆弱。这一结果不是最可能发生的，但它是眼下最值得保持高度关注的那一个。
Introducción
Bitcoin no ha activado ningún cambio de consenso desde Taproot en noviembre de 2021. Todas las demás cadenas importantes con contratos inteligentes han iterado varias veces sobre su capa de ejecución en ese mismo período. Bitcoin, por diseño, no lo ha hecho — y la frustración que esto ha generado dentro de la comunidad de builders de BTCFi está aflorando ahora como un impulso organizado hacia una actualización concreta y mínima: la combinación de OP_CHECKTEMPLATEVERIFY (CTV) y OP_CHECKSIGFROMSTACK (CSFS).
La propuesta es acotada. CTV permite que una moneda se comprometa de antemano con la forma exacta de la transacción que la gasta. CSFS permite que un script verifique una firma sobre datos arbitrarios extraídos del stack. Ninguno introduce recursión. Ninguno habilita la programabilidad general que los defensores de OP_CAT persiguen. Sin embargo, juntos desbloquearían una categoría de construcciones — vaults sin custodia, joinpools y channel factories más eficientes, discreet log contracts más baratos, y caminos más simples para Lightning y Ark — que los builders de BTCFi han venido emulando con maquinaria de transacciones prefirmadas cada vez más frágil.
La pregunta interesante para nosotros no es si CTV+CSFS es técnicamente sólido. Ese debate está en gran medida agotado; la propuesta lleva años en el dominio público. La pregunta interesante es por qué una actualización tan acotada ha quedado paralizada, y qué significan la carta abierta de mediados de 2025 y el calendario de activación fuera de Core propuesto para 2026~2027 en términos de cómo Bitcoin toma decisiones de consenso en adelante. Si la activación prospera a través de un cliente que no es Bitcoin Core, será el primer precedente de ese tipo desde la era del UASF de SegWit, y redefinirá cómo se negocian los cambios de protocolo futuros. Si fracasa, confirmará que la trayectoria de actualización de Bitcoin está, en la práctica, congelada — y que los builders de BTCFi deberían planificar en consecuencia.
Qué es un covenant
Un covenant, en términos de Bitcoin script, es una condición de gasto que restringe no solo si un UTXO puede gastarse, sino cómo debe ser la transacción que lo gasta. Hoy, el script responde una pregunta en tiempo presente: dados los datos del witness, ¿está autorizado este gasto ahora mismo? Un covenant extiende ese horizonte temporal: dado este gasto, ¿la transacción que produce coincide con una forma a la que nos comprometimos antes?
CTV, especificado en el BIP-119, implementa esto de la manera más restrictiva posible. Cuando un UTXO está bloqueado en un script CTV, el opcode hashea un conjunto específico de campos de la transacción que lo gasta y los compara con un hash de plantilla embebido en el script. Según Bitcoin Optech, los campos comprometidos son: la versión de la transacción, el locktime, los scriptsigs, el número de inputs, los valores de secuencia, el número de outputs, los propios outputs, y el índice del input que gasta. Si alguno de estos difiere de la plantilla, el gasto falla.
Dos propiedades de este diseño merecen una pausa. Primera, CTV se compromete con los outputs pero no con los inputs — en concreto, no con los txids de los inputs. Esto es lo que permite reutilizar la misma plantilla con distintas transacciones de financiación, lo cual hace prácticas las construcciones de vaults y de control de congestión. Segunda, CTV es no recursivo por construcción. El hash de la plantilla es un valor fijo en el script; no puede computarse a partir de la transacción que lo gasta. Un output CTV puede forzar su siguiente salto, pero ese siguiente salto es una transacción concreta y preespecificada — no puede ser a su vez un output CTV cuya plantilla se derive de algo en el stack. Esta no recursión estructural es la base íntegra del argumento de que CTV no puede producir monedas permanentemente restringidas.
CSFS es un primitivo diferente. Mientras que el OP_CHECKSIG existente de Bitcoin verifica una firma sobre la transacción actual, CSFS verifica una firma sobre datos arbitrarios que el gastador coloca en el stack. Esos datos pueden ser cualquier cosa — un mensaje sobre un precio futuro, una attestation de un oráculo, un compromiso producido por una contraparte en un protocolo de canal. Por sí solo, CSFS no es un covenant; es un primitivo de delegación y attestation. Su potencia en esta combinación proviene de lo que permite hacer a los scripts junto con CTV: verificar que una parte fuera de la cadena ha autorizado un estado concreto y, a continuación, usar CTV para restringir la liquidación on-chain de ese estado.
Debemos ser honestos sobre una laguna en nuestra investigación. La mecánica precisa de cómo CSFS se compone con CTV para producir, por ejemplo, un canal al estilo LN-Symmetry o una ronda de Ark más eficiente no quedó desarrollada en el material de partida con el que trabajamos. Lo que sí está claro es que CSFS se incluye en el paquete de “primer paso” precisamente porque CTV solo no cierra la brecha de diseño que más preocupa a los builders de Lightning y Ark. Los lectores que quieran rastrear esas construcciones en detalle deben acudir directamente al hilo de Delving Bitcoin y a los BIPs referenciados.
Qué desbloquea CTV para BTCFi
La manera más clara de entender por qué los builders impulsan esto es recorrer las construcciones concretas que CTV mejora de forma sustancial.
Vaults
Un vault de Bitcoin, en el sentido que ha adquirido el término, es un esquema de almacenamiento en frío en el que cualquier gasto desde cold storage debe pasar primero por una dirección intermedia con timelock. Durante la ventana de demora, el propietario del vault puede observar el gasto pendiente y, si no está autorizado, invocar un clawback de recuperación que redirige los fondos a una clave más segura. Es lo más parecido que tiene Bitcoin a una respuesta nativa ante el compromiso de claves.
Hoy, los vaults se construyen con claves efímeras y transacciones prefirmadas. El propietario genera un par de claves temporal, firma los caminos de gasto del vault con ellas, y luego destruye la clave privada. La seguridad del vault descansa entonces en la suposición de que la clave efímera fue efectivamente eliminada y nunca se filtró antes de esa eliminación. Bitcoin Optech describe esta construcción como “frágil en el mejor de los casos,” que es la versión educada de la visión de los practitioners. Verificar la eliminación de claves de manera auditable y repetible es un problema operativo real, y la clase de personas dispuestas a ejecutar ese esquema con capital significativo es pequeña.
Con CTV — y el OP_VAULT del BIP-345 se apoya en CTV precisamente por esta razón — el juego de las transacciones prefirmadas se reemplaza por un covenant. El output del vault se compromete directamente en consenso con la forma de la transacción de gasto diferido. No existe ninguna clave efímera que pueda filtrarse. No se requiere ninguna eliminación de confianza. El vault se convierte en una construcción sin estado y reproducible que una wallet puede generar de forma determinista a partir de parámetros públicos.
Joinpools y channel factories
Las construcciones que agrupan los fondos de muchos usuarios en un único UTXO y les permiten salir o reestructurarse de forma independiente — joinpools, channel factories y sus variantes — dependen de poder renegociar el estado fuera de la cadena sin pasar por dos rondas completas de firma interactiva cada vez. Optech señala que CTV reduce las rondas de firma necesarias para las transiciones de estado en estas construcciones de dos a una. Suena a un detalle de implementación; en realidad es un cambio de escalabilidad y liveness. Una construcción que requiere que los N participantes estén en línea durante dos rondas falla la mitad de las veces, en el límite, si solo requiere una — y los modos de fallo de estas construcciones son habitualmente peores de lo que sugiere el camino feliz.
Discreet log contracts
Los DLC son la forma en que Bitcoin ejecuta hoy los contratos atestados por oráculos. Un único DLC con, digamos, pagos BTC/USD redondeados al dólar más cercano puede involucrar más de diez mil resultados posibles, según Optech, cada uno de los cuales requiere su propio signature adaptor que las contrapartes deben crear, intercambiar, verificar y almacenar. CTV reemplaza ese adaptor por resultado con una plantilla. El coste de configuración de un DLC grande cae aproximadamente en proporción al tamaño del espacio de resultados, que para contratos prácticos es uno o dos órdenes de magnitud.
Control de congestión y batching
CTV también habilita una construcción específica para el mercado de comisiones: un exchange o custodio puede comprometerse on-chain con un único output de plantilla que, cuando se despliega más adelante, paga a múltiples destinatarios. Durante la congestión, el compromiso es barato; el despliegue ocurre cuando las comisiones lo permiten. Esto no crea nueva capacidad, pero permite a los grandes actores desacoplar el momento del settlement orientado al usuario del momento de la confirmación on-chain, lo que cambia la curva de demanda de espacio en bloques durante los picos.
Vale la pena mencionar por separado la vía de BitVM. BitVM2 ya está en producción, impulsando el bridge de mainnet de Citrea sin ningún soft fork. Lo que ofrecerían los covenants no es habilitación sino reducción de costes: las construcciones actuales de BitVM consumen una cantidad sustancial de bytes de script emulando primitivos que CTV+CSFS proporcionaría directamente. La afirmación de los proponentes es que los covenants hacen que los bridges con mínima confianza sean más baratos, no que los hagan posibles por primera vez.
La apuesta minimalista frente al espacio de diseño de OP_CAT
CTV+CSFS no es la única propuesta de covenant sobre la mesa. La alternativa más debatida es OP_CAT, un opcode de cuatro bytes que simplemente concatena los dos elementos superiores del stack. Formaba parte del lenguaje de scripting original de Bitcoin y fue desactivado en 2010 por preocupaciones de denegación de servicio relacionadas con el crecimiento ilimitado del stack. A OP_CAT se le asignó el número BIP 347 en 2024, lo que es una señal de que ha superado el umbral de seriedad técnica del proceso, no de que esté cerca de la activación.
La brecha de filosofía de diseño entre los dos campos es real. CTV es un opcode específico y diseñado para un propósito concreto: hace una sola cosa (comprometerse con un hash de plantilla), y lo hace de una manera que descarta estructuralmente la recursión. OP_CAT es un primitivo: hace una cosa muy pequeña (concatenar bytes), pero ese primitivo, combinado con las firmas Schnorr de Taproot, habilita la introspección de scripts — la capacidad de un script de razonar sobre la transacción que lo contiene — lo que a su vez permite covenants recursivos y máquinas de estado generales. StarkWare ha publicado una prueba de concepto de un covenant bridge con OP_CAT que demuestra bridging Bitcoin-a-L2 con mínima confianza sin un multisig federado. Ese tipo de construcción no está disponible bajo CTV+CSFS.
El tradeoff, entonces, es entre dos posiciones que son internamente coherentes.
La posición de CTV+CSFS es que los covenants deben añadirse en los incrementos más pequeños posibles, que la recursión es una escalada cualitativa distinta, y que la preocupación por la fungibilidad planteada contra los covenants recursivos — la posibilidad teórica de monedas permanentemente bloqueadas en scripts restrictivos — es suficientemente grave como para tratarse en su propio debate, no escondida dentro de un primitivo de propósito general. Los proponentes aceptan que esto significa que varias construcciones de BTCFi seguirán fuera de alcance.
La posición de OP_CAT es que la preocupación por los covenants recursivos es en gran medida teórica, que ya existen formas más débiles de restricción (multisig, timelocks, hashlocks), y que añadir introspección general es un cambio de protocolo de una sola vez que abre un espacio de diseño mucho mayor de lo que jamás logrará una serie de opcodes acotados. Las preocupaciones de DoS que motivaron la desactivación de OP_CAT en 2010, argumenta este campo, ya no aplican dado los límites de tamaño de script que introdujo Taproot. Señalamos que la afirmación de que “ya no aplican” es controvertida; se afirma con más frecuencia de la que se demuestra en el material que revisamos.
Existe una tercera posición, sostenida principalmente por colaboradores de Bitcoin Core que han sido escépticos abiertos: que el debate sobre covenants en su conjunto es prematuro, que ninguna propuesta ha acumulado los años de revisión que justifica un cambio de consenso, y que la cultura de scripting de Bitcoin — que trata cada nuevo opcode como superficie de ataque — debería tomar el no como predeterminado a menos que el caso del sí sea abrumador. Esta posición no requiere una objeción técnica específica a CTV. Solo requiere una prior elevada contra los cambios de consenso.
La carta de junio de 2025 y el plan de activación de 2026
En junio de 2025, según reportes que no pudimos verificar completamente a partir de fuentes primarias en nuestro material de investigación, se publicó una carta abierta convocando a la activación de CTV+CSFS. El brief temático cita aproximadamente 66 firmantes, entre ellos criptógrafos y desarrolladores de Lightning identificados por nombre, pero la lista específica, el texto exacto y el argumento completo de la carta no son directamente accesibles desde las fuentes con las que trabajamos. Optamos por señalar esto como una laguna en lugar de citar una lista de firmantes que no podemos verificar. Lo que sí podemos decir es que la carta existió, que fue cubierta como un evento significativo en la industria, y que su propósito era demostrar consenso entre desarrolladores en torno al paquete mínimo de covenants como primer paso.
La respuesta de los colaboradores de Bitcoin Core, según el brief temático, fue de rechazo más que de respaldo. De nuevo, no tenemos acceso directo a las objeciones técnicas específicas planteadas — el hilo de Delving Bitcoin que alberga el debate de fondo solo era parcialmente legible en nuestro material fuente — y no vamos a inventarlas. Lo que sí está claro por la forma del debate es que ninguna facción dentro de Core ha avanzado hacia fusionar la lógica de activación de CTV+CSFS en la propia base de código de Core.
Aquí es donde el calendario de 2026 se vuelve interesante. Según una síntesis publicada en abril de 2026, los parámetros concretos de despliegue propuestos para un cliente de activación fuera de Core son:
- Tiempo de inicio: 30 de marzo de 2026
- Tiempo de expiración: 30 de marzo de 2027
- Altura mínima de activación: aproximadamente mayo de 2027
- Umbral de señalización: 90% de los mineros durante un período de 2016 bloques
Tratamos estos números como parámetros propuestos procedentes de una fuente secundaria, no como consenso finalizado. Pero si se mantienen, este sería el primer calendario concreto de soft fork que Bitcoin produce desde Taproot. El mecanismo es la señalización de mineros al estilo BIP9: durante cada ventana de 2016 bloques, los mineros pueden activar un bit en las versiones de sus bloques para señalar disponibilidad. Si el 90% señaliza dentro de la ventana, el fork se bloquea y activa en la altura mínima de activación.
La dimensión fuera de Core es la parte más relevante del plan. Como Core no ha fusionado la lógica de activación, el código de señalización y activación se distribuirá en un cliente alternativo — una implementación de Bitcoin que sigue todas las reglas de consenso existentes pero añade CTV+CSFS como nueva regla en la altura mínima de activación, siempre que se haya alcanzado el umbral de señalización de los mineros. Los nodos que ejecuten Core seguirán siendo válidos siempre que no se mine ninguna transacción CTV. Si CTV se activa y los nodos Core rechazan un bloque con compromiso CTV, se producirá una escisión de la cadena.
Apuestas de gobernanza: qué señalaría una activación fuera de Core
El proceso de consenso de Bitcoin no tiene ningún órgano de gobernanza formal. En la práctica, la norma ha sido que los mantenedores de Bitcoin Core tienen un veto suave: los cambios que Core no quiera fusionar no se activan. El UASF de SegWit de 2017 fue el último desafío serio a esa norma, e incluso entonces terminó pasando por la base de código de Core; el cliente UASF (BIP148) era un fork de Core con lógica de activación modificada, y SegWit ya estaba en Core cuando la presión del UASF alcanzó su punto álgido.
Una activación fuera de Core para CTV+CSFS supondría un desafío más fuerte a la norma del veto de Core que el UASF de SegWit. El cliente alternativo llevaría código de activación que los mantenedores de Core han declinado explícitamente adoptar. Si los mineros señalizan por encima del 90% y el fork se activa, o bien Core tendría que fusionar CTV+CSFS para mantener a sus usuarios en la cadena mayoritaria — lo que establecería un precedente de que una coalición de desarrolladores suficientemente coordinada más una supermayoría de mineros puede forzar la mano de Core — o bien Core tendría que rechazar explícitamente el fork y aceptar una escisión de la cadena, lo que representa una ruptura mucho más profunda con la suposición de que Bitcoin tiene una única implementación canónica.
Hay un argumento legítimo de que esto sería saludable. Que el proceso de actualización de Bitcoin esté efectivamente congelado desde 2021 no es un resultado de diseño que nadie eligió; es un equilibrio que emergió de la dificultad de coordinar cambios de consenso sin gobernanza formal. Forzar la pregunta — o se activa o se rechaza explícitamente — genera información que un estancamiento permanente no produce.
También hay un argumento legítimo de que esto es peligroso. El umbral de señalización del 90% de los mineros es un piso, no una prueba de consentimiento de los usuarios. La activación de Taproot contó con un apoyo visible mucho más amplio entre usuarios, empresas y desarrolladores del que tiene CTV actualmente. Un soft fork que se activa con una supermayoría mínima de mineros frente a la objeción de Core podría sentar un precedente explotable por coaliciones futuras con objetivos más estrechos — y los covenants son exactamente la clase de cambio en la que el espacio de “objetivos más estrechos” es amplio.
Ninguno de los dos argumentos es decisivo por sí solo. La pregunta empírica es si la coalición de desarrolladores detrás de la carta puede producir suficiente infraestructura de apoyo — soporte de nodos económicos, compromisos de integración de wallets, disponibilidad de exchanges — para que la señal del 90% de los mineros parezca una ratificación y no una señal capturada. A partir de las fuentes que revisamos, esa infraestructura de apoyo aún estaba en proceso de ensamblaje.
Objeciones pendientes
Sería deshonesto de nuestra parte insinuar que las objeciones técnicas han sido resueltas. Tres merecen nombrarse aunque no podamos documentarlas completamente.
La primera es la preocupación sobre TxWithhold, explorada por Gleb Naumenko en un artículo de BitMEX referenciado en el hilo de Delving Bitcoin. Los covenants pueden usarse para construir scripts que paguen a los mineros por retener transacciones específicas de los bloques. La gravedad depende de cuán fácil resulte realizar dichas construcciones y de cuánta tolerancia tenga el mercado de comisiones; la preocupación no es que los covenants introduzcan la retención de transacciones, sino que podrían abaratar sustancialmente el coste de sobornar para lograrlo. Esto no ha sido, hasta donde sabemos, analizado formalmente en el contexto específico de CTV+CSFS de una manera que resuelva el debate.
La segunda es la crítica del presupuesto de complejidad. Cada nuevo opcode amplía la superficie del código de consenso y crea nuevas interacciones con los primitivos de script existentes. La cultura de desarrollo de Bitcoin trata esta expansión como costosa por defecto. El paquete CTV+CSFS es acotado, pero no es gratuito, y las horas de revisión necesarias para auditar las interacciones con Taproot, los flags de sighash y las propuestas futuras son nada despreciables.
La tercera es el problema del primer paso. Si CTV+CSFS se activa, ¿hace eso el debate de OP_CAT más fácil o más difícil? Los proponentes argumentan que más fácil: la comunidad habrá demostrado que puede publicar un soft fork, y el espacio de diseño más allá de CTV podrá evaluarse por sus propios méritos. Los escépticos argumentan que más difícil: la activación de un covenant acotado consumirá el capital político que de otro modo estaría disponible para una propuesta más ambiciosa, y Bitcoin quedará con un covenant parcial que resulta inadecuado para las construcciones que OP_CAT habría habilitado. Ambas posiciones son plausibles. La evidencia histórica es escasa porque Bitcoin no ha publicado una actualización desde 2021.
Implicaciones para BTCFi
Para los builders de BTCFi, la pregunta práctica es cómo planificar la asignación de capital y hoja de ruta frente a la incertidumbre. Tres orientaciones parecen defendibles.
La primera es construir contra el conjunto de scripts actual. BitVM2 en producción en Citrea demuestra que una mínima confianza significativa es alcanzable sin ningún nuevo opcode, al precio de una huella on-chain sustancialmente mayor. Los equipos que necesiten publicar en 2026~2027 no pueden condicionar su hoja de ruta a la activación.
La segunda es construir teniendo CTV+CSFS como objetivo blando. Los productos de vault, los venues basados en channel factories y las aplicaciones con uso intensivo de DLCs se benefician desproporcionadamente de la activación, y sus diseños pueden estructurarse para que una versión con covenants sea una actualización limpia respecto a una versión con transacciones prefirmadas. La desventaja es que la versión con transacciones prefirmadas sigue siendo frágil, y los usuarios soportan esa fragilidad hasta la activación.
La tercera es construir contra el espacio de diseño más profundo de OP_CAT, bajo la suposición de que una vez que un covenant se activa, el segundo se vuelve políticamente más fácil. Es una apuesta a más largo plazo. Además, depende de una cadena de contrafactuales — activación de CTV, debate posterior sobre OP_CAT, activación del propio OP_CAT — cada uno de los cuales es contingente.
Las preguntas abiertas que vigilaríamos durante el resto de 2026 y a lo largo de 2027 son acotadas y respondibles. ¿Se publica el cliente alternativo, y responde Core con su propia lógica de señalización o con un rechazo explícito? ¿Cuál es el comportamiento de señalización de los mineros en la primera ventana de 2016 bloques tras el inicio de marzo de 2026? ¿Las objeciones técnicas específicas de los colaboradores de Core se publican en una forma evaluable, o el debate permanece difuso? ¿Y la coalición de apoyo — wallets, exchanges, custodios — se compromete públicamente antes de que se abra la ventana de señalización, o después?
Si la respuesta a esas preguntas es “el cliente alternativo se publica, los mineros señalizan por encima del 90%, y Core fusiona el cambio en respuesta,” Bitcoin habrá descubierto una nueva vía de actualización, y BTCFi tendrá un espacio de diseño sustancialmente diferente contra el que construir en un plazo de dieciocho meses. Si la respuesta es “el cliente se publica, la señalización fracasa, y el debate se reinicia,” habremos confirmado que el proceso de actualización de Bitcoin no es meramente conservador sino estructuralmente bloqueado, y la hoja de ruta de BTCFi necesitará asumir una estasis del script en el futuro previsible. Ambos resultados son informativos. El que sería peor es el tercero: el cliente se publica, los mineros señalizan, y la escisión de cadena resultante revela que la gobernanza de Bitcoin era menos coherente de lo que cualquier facción suponía. Ese resultado no es el más probable, pero es el que más recompensa prestarle atención ahora.
Read next다음으로 읽기次に読む继续阅读Leer a continuación
Follow the next market structure breakdown 다음 시장 구조 분석 받기 次の市場構造分析をフォロー 关注下一篇市场结构分析 Sigue el próximo análisis de estructura de mercado
New Steadyrain research is published several times a week across DeFi risk, BTCFi, stablecoins, and RWA. Steadyrain은 DeFi 리스크, BTCFi, 스테이블코인, RWA 분석을 매주 여러 차례 발행합니다. SteadyrainはDeFiリスク、BTCFi、ステーブルコイン、RWAの分析を毎週公開しています。 Steadyrain 每周发布 DeFi 风险、BTCFi、稳定币和 RWA 研究。 Steadyrain publica análisis sobre riesgo DeFi, BTCFi, stablecoins y RWA varias veces por semana.