OP_CHECKSIGFROMSTACK (CSFS)

What Is OP_CHECKSIGFROMSTACK?

OP_CHECKSIGFROMSTACK (often abbreviated CSFS) is a proposed Bitcoin opcode defined in BIP 348, authored by Brandon Black and Jeremy Rubin. It allows Bitcoin Script to verify a digital signature against an arbitrary message provided on the stack, rather than only against the spending transaction itself.

Today, Bitcoin's existing signature opcodes like OP_CHECKSIG can only verify that a signature is valid for the current transaction's sighash: a commitment to the transaction's inputs, outputs, and other metadata. This means scripts can ask "did the owner authorize this specific transaction?" but cannot ask "did someone sign this particular piece of data?" CSFS removes that limitation, opening the door to entirely new categories of smart contracts on Bitcoin.

The opcode has gained significant momentum in the Bitcoin development community. An open letter signed by over 40 Bitcoin developers and researchers called for the priority implementation of both CTV (BIP 119) and CSFS (BIP 348), and the LNHANCE proposal bundles CSFS with CTV and OP_INTERNALKEY as a combined soft fork package targeting Lightning Network improvements.

How It Works

To understand why CSFS matters, it helps to see how standard signature verification works in Bitcoin today and what CSFS changes.

OP_CHECKSIG: Transaction-Bound Signatures

When a Bitcoin script executes OP_CHECKSIG, it performs these steps:

1. Pops a public key and a signature from the stack
2. Internally computes the transaction's sighash (a hash of the transaction data according to the active sighash flag)
3. Verifies the signature against the sighash and the public key

The message being signed is always derived from the transaction. The script has no control over what message is checked: it is always "does this signature authorize this spending transaction?"

OP_CHECKSIGFROMSTACK: Arbitrary Message Signatures

CSFS changes the equation. It pops three elements from the stack:

1. A 32-byte public key
2. A message (arbitrary data)
3. A signature

It then verifies that the signature is valid for the given message and public key using BIP 340 Schnorr verification. If the signature is valid, it pushes 1 to the stack. If the signature is the empty vector, it pushes 0 (allowing optional signature checks). Any other invalid signature causes script execution to fail.

# OP_CHECKSIG (existing)
# Stack: <signature> <pubkey>
# Internally computes sighash from the transaction
# Verifies: sig valid for sighash under pubkey

# OP_CHECKSIGFROMSTACK (proposed)
# Stack: <signature> <message> <pubkey>
# Message is provided explicitly on the stack
# Verifies: sig valid for message under pubkey

Technical Specification

BIP 348 assigns opcode 0xcc to OP_CHECKSIGFROMSTACK. It replaces OP_SUCCESS204 and is available only in BIP 342 tapscript (leaf version 0xc0). This means CSFS works exclusively within Taproot spend paths, not in legacy or SegWit v0 scripts.

The soft fork upgrade mechanism is clean: non-upgraded nodes encounter 0xcc and treat it as OP_SUCCESS, marking the script as valid without further checks. Upgraded nodes interpret the byte as OP_CHECKSIGFROMSTACK and perform the full Schnorr signature verification. This is the standard OP_SUCCESS upgrade path introduced by BIP 342.

CSFS operations count against the tapscript sigops budget, the same resource accounting applied to other signature-checking opcodes. This prevents abuse through excessive signature verification.

Why It Matters

The ability to verify signatures against arbitrary messages is a fundamental building block that unlocks several categories of Bitcoin functionality. On its own, CSFS enables delegation and oracle patterns. Combined with other proposed opcodes, it enables full covenant functionality.

Enabling Covenants with CTV

When paired with OP_CHECKTEMPLATEVERIFY (CTV), CSFS enables scripts to enforce constraints on how coins can be spent in the future. CTV commits to the structure of the spending transaction (outputs, sequences, locktime), while CSFS allows a signer to authorize specific transaction templates. Together, they let scripts verify that:

• A trusted key has signed off on a particular spending template
• The spending transaction matches a pre-committed structure
• Funds can only flow to designated destinations under specified conditions

This combination can emulate the behavior of SIGHASH_ANYPREVOUT (BIP 118), which is the key ingredient needed for Lightning Symmetry (eltoo) channels, without requiring a separate sighash flag change. For a deeper look at how these proposals interact, see the Bitcoin covenants research article.

Comparison with OP_CAT

OP_CAT offers an alternative path to similar covenant functionality. Where CSFS directly verifies a signature against an arbitrary message, OP_CAT achieves introspection by concatenating individual transaction fields on the stack and then using OP_CHECKSIG to verify the assembled data matches the actual sighash.

