BIP 348 (OP_CHECKSIGFROMSTACKVERIFY)

What Is BIP 348?

BIP 348 is a Bitcoin Improvement Proposal that introduces OP_CHECKSIGFROMSTACK (CSFS), a new Bitcoin Script opcode. While existing signature opcodes like OP_CHECKSIG can only verify whether a signature authorizes the current spending transaction, CSFS verifies a signature against any arbitrary message provided on the stack. This seemingly small change unlocks entirely new categories of programmability in Bitcoin.

The proposal was authored by Brandon Black and Jeremy Rubin. Its formal specification assigns opcode 0xcc, replacing OP_SUCCESS204, and restricts operation to BIP 342 tapscript (leaf version 0xc0). This means CSFS is available exclusively within Taproot spend paths, not in legacy or SegWit v0 scripts.

The concept originated on Blockstream's Elements Alpha sidechain, where CSFS was deployed alongside OP_CAT and used to build production covenant contracts on the Liquid Network. BIP 348 formalizes the opcode for Bitcoin mainnet, incorporating lessons from that sidechain experience: specifically that CSFS covenants require transaction data to be pushed onto the stack during spending, which increases witness size but provides full transaction introspection.

How It Works

To understand why BIP 348 matters, consider the difference between transaction-bound and message-bound signature verification.

OP_CHECKSIG: Transaction-Bound Only

When OP_CHECKSIG executes, it pops a public key and a signature from the stack, then internally computes the transaction's sighash (a hash of the transaction data according to the active sighash flag). The script never controls what message is being verified: it is always "did this key authorize this specific transaction?"

CSFS: Arbitrary Message Verification

BIP 348's OP_CHECKSIGFROMSTACK pops three elements from the stack instead of two:

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

It verifies the signature against the provided message and public key using BIP 340 Schnorr verification rules. Three outcomes are possible:

• Valid signature: pushes 1 to the stack
• Empty signature (zero-length byte vector): pushes 0 to the stack, enabling optional signature checks
• Any other invalid signature: script execution fails immediately

# OP_CHECKSIG (existing, BIP 342)
# Stack before: <signature> <pubkey>
# Internally computes sighash from the spending transaction
# Result: 1 (valid) or 0 (empty sig) on stack

# OP_CHECKSIGFROMSTACK (proposed, BIP 348)
# Stack before: <signature> <message> <pubkey>
# Message is explicitly provided, not derived from the transaction
# Result: 1 (valid) or 0 (empty sig) on stack

Key Type Handling

BIP 348 follows the same key type semantics as BIP 342:

• 32-byte keys are verified using Schnorr signatures (the only currently defined key type)
• Zero-length keys cause script execution to fail
• Keys of any other length are treated as unknown key types: verification succeeds unconditionally, preserving forward compatibility for future signature schemes

Soft Fork Deployment

BIP 348 uses the OP_SUCCESS upgrade mechanism from BIP 342. Nodes that have not upgraded encounter opcode 0xcc and treat it as OP_SUCCESS, marking the entire script as valid without further evaluation. Upgraded nodes interpret 0xcc as OP_CHECKSIGFROMSTACK and perform full signature verification. This makes BIP 348 a clean soft fork: the new rules only restrict validity, never expand it.

CSFS operations count against the tapscript sigops budget, the same resource accounting that applies to OP_CHECKSIG and OP_CHECKSIGADD. This prevents abuse through excessive signature verification within a single script execution.

Use Cases

Oracle Attestations

