What Is CUSF? How eCash Runs Drivechains Without Touching Bitcoin's Code
CUSF stands for Core Untouched Soft Fork. It is a way to add new rules to Bitcoin without changing Bitcoin Core's code.
Instead of editing the node, you run a second program beside it. That program checks the new rules and tells the node to throw out any block that breaks them.
Paul Sztorc proposed CUSF in 2024 as a way to get drivechains onto Bitcoin. Today it is how drivechains run on eCash (ECX). This article explains what CUSF is, how it works, and what its critics say.
What is CUSF? The short answer
CUSF is a soft fork that lives outside the node. A separate program, called an enforcer, watches every new block.
If a block breaks the new rules, the enforcer tells the node to reject it. The node itself stays unchanged, so nobody has to merge anything into Bitcoin Core.
On eCash, the enforcer checks the drivechain rules from BIP 300 and BIP 301. It has done so since the fork block, 973,728.
Last verified: November 3, 2026.
The problem CUSF tries to solve
A normal soft fork changes Bitcoin Core itself. The code has to be written, reviewed, merged and released before anyone can turn it on.
In Paul's CUSF paper, he describes the cost of that route. A developer can spend 20 or more hours rebasing a proposal onto each new Core release. That can repeat every three months for two years before a merge.
By Paul's count, Bitcoin activated only two soft forks between 2017 and 2025: SegWit and Taproot. Many proposals, from CTV to OP_CAT, are still waiting. Paul argues the bottleneck is the review process, not the ideas.
CUSF skips that queue. If miners and users want a new rule, they run the program that enforces it. If they stop wanting it, they stop running it.
How the CUSF enforcer works
The eCash enforcer is a program written by LayerTwo Labs. It sits next to the node and does four jobs.
It watches. It reads each new block from the node as it arrives.
It checks. It tests the block against the drivechain rules, such as the vote counts on withdrawals.
It rejects. If a block breaks a rule, it calls the node's own invalidateblock command. The node drops that block and its children, then follows the next best chain.
It helps miners. It screens the mempool and builds block templates, so miners never build on a bad block by mistake.
The trick is that invalidateblock already exists in Bitcoin Core. It is a standard command for marking a block as bad. CUSF uses it to enforce rules Core does not know about.
The enforcer needs the full chain to do its job. It refuses to run beside a pruned node, one that has deleted old blocks to save space.
How a CUSF rule gets switched on
In Paul's design, a CUSF rule activates when miners with more than half the hashrate run the enforcer. Users who want the feature run it too.
Turning it off is just as simple. People stop running the program, and the rule lapses. No second fork is needed to undo it.
How eCash uses CUSF
eCash is a hard fork of Bitcoin, so its node is not untouched. LayerTwo Labs changed Bitcoin Core's code for the fork itself. That covers the fork height, replay protection and a new difficulty adjustment.
The drivechain rules are different. They are not in eCash's node at all. They live in the enforcer, CUSF style.
That split explains a few things eCash users notice.
BitWindow runs three programs: the eCash node, the enforcer, and each sidechain you use.
Drivechain rules can change without a new node release. On October 28, 2026, an enforcer update set eCash's withdrawal vote to more than 6,048 approvals in 12,096 blocks. The node did not change.
An enforcer bug is a mining problem, even when the node is fine. Miners take their block templates from it.
For why slow, voted withdrawals matter, read The Liquid Hack: Do Drivechains Fix This?
What it looks like when the enforcer breaks
eCash has already run this experiment, by accident.
In the first days after the fork, one mining pool produced a run of nearly empty blocks. Its operator explained why on November 3, 2026. A bug in the enforcer's mempool tracker had dropped most of the mempool from their block templates.
The node was fine. The enforcer was not, and the enforcer builds the templates.
They said the fix went live at 12:48 UTC on November 2. Only 2 of their next 77 blocks were near empty. They filed the bug upstream.
There is a second number worth setting beside that. On November 4 the same operator said their pool held about 94% of recent eCash blocks. They called that unhealthy for the network and began moving hashrate to Bitcoin.
Put those together and you get the honest state of CUSF on eCash today. The drivechain rules hold because miners enforce them. Most of that hashrate has been in one place, and that one place had an enforcer bug.
What if you don't run the enforcer?
If you just hold ECX in a wallet, you do not need the enforcer. Your wallet follows the chain that miners build, and enforcing miners build only valid blocks.
If you run your own node without the enforcer, it acts like an old node after a soft fork. It accepts blocks that break the drivechain rules, because it does not know them. As long as most hashrate enforces the rules, the valid chain wins and your node follows it.
Miners face more risk. A miner without the enforcer could build on a block the rest of the network rejects. That miner loses the reward.
Mining through a pool is different. The pool's enforcer builds the template, so individual miners pointing machines at it are covered.
The case against CUSF
CUSF has critics, and some of their points are fair.
Is it really a soft fork?
A developer raised this on the Delving Bitcoin forum in 2024. They argued it is "only a soft fork if there is economic consensus" to run it. If few nodes run the enforcer, the rules are only as strong as the miners who choose to apply them.
Early movers carry the risk
Paul's own paper admits this one. The first miners to run a new rule take most of the risk, while later miners free-ride. If a CUSF rule has too little hashrate behind it, its blocks can be undone.
It reacts after the fact
The node accepts a block first, and the enforcer rejects it a moment later. That is by design, and it works. But it is less direct than a rule built into the node's own checks.
One more thing to run
A separate program is one more thing to install, update and keep running. When it breaks, mining feels it, even if the node is fine.
Even the name has critics. One developer in the same forum thread called it "pretty horrible."
What else could CUSF carry?
Drivechains are the first big CUSF use, but Paul's paper names others. These are Bitcoin proposals that have waited years for Core to merge them.
CTV (BIP 119), a way to restrict where coins can be sent next.
OP_CAT, an old opcode that joins two pieces of data.
OP_VAULT, for safer cold storage.
BIP 118, which lets signatures work across more than one transaction.
Any of these could, in principle, run as a CUSF on Bitcoin or eCash. None has been announced for eCash.
CUSF FAQ
What does CUSF stand for?
Core Untouched Soft Fork. It is a soft fork enforced by a separate program, not by changes to Bitcoin Core.
Who invented CUSF?
Paul Sztorc, the inventor of drivechains. He published the CUSF paper in June 2024.
Does eCash use CUSF?
Yes, for drivechains. eCash's node is a modified Bitcoin Core. The BIP 300 and BIP 301 drivechain rules are enforced by a separate CUSF enforcer.
Do I need to run the enforcer to hold ECX?
No. Holding and sending ECX works without it. Miners, and anyone who wants their node to check drivechain rules, run it.
Can CUSF bring drivechains to Bitcoin?
In theory, yes. If more than half of Bitcoin's hashrate ran the enforcer, BIP 300 rules would apply on Bitcoin. That has not happened.
How do you turn off a CUSF?
People stop running the enforcer. The rule then lapses without another fork.
Related reading
Sources
Paul Sztorc, CUSF paper v0.4.1, June 23, 2024
LayerTwo Labs bip300301_enforcer, source code read at version 1.0.1, for invalidateblock use, the pruning check, eCash's activation at block 973,728 and its withdrawal thresholds
Enforcer PR 685, merged October 28, 2026
Delving Bitcoin: Drivechain with and without BIP 300/301, August 2024
Drivechain FAQ, updated December 2025, for Paul's count of Bitcoin soft forks since 2017
The empty-block cause, the fix times and the 94% hashrate figure are from the pool operator's own statements in the public eCash developer group, November 3 and 4, 2026
Comments