Historically, CSFS and OP_CAT were often proposed together: both existed in the Elements Alpha sidechain (used by Blockstream's Liquid Network) where they enabled production covenant contracts. In practice, CSFS and OP_CAT are complementary rather than competing: OP_CAT can construct messages on the stack, and CSFS can verify signatures against those messages. For more on OP_CAT's covenant approach, see the OP_CAT covenant debate research article.

Use Cases

Vaults

CSFS enables vault constructions where coins can only be spent through a time-delayed unvaulting process. A vault script can require that the spending transaction sends funds to a predetermined recovery address or waits for a timelock before releasing to the intended destination. This gives users a window to detect and respond to theft. Compared to OP_VAULT (BIP 345), which is purpose-built for vaults, CSFS-based vaults are more general but require more complex script construction.

Delegated Authorization

With CSFS, a key holder can sign a message authorizing another party to spend coins under specific conditions, without creating a new multisig arrangement or moving funds on-chain. The delegate presents the authorization signature along with their spending transaction, and the script verifies both: the delegation authorization (via CSFS) and the spending authorization (via standard OP_CHECKSIG).

Oracle-Verified Conditions

CSFS allows scripts to verify that an oracle has signed a particular piece of data, enabling on-chain contracts that settle based on real-world events. An oracle publishes a signed attestation (a price, a sports result, a weather reading), and the spending script uses CSFS to verify that attestation before releasing funds. This is closely related to discreet log contracts (DLCs), but CSFS provides a more direct and flexible verification mechanism.

Lightning Symmetry (Eltoo)

One of the most anticipated applications of CSFS is enabling Lightning Symmetry (formerly eltoo) channels. Current Lightning channels use a penalty-based mechanism where broadcasting an old state allows the counterparty to claim all channel funds. Symmetry channels replace this with a simpler model where any newer state can spend any older state, with no penalty risk.

Symmetry channels require the ability to sign transactions that are not bound to a specific input (SIGHASH_ANYPREVOUT behavior). CTV + CSFS together can emulate this: CTV constrains the transaction outputs while CSFS verifies authorization without committing to a specific previous output. This would be a significant improvement for Lightning channel management, reducing complexity and eliminating the need for watchtowers to store every prior channel state.

Non-Interactive Channel Opens

CSFS can enable channel constructions where one party pre-signs spending conditions for a channel without the other party being online. The signed message commits to the channel parameters, and when the second party comes online, they can open the channel using the pre-signed authorization. This is particularly relevant for Lightning Service Providers (LSPs) that need to open channels to mobile users who may only be intermittently connected.

The LNHANCE Proposal

LNHANCE is a soft fork proposal that bundles three opcodes: CTV (BIP 119), CSFS (BIP 348), and OP_INTERNALKEY. The package specifically targets Lightning Network improvements, arguing that these three opcodes together provide the minimal toolkit needed for symmetry channels, better vault designs, and more efficient covenant constructions.

By bundling CSFS with CTV, LNHANCE offers a conservative path to covenant functionality: each opcode is narrowly scoped, well-understood, and has been extensively reviewed. The proposal contrasts with broader opcodes like OP_CAT that enable more functionality but carry a wider risk surface. For background on how CTV works independently, see the OP_CTV research article.

Risks and Considerations

Witness Size Overhead

For full transaction introspection, CSFS requires the message being verified to be placed on the stack. If that message is a serialized representation of the transaction (needed for covenant enforcement), the witness data can grow significantly. This increases transaction weight and cost, though the overhead is bounded by tapscript's existing resource limits.

Complexity of Covenant Construction

While CSFS is a general-purpose primitive, building practical covenants with it requires combining multiple opcodes and careful script engineering. Purpose-built opcodes like OP_VAULT are simpler for specific use cases (vaults), while CSFS offers flexibility at the cost of script complexity. Bugs in complex scripts could lead to funds being locked or stolen.

Activation Path Uncertainty

As of mid-2026, CSFS remains in draft status (BIP 348). While developer consensus has been building (with implementation PRs submitted to Bitcoin Core and activation on Bitcoin Inquisition's signet), the activation timeline depends on broader community agreement about which covenant opcodes to prioritize. The debate between CSFS + CTV, OP_CAT, OP_VAULT, and other proposals continues.

Scope of Functionality

CSFS alone does not provide transaction introspection: it only verifies that a signature matches a message and key. To enforce covenants, the message must somehow represent the spending transaction, which requires either trusting the signer to construct the message honestly or combining CSFS with other opcodes (like CTV or OP_CAT) that can reconstruct transaction data on the stack.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.