OP_CHECKSIGFROMSTACK (CSFS)

OP_CHECKSIGFROMSTACK, abbreviated CSFS, is a proposed Bitcoin opcode described in BIP 348, with authorship credited to Brandon Black and Jeremy Rubin. On Bitcoin's base layer it is not active: it would require a soft fork, and as of this writing there is no consensus to deploy it and no timeline. Notably, equivalent functionality has been live on the Liquid Network and Elements since 2016 and on Bitcoin Cash since 2018, so the primitive itself is well understood in practice. We describe it neutrally for readers tracking Bitcoin's scripting roadmap.

What it does

Standard signature checks like OP_CHECKSIG only verify a signature against a digest of the spending transaction — the message is fixed by the protocol, and script has no say in it. CSFS instead takes three items off the stack — a signature, a message, and a public key — and verifies the signature against that arbitrary message. That one change frees signature verification from the transaction: a script can now demand proof that some key signed some statement, whatever that statement is. In the proposal's Tapscript context this uses Schnorr signatures, consistent with the rest of the Taproot stack.

Why it is useful

The flagship application is script delegation: a committed key can sign a message authorizing spending by some other key or condition, without moving coins on-chain to change the rules. Paired with OP_CHECKTEMPLATEVERIFY (CTV, BIP 119) it supports floating signatures that can attach to more than one transaction — a combination often discussed under the "LNhance" banner because of its relevance to Lightning, where it could simplify how channel protocols handle revocation and penalties. Combined with a proposal like OP_CAT, CSFS contributes to richer contract composition and introspection, since scripts could verify signatures over messages assembled on the stack. CSFS is not itself a covenant — it does not constrain where coins go — but it synergizes with covenant opcodes to build pre-signed and stateful protocols.

The case for and against

Proponents argue CSFS is among the most conservative items on the scripting wishlist: it is a single, well-scoped primitive with a decade of production history on other chains, it reuses the signature machinery Bitcoin already trusts, and its costs are easy to reason about. Skeptics apply the standard covenant-adjacent caution — that each new primitive expands the space of constructible protocols in ways that are hard to fully map in advance, and that Bitcoin's conservatism around consensus changes is a feature, not an obstacle. Both positions are reasonable; what is settled is only that discussion continues on standardization, deployment paths, and how CSFS ranks against alternative proposals.

Where to go deeper

A reader tracking the debate should also watch how proposals are evaluated, not just whether they pass: the review process weighs implementation simplicity, interaction with every existing opcode, and the precedent each change sets for future ones. CSFS's small surface area is its strongest card in that process, and the years of Liquid and Elements deployment supply the field data most proposals lack. Whatever the outcome, the deliberation itself is the base layer's security model working as designed — slow by intention, so that everything built on top can afford to be fast.

CSFS is best understood as one tile in the larger mosaic of proposed script upgrades, alongside covenant designs such as OP_CHECKCONTRACTVERIFY and generalized templating ideas like OP_TXHASH. None of these are consensus rules today; all remain research and proposal work. For a sovereign Bitcoiner, the practical posture is informed patience — understand what each primitive would enable, and let the deliberate pace of Bitcoin's consensus process do its job.