bitcoin-proposalsSoft-fork proposals NOT activated on mainnet: consensus cleanup (BIP54), CTV (BIP119), the BIP448 rebindable-transaction bundle (BIP446/348/349), APO/APOAS (BIP118), OP_CHECKCONTRACTVERIFY (BIP443), OP_CAT (BIP347), the 2026 script/covenant BIP cluster (BIP440-443, 446, 448, 449), post-quantum proposals (BIP360/361), drivechains (BIP300/301), spacechains, C…
Independent GitHub snapshot · Automated classification · Original documentation governs
These are not consensus-active on mainnet. Some are deployed on signet (custom signets) or testnet for experimentation. Be explicit when reasoning: never present these as "Bitcoin" features without naming the proposal status.
Statuses below are as of September 2026 and cite the BIPs repo index, which moved to BIP-3 status semantics (Draft / Complete / Deployed / Closed). "Complete" means the authors finished the spec and recommend adoption; it does not mean activated.
The most advanced soft-fork proposal in the pipeline, and the only non-covenant one here. Authors Antoine Poinsot and Matt Corallo; assigned 2025-04-11; Status: Complete since version 1.0.0 (2026-05-22). Four narrow restrictions on 2009-era defects:
| Defect | New rule |
|---|---|
| Timewarp (off-by-one at retarget) | Timestamp floors at period edges |
| Worst-case block validation time | Legacy sigop cap of 2500 per tx |
| Merkle-tree ambiguity | 64-byte transactions invalid |
| Duplicate txids / BIP30 | Coinbase nLockTime commits to height |
N % 2016 == 0, T_N >= T_{N-1} - 7200; for
N % 2016 == 2015, T_N >= T_{N-2015} (the Murch-Zawy clause).CHECKSIG/CHECKMULTISIG counted over scriptSig
nLockTime must equal block height minus 1 and
nSequence must not be 0xffffffff.All four tighten rules only, so the soft fork is backward-compatible with non-upgraded nodes.
Already shipped as policy, not consensus:
getblocktemplate to adjust both mintime and curtime for the
Murch-Zawy end-of-period rule, on all networks. Consensus
validation is unchanged.Status (September 2026): spec Complete, no activation parameters chosen. Core PR #35793 "Implement BIP 54 (Consensus Cleanup) without mainnet activation" is open and unmerged. Bitcoin Inquisition carries an implementation for signet (Optech, 2026-02-13); a slow-block demonstration ran on signet (Optech, 2026-05-01); a draft BIP would activate BIP54 from block 1 on testnet5 (Optech, 2026-06-12).
Pool readiness: pools have been emitting forward-compatible
coinbase transactions (nLockTime = height - 1) since February 2026.
mainnet-observer's per-pool table (fetched 2026-09-15) records
WhitePool first at block 937,404 (2026-02-19), then MARA Pool at
940,548 (2026-03-13), ViaBTC at 949,094 (2026-05-12) and Foundry USA
at 952,880 (2026-06-08), plus Solo CK and CKPool. Between 33% and 49%
of coinbase transactions per day carried a BIP54 locktime over
2026-09-01..15. This is readiness, not BIP9 signaling, and cannot
lock in a soft fork. F2Pool still uses coinbase nLockTime for job
metadata; Poinsot reported (BNOC, 2026-02-23) that it does not intend
to change until BIP54 is further along toward activation.
A covenant restricts how an output may be re-spent (where the funds go, in what shape, with what conditions). Existing scripts can restrict who spends; covenants restrict how.
Use cases:
OP_CHECKTEMPLATEVERIFY (BIP119)<TemplateHash> OP_CTV
Forces the tx to match a pre-committed template:
Template-hash is committed on-chain → spending tx must produce the exact set of outputs.
Status (September 2026): BIP119 assigned 2020-01-06, still Draft in the BIPs repo. Active on signet for testing (specifically the "CTV signet"), and on the default signet via Bitcoin Inquisition.
There is now a concrete - but entirely third-party - activation path, so "no activation path" is no longer accurate:
nStartTime 2026-03-30, nTimeout
2027-03-30, threshold 1815/2016 (90%), min_activation_height
1001952 (~May 2027). This is not Bitcoin Core.Competing designs: BIP446 OP_TEMPLATEHASH (Draft) covers the same
"commit to the spending transaction" ground inside the BIP448 bundle
below, and BIP443 OP_CHECKCONTRACTVERIFY is a more general
deferred-check covenant.
Use cases: vaults, payment pools, congestion control, simple Ark variants.
New SIGHASH flag. Sig commits to script + value but not to specific prevout txid:vout.
APO sighash (commits to scriptPubKey, not txid)
APOAS sighash variant (also doesn't commit to script — even more permissive)
Original use case: Eltoo — Lightning channel update protocol that replaces commitment-tx penalty with simple state replacement.
Status (September 2026): BIP118 assigned 2017-02-28, still
Draft; no mainnet activation, signet only via Bitcoin Inquisition
(binana [2016, 118, 0], deployment ANYPREVOUT). Treat it as the
historical route to eltoo: the mainstream route is now BIP448's
Taproot-native rebindable signatures (below), which reach the same
LN-Symmetry semantics without a new sighash flag or key version.
BIP118 has not been withdrawn or formally replaced, so do not call it
dead - but do not present it as the live eltoo path either.
Authors Gregory Sanders, Antoine Poinsot and Steven Roose; assigned 2026-03-11; Status: Draft. A deployment bundle of three tapscript operations, each spec'd in its own BIP:
| BIP | Opcode | Redefines | Status |
|---|---|---|---|
| 446 | OP_TEMPLATEHASH | OP_SUCCESS206 (0xce) | Draft (assigned 2026-02-06) |
| 348 | OP_CHECKSIGFROMSTACK | OP_SUCCESS204 (0xcc) | Draft (assigned 2024-11-26) |
| 349 | OP_INTERNALKEY | OP_SUCCESS203 (0xcb) | Draft (assigned 2024-11-14) |
OP_TEMPLATEHASH pushes a hash of the spending transaction onto the
stack rather than taking a commitment as an argument, so it composes
with other opcodes where CTV does not. OP_CHECKSIGFROMSTACK gives
BIP340 verification over arbitrary messages (delegation, oracle
attestations). OP_INTERNALKEY pushes the Taproot internal key, an
8-vbyte optimisation for rebindable signatures.
BIP448's stated motivation: together these "enable rebindable transaction signatures, making possible a new type of payment channel: LN-Symmetry ('Eltoo')", make multiparty channels practical, enable the Daric 2-party channel simplification, "substantially improve statechains", and reduce interactivity in the Ark variant "Erk" and in PTLC upgrades. Deployment: "the specific activation is left to be determined at a later date." A CTV+CSFS-flavoured variant of this opcode set was previously proposed for activation as "LNHANCE".
Ecosystem as of September 2026 (Optech, 2026-09-04): a BIP448
GitHub organization aggregates implementations (Bitcoin Inquisition,
a Core patch without activation, miniscript and PSBT integration,
draft LN-Symmetry BOLTs plus a Core Lightning implementation, an Ark
OP_TEMPLATEHASH signet demo); covenants.diy is a browser tapscript
editor with selectable opcode sets; and a Covenants Use-Case Atlas
collects more than two dozen constructions. The full bundle is
expected on the default signet with the next Bitcoin Inquisition
release.
Two-stage vault primitive:
OP_VAULT output: spend to a "trigger" path (begins cooldown) or
recover path (immediate, to cold key).Provides first-class vault semantics without complex script gymnastics. Works in P2TR script-path.
Status (September 2026): BIP345 is Closed with
Proposed-Replacement: 443. Under BIP-3, Closed means "of historical
interest only, and is not being actively worked on, promoted or in
active use". Read the OP_VAULT mechanics above as design history.
OP_CHECKCONTRACTVERIFY (BIP443)Salvatore Ingala; assigned 2025-05-08; Status: Draft. A single
general deferred-check opcode (OP_CCV) instead of a vault-specific
pair: a UTXO carries a dynamic commitment to a piece of data, the
script can introspect that data, and it can constrain the internal
public key, taptree and committed data of one or more outputs.
Combined with a vector-commitment opcode this composes into arbitrary
UTXO state machines, of which a vault is one instance. Also cited as
a way to make CTV-based receive addresses safer (Optech,
2026-01-02).
Re-enable string concatenation in Tapscript. Disabled since 2010 genesis era (pulled due to DoS concerns, since obsoleted by stack-item size limits).
Why people want it:
Status (September 2026): this is BIP347, "OP_CAT in
Tapscript" (Ethan Heilman, Armin Sabouri), assigned 2023-12-11,
version 1.0.0, Status: Complete - spec finished and recommended
for adoption, with no mainnet activation; it is available on the
default signet via Bitcoin Inquisition. It redefines
OP_SUCCESS126 (0x7e, the original OP_CAT opcode value) in tapscript
only, and fails if the concatenated result would exceed the 520-byte
element limit.
Sidechains pegged with miner-validated locks:
Allows trustless-of-miner-majority sidechains. Critique: trusts miners implicitly with all sidechain funds.
Status (September 2026): BIP300 and BIP301 are both still
Draft, with no Bitcoin mainnet soft-fork activation and no
activation parameters. LayerTwo Labs runs testnet drivechains and
maintains bip300301_enforcer, "CUSF software enforcing BIP300 and
BIP301 rules" - a client-side user soft fork enforcement path that
does not require a Bitcoin-wide deployment - plus
cusf-enforcer-mempool, which patches getblocktemplate to mine
CUSF-compliant blocks.
Beyond Bitcoin, LayerTwo Labs stopped waiting for a soft fork: Paul Sztorc announced an "eCash" hard fork of Bitcoin targeting block 964,000 (August 2026), with a one-time minimum-difficulty reset, a 1:1 airdrop to BTC holders and BIP300/301 drivechains enabled from day one. It is heavily contested because the plan also describes a partial reassignment of coins for development or community incentives (Bitcoin.com News, 2026-06-22). That chain is not Bitcoin: a drivechain running there says nothing about BIP300/301's status on Bitcoin mainnet.
Sidechain idea using OP_CAT (BIP347) + OP_CHECKSIGFROMSTACK
(BIP348, also unactivated) to enable arbitrary-script verification
without explicit miner support.
Status: Concept. Not a formal BIP.
Aggregate all signatures in a transaction into a single signature. Massive witness savings (n inputs → 1 sig instead of n sigs). Active research; not yet a deployable proposal.
As of September 2026 CISA is rarely discussed standalone: the live question is whether to bundle it with a post-quantum output type. Pieter Wuille put the maximum weight reduction at about 28%, and only for transactions with many inputs, argued wallet and custodian support is the real bottleneck, and warned that bundling would delay a P2TRv2 soft fork; Adam Gibson agreed. Conduition argued pairing CISA with P2TRv2 would strongly incentivise migration, and that a CISA-supporting output type can ship first with ordinary BIP340 signatures and gain aggregation later (Optech, 2026-09-04).
Post-quantum work is now a dominant consensus-track discussion and covers far more than signature schemes.
| Proposal | What it is | Status |
|---|---|---|
| BIP360 | Pay-to-Merkle-Root output type | Draft (v0.12.1) |
| BIP361 | PQ migration / legacy signature sunset | Draft, Informational |
| P2TRv2 | Candidate PQC output type, not a BIP | Under discussion |
| SHRINCS | Semi-stateful hash-based signatures | Draft spec, no BIP |
| DropKick | Commit/reveal rescue for stranded coins | Sketch |
libshrincs with
machine-checked WOTS+C proofs. A signature scheme only - deployment
would be a separate proposal.Also live: a proposed segwit commitment to post-quantum witness data (Optech, 2026-08-07) and a post-quantum path for BIP324 P2P transport encryption (Optech, 2026-06-05).
Reusing a SHRINCS stateful counter lets an observer forge signatures; Antoine Riard noted 5,777-byte stateless signatures would be roughly 90x today's onchain cost absent a witness discount. None of these is activated, numbered as a consensus deployment, or scheduled.
Any engineer reasoning about Bitcoin covenants today will run into these. All Draft, none deployed, as of September 2026:
| BIP | Title | Author(s) |
|---|---|---|
| 440 | Varops Budget For Script Runtime Constraint | Russell, Moik |
| 441 | Restoration of disabled script (Tapleaf 0xC2) | Russell, Moik |
| 442 | OP_PAIRCOMMIT | moonsettler, Brandon Black |
| 443 | OP_CHECKCONTRACTVERIFY | Salvatore Ingala |
| 446 | OP_TEMPLATEHASH | Sanders, Poinsot, Roose |
| 448 | Taproot-native (Re)bindable Transactions | Sanders, Poinsot, Roose |
| 449 | OP_TWEAKADD - x-only key tweak addition | Jeremy Rubin |
Alongside them, BIP53 "Disallow 64-byte transactions" (Chris Stewart, Draft) is the standalone spec for one of BIP54's four fixes.
BIP-3 replaced the older BIP-2 status set. Current statuses:
| Status | Meaning |
|---|---|
| Draft | In the BIPs repo, work ongoing |
| Complete | Planned work concluded; adoption recommended |
| Deployed | Evidence of active use; for a soft fork, activated |
| Closed | Of historical interest only; not worked on or in use |
A Specification BIP needs a reference implementation and comprehensive test vectors before it can move to Complete.
The BIP-2 names still appear in secondary sources and in this
corpus's older material. BIP-3 renamed Proposed to Complete,
folded Deferred, Obsolete, Rejected, Replaced and Withdrawn
into Closed, and Final and Active into Deployed. Older
material in this corpus that says "Proposed" means Complete. A
Closed BIP may carry a Proposed-Replacement: <n> header naming its
successor (BIP345 does, pointing at 443).
For consensus changes, Deployed requires a successful soft-fork
deployment — never assume it from Complete. BIP54 and BIP347 are
both Complete and neither is active on mainnet.
nLockTime = height - 1) with BIP9 signaling. They are different
things and only the latter can lock in a soft fork.