OP_CSFS
What Is OP_CSFS?
OP_CSFS stands for OP_CheckSigFromStack. It is a proposed new instruction for Bitcoin’s scripting language that expands what Bitcoin scripts can verify.
Under the current Bitcoin protocol, a signature inside a script can only be validated against the transaction that spends a given output. OP_CSFS breaks that constraint. It lets a script verify a signature against arbitrary message data supplied in the transaction itself, such as a pre-committed statement from an oracle or an off-chain policy, rather than being limited to the transaction’s signature hash.
The proposal has circulated in Bitcoin development discussions for several years and is often discussed alongside OP_CTV (OP_CheckTemplateVerify) as part of a broader set of script-enhancement proposals, though the two serve distinct purposes and operate independently.
How Does OP_CSFS Expand Bitcoin’s Scripting Capabilities?
When a Bitcoin script executes today, signature-checking opcodes like OP_CHECKSIG only work on the transaction being signed. OP_CSFS adds a new verification path, taking a public key, a signature, and a message from the script execution stack, and then checking whether the signature is valid for that specific message under that public key.
This unlocks several capabilities. Scripts can verify data signed by an external source, such as a price oracle, by having that signed message included in the transaction’s witness or script, without tying the verification to the transaction’s sighash.
OP_CSFS also allows Bitcoin Covenants to become more expressive, allowing funds to be locked under conditions that depend on signed claims about external state, provided those claims are supplied as data in the transaction. Delegation schemes become possible too: a key holder can sign a policy, and a script can verify that policy before permitting a spend.
OP_CSFS itself does not introduce a new signature scheme; it uses Bitcoin’s existing ECDSA or Schnorr verification under the hood.
Why OP_CSFS Raises the Stakes for Transaction Verification
For self-custody users, OP_CSFS-enabled scripts could eventually allow more sophisticated spending conditions: multi-party governance, time-locked inheritance setups, and oracle-dependent contracts enforced directly at the protocol level, with no reliance on trusted third parties.
It’s important to note that OP_CSFS has not been activated on Bitcoin mainnet. Activation requires broad consensus across developers, miners, and node operators through Bitcoin’s standard upgrade process.