BIP 348 allows Bitcoin scripts to verify that an oracle has signed a specific piece of data. An oracle publishes a signed attestation (a price feed, 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 on-chain verification mechanism without requiring the oracle to be aware of the contract structure.

Delegated Spending Authority

With CSFS, a key holder can sign a message authorizing another party to spend coins under specific conditions. The delegate presents two proofs when spending: the delegation authorization (verified via CSFS) and their own spending signature (verified via standard OP_CHECKSIG). This avoids creating a new multisig arrangement or moving funds on-chain, making it more private and efficient than alternatives.

Covenant Constructions

CSFS alone does not implement covenants: it verifies signatures but does not inherently bind those signatures to transaction structure. To enforce spending restrictions on future transactions, CSFS must be combined with other opcodes:

• With CTV (BIP 119): CTV commits to the spending transaction's outputs and structure, while CSFS verifies that a key has authorized a specific template. Together they enable vaults, payment pools, and channel constructions.
• With OP_CAT (BIP 347): OP_CAT concatenates individual transaction fields on the stack, reconstructing the sighash. CSFS then verifies a signature against the reconstructed data, achieving full transaction introspection.

For a deeper comparison of these approaches, see the Bitcoin covenants research article.

Lightning Symmetry (Eltoo)

One of the most anticipated applications of BIP 348 is enabling Lightning Symmetry channels. Current Lightning channels use a penalty-based mechanism: if one party broadcasts an old state, the counterparty can 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 SIGHASH_ANYPREVOUT behavior: signatures that are not bound to a specific input. BIP 348's CSFS, combined with CTV, can emulate this without a separate sighash flag change. CTV constrains the transaction outputs while CSFS verifies authorization without committing to a specific previous output. This would significantly simplify Lightning channel management and reduce the storage burden on watchtowers.

The LNHANCE Bundle

BIP 348 is a central component of the LNHANCE soft fork proposal, which bundles three opcodes as a combined upgrade:

The LNHANCE proposal argues that these three opcodes together provide the minimal toolkit needed for symmetry channels, vault designs, and efficient covenant constructions. Each opcode is narrowly scoped and well-understood, which proponents consider a lower-risk path than broader opcodes like OP_CAT. For details on how CTV works independently, see the OP_CTV research article.

In addition to the original LNHANCE bundle, a newer proposal (BIP 448) bundles OP_TEMPLATEHASH (BIP 446) with BIP 348 and BIP 349, offering a related but distinct approach to the same goal of enabling Lightning Symmetry and covenant functionality.

History: From Elements to Bitcoin

OP_CHECKSIGFROMSTACK was first deployed on Blockstream's Elements Alpha sidechain, where it was combined with OP_CAT and other re-enabled opcodes to build production covenant contracts on the Liquid Network. Developers used it to construct a proof-of-concept vault based on the Möser-Eyal-Sirer design.

One key lesson from Elements: CSFS-based covenants are more complex than purpose-built alternatives because transaction data must be pushed onto the stack during spending. This increases witness size and script complexity. The exercise of running CSFS on a federated sidechain was specifically intended to identify common usage patterns that could inform optimized opcodes for Bitcoin mainnet.

BIP 348 incorporates these lessons. By restricting CSFS to tapscript and using Schnorr signatures exclusively, it avoids the complexity of supporting multiple signature schemes and leverages Taproot's batch verification capabilities.

Comparison with Other Chains

Several Bitcoin-adjacent platforms already have CSFS-style functionality:

• The Liquid Network (Elements) has had OP_CHECKSIGFROMSTACK since the Alpha sidechain, supporting production covenant contracts
• Some altchains implement similar introspection natively via broader smart contract languages, making a dedicated opcode unnecessary
• Bitcoin's approach with BIP 348 is intentionally conservative: rather than adding a general-purpose scripting language, it adds a single narrowly-scoped opcode that extends the existing Script model

Risks and Considerations

Witness Size Overhead

For covenant enforcement, the message being verified via CSFS typically contains a serialized representation of the spending transaction. This means transaction data appears in the witness twice: once as the transaction itself, and once as the message on the stack. The overhead increases transaction weight and cost, though it is bounded by tapscript's existing resource limits. Purpose-built opcodes like CTV avoid this duplication by hashing the transaction data internally.

Script Complexity

Building practical covenants with CSFS requires combining multiple opcodes and careful script engineering. Compared to purpose-built constructions like OP_VAULT (BIP 345), CSFS-based scripts are more general but harder to get right. Bugs in complex scripts could lead to funds being permanently locked or stolen.

CSFS Alone Is Not Introspection

A common misconception is that CSFS provides transaction introspection. It does not: it only verifies that a signature matches a message and key. Without a complementary opcode (CTV, OP_CAT, or a future introspection primitive), there is no way for the script to verify that the message actually represents the spending transaction. The signer must be trusted to construct the message honestly, unless additional opcodes enforce correspondence between the message and the transaction.

Activation Status

As of mid-2026, BIP 348 remains in draft status. It has been implemented in Bitcoin Core for regtest (PR #32247) and activated on Bitcoin Inquisition's signet alongside CTV and OP_CAT. However, no activation timeline has been set for mainnet. Developer consensus continues to build, with an open letter signed by over 40 Bitcoin developers and researchers calling for priority implementation of both CTV and CSFS, but the broader community debate about which covenant opcodes to prioritize is ongoing.

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.