Autor Cointelegraph by Kyrian Alex

This is Part 4 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article, click here. The following opcodes do not independently implement full covenant functionality. Instead, they are building blocks for constructing covenants when combined with other opcodes or script elements.OP_CHECKSIGFROMSTACK (OP_CSFS) and OP_CATOP_CSFS is a proposed opcode that would allow Bitcoin script to verify signatures over arbitrary messages supplied on the stack. It is different from OP_CHECKSIG, which verifies signatures over the spending transaction according to the active SIGHASH mode. By enabling signature verification for data other than the serialized transaction details, OP_CSFS enables a broader class of constructions, including oracle-based scripts where an external party signs off-chain messages that represent real-world events. For example, a trusted oracle could publish Schnorr signatures over messages that encode external outcomes, and an OP_CSFS-based script could condition payments on the presence of a valid oracle signature. On its own, OP_CSFS does not implement covenants. It can authenticate external data, but it does not bind that data to the structure of the spending transaction. That binding requires OP_CAT.OP_CAT is a proposed opcode that enables the concatenation of two values on the script stack to form a single byte sequence instead of two distinct ones. When combined with OP_CSFS, it allows the script to assemble selected transaction fields into a canonical message and verify that a provided signature commits to that message.OP_CSFS and OP_CAT taken together can perform introspection by compelling the spender to provide transaction details on the witness stack. If both OP_CSFS and OP_CHECKSIG succeed for the same signature, it proves that the correct transaction details have been passed on to the witness stack and can be further reasoned about. By checking the transaction against a predefined template, a covenant construction, similar to OP_CTV, can be enforced. Two minimal assemblies show how this works:OP_CAT + Schnorr TricksUsing OP_CAT, covenant-like constructions can be enforced under Taproot without OP_CSFS by exploiting how Schnorr signatures interact with the Taproot sighash rules defined in BIP 341. The construction repurposes OP_CHECKSIG which is ordinarily used to authenticate ownership of a private key, to a transaction introspection tool.A schnorr signature is a pair ⟨R, s⟩. Under normal circumstances, this schnorr signature is generated by selecting a secret nonce k, deriving the point R = kG, and computing the signature value s as a function of the message hash and the private key. The verifier then checks the signature pair ⟨R, s⟩ against a public key P and the message being signed. The randomness of k ensures that s is unpredictable and non-reproducible without knowledge of the private key.The introspection trick works by eliminating randomness by fixing some of these variables in advance. Instead of choosing R randomly during signing, the script commits to a predetermined value of R and to a fixed public key P. Because Schnorr verification follows a deterministic equation, it becomes possible to construct these values so that the signature scalar s must equal a hash of specific transaction parameters.The spender provides R and s on the witness stack. OP_CAT concatenates them into the signature pair ⟨R, s⟩ in the format OP_CHECKSIG expects. The script verifies this against the hardcoded public key P. Because R and P are fixed to the base point G, OP_CHECKSIG will only accept the pair if s equals the SHA256 hash of the actual transaction data computed by the protocol. The spender cannot fabricate an s that passes OP_CHECKSIG unless it genuinely reflects the real transaction data. The spender must grind the transaction data until its SHA256 hash ends in a specific byte, which takes roughly 256 attempts on average and adds negligible cost. In this way, OP_CHECKSIG is no longer used to authenticate ownership of a secret private key but instead to enforce that the transaction matches a specific template.  The expressiveness is broadly comparable to OP_CTV.Because this approach depends on Schnorr signatures and the taproot sighash algorithm, it applies only to SegWit v1 outputs and does not extend to SegWit v0 outputs which uses the BIP-143 digest and ECDSA signatures.In our next article we will commence our discussion of OP_CCV, which is even more capable than OP_CSFS and OP_CAT combined.

After the 2008 Great Financial Crisis, regulations forced European banks to hold more capital against riskier loans. As a result, SME loans became less attractive because they carried similar underwriting and monitoring costs as larger loans but generated lower absolute returns. Private credit firms filled some of the gap but exposed borrowers to floating rates that became unbearable when rates spiked. Now, European SMEs face a €39 billion annual funding gap. Cointelegraph Research’s new report identifies a structured-access hybrid model within RWA private credit that could help close the funding gap with onchain capital. One platform using this approach has already originated 15.4 million USDC across 2,143 investors.Read the full Cointelegraph Research report hereRWA Private creditA key advantage of RWA private credit is fractionalization. In traditional private credit, a single loan position is held entirely by one lender or distributed among a small group of institutional investors through a fund structure. Fractionalization splits the position into smaller units, each representing a proportional claim on the same underlying loan, which makes positions easier to transfer and opens the investor base beyond domestic institutional capital. A retail investor in Indonesia can hold $500 worth of exposure to a Czech SME loan without going through a local broker, custodian, or fund administrator, with settlement clearing instantly through stablecoins across borders.Excluding stablecoins, onchain RWA value has grown from roughly $2.7 billion in January 2024 to about $30 billion in April 2026. Sovereign debt remains the largest segment of RWA at $14.8 billion, while private credit sits at $6.1 billion, commodities at $5.4 billion, and equities at $2.1 billion. However, the growth of RWAs confirms demand for yield-bearing assets that can integrate with crypto-native capital, but it does not prove that retail access for SMEs has been solved. SMEs typically secure credit with tangible assets such as machinery, equipment, vehicles, inventory, or real estate. But most existing RWA products accept financial collateral such as receivables, treasuries, or crypto-native assets. They also remain restricted through accredited investor requirements, minimum capital thresholds, or mandatory KYC onboarding. For example, Centrifuge’s ACRDX limits participation to non-U.S. accredited investors and requires a $500,000 minimum investment. Ondo Finance’s tokenized treasury products require KYC verification and block access from several jurisdictions. Canton Network targets regulated financial counterparties rather than open retail participation.Structured-access hybrid modelAn emerging model under RWA private credit that addresses this mismatch is called the structured-access hybrid model. Under this model, investors deploy stablecoins into smart contracts, which then route capital to regulated lenders that verify borrowers, inspect tangible assets, and enforce legal liens.One such example of a project building under the structured-access hybrid model is 8lends. It is the retail-facing Web3 interface for Maclear AG, which is a Swiss-registered financial intermediary founded in 2020 and operating as a financial intermediary under PolyReg SRO oversight. In this structure, 8lends functions as the distribution and settlement layer for loans that Maclear originates and underwrites. Investors deposit a minimum of 100 USDC to gain exposure to these SME loans.As of Q2 2026, 8lends has funded approximately 15.4 million USDC in originations. Of this, 5.79 million USDC has been repaid (~38%) and 9.61 million USDC remains in active credit (~62%), serving 2,143 investors. Read the full report to see how the structured-access hybrid model compares to other RWA architectures, what risks remain as these platforms scale, and whether this approach can fully close the €39 billion SME funding gap.

This is Part 3 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article click here. SIGHASH_ANYPREVOUT, as proposed in BIP 118, builds on the earlier SIGHASH_NOINPUT concept mentioned in the 2015 Lightning Network paper by Joseph Poon and Thaddeus Dryja, and later formally proposed by Joseph Poon on the bitcoin-dev mailing list in February 2016.SIGHASH_ANYPREVOUT is not a new opcode but a proposed new value for the SIGHASH flag, designed to be deployed as a soft-fork upgrade to Bitcoin. The SIGHASH flag is appended to a signature and determines which parts of a transaction are signed and will be checked by the CHECKSIG opcode. The selected flag is chosen by the signer, not enforced by the scriptPubKey. Due to the technical details related to upgradability in a softfork, the SIGHASH_ANYPREVOUT proposal only extends to spends from taproot addresses.A variety of standard SIGHASH modes already exist, as illustrated in Figure 1. If the flag is set to SIGHASH_ALL, the signature must cover all inputs, all outputs, and the specific outpoint being spent, thus cryptographically binding the authorization to that exact UTXO. An outpoint is the combination of a transaction ID and an output index that together uniquely identify which UTXO a transaction is consuming. With SIGHASH_NONE, only the inputs need to be signed, leaving the outputs unconstrained. The SIGHASH_SINGLE variant signs all inputs, but only the output at the same index as the input being signed. The ANYONECANPAY modifier introduces further flexibility by allowing a single input to be signed independently of the others. Crucially, none of these existing modes allows a signature to omit commitment to the outpoint. That restriction is what SIGHASH_ANYPREVOUT removes.BIP-118 defines two ANYPREVOUT variants that differ in how much of the previous output they omit from the digest, summarised in Figure 2. Under SIGHASH_ANYPREVOUT, the outpoint is excluded from the digest, but the signature still commits to the amount and scriptPubKey of the previous output, as well as the input’s nSequence. Under SIGHASH_ANYPREVOUTANYSCRIPT, the amount and scriptPubKey are also excluded, meaning the signature is not bound to the locking script of the spent output at all. All other commitments follow the standard Taproot signature message construction and depend on the selected base flag, such as SIGHASH_ALL or SIGHASH_SINGLE.Because the outpoint is omitted from the digest, the same signature can authorize spending any compatible UTXO that satisfies the remaining committed fields. For example, a transaction pre-signed with ANYPREVOUT | ALL to produce a 0.5 BTC output can be reused if the same address later receives another UTXO of 0.5 BTC, even if the private key used to create the original signature is no longer available. If the new UTXO holds more than 0.5 BTC, however, the excess will be lost to miners unless the original signature included a change output. This rebinding property is what makes ANYPREVOUT useful for layer-2 protocols, where the same pre-signed transaction must apply to multiple possible on-chain UTXOs without requiring new signatures for each one.For covenant-like applications, the ANYPREVOUT variants preserve commitment to the scriptPubKey of the previous output, and are typically the most relevant. They allow signatures to be reused across compatible UTXOs while ensuring funds remain bound to the same locking script. ANYPREVOUTANYSCRIPT removes this binding entirely and is therefore less suited to covenant-style applications.Similar to OP_CTV, SIGHASH_ANYPREVOUT improves on the logic already achievable with pre-signed transactions but does not by itself enable recursive covenants or transaction introspection. Instead, it relaxes the binding between a signature and a specific UTXO, allowing a signature to be reused across multiple compatible UTXOs.Some research has also noted that removing the outpoint commitment makes recovered-key constructions possible — that is, a public key can be derived from a fixed signature and message pair such that the corresponding private key is provably unknown to anyone, making the UTXO’s key path provably unspendable and forcing any spend through the script path. It would avoid the need for temporary keys, which are otherwise required to make the key path unspendable in constructions that rely on script-path-only enforcement. This observation appears in Bitcoin Covenants: Three Ways to Control the Future by Jacob Swambo et al. (2020), although it remains a theoretical construction rather than a design proposed in BIP-118.The primary risk associated with SIGHASH_ANYPREVOUT signatures is signature replay. Because these signatures do not commit to a specific outpoint, the same signature can be used to spend a different UTXO than the one originally intended, provided the new UTXO satisfies the remaining committed fields. This risk becomes more pronounced in specific configurations: when ANYPREVOUT | SINGLE is used and output amounts can be rearranged; when a separate UTXO exists with the same scriptPubKey and amount, in the case of ANYPREVOUT; when the same public key appears in a compatible script, in the case of ANYPREVOUTANYSCRIPT; or when a miner can influence transaction ordering and inclusion to exploit these conditions. However, these scenarios require either deliberate misuse or a failure of the user or developer to account for replay conditions during protocol design.In our next article we will commence our discussion of Opcodes that serve as supporting tools. These extend the expressiveness of Bitcoin script or data handling but do not implement covenant functionality unless combined with other opcodes. In this next category, we will discuss OP_CHECKSIGFROMSTACK and OP_CAT.

Recently, the concept of so-called covenants has received renewed attention as Bitcoin development and protocol discussions underwent a renaissance. Covenants could enable and facilitate a wide range of applications, including new trustless and scalable layer 2s, fully non-custodial vaults with more complex spending logic, and more efficient payment channels. However, most paths to implementing this functionality require a soft fork of Bitcoin’s consensus rules, a process that would likely spark debate within the community.With the recent diversification of consensus clients into Core and Knots nodes, reaching agreement on such a change has become less likely. In spite of recently pushing for a soft-fork of their own, namely BIP-110, the Knots side tends to advocate for protocol ossification and appears less supportive of facilitating scaling solutions on the base layer. The recent controversy that Bitcoin Core has attracted, both as a technical debate and in governance, is diminishing the prospect of covenant implementations on Bitcoin anytime soon.Prominent figures such as Michael Saylor have also publicly advocated for protocol ossification, portraying zealous, well-funded developers as the greatest threat to the protocol. Nonetheless, some minimal covenant implementation likely offers the most conservative path to trust-minimized Layer-2s, which can bring the privileges of self-custody to the next billion people. Should mainnet fees spike again in the future and a resolution to the spam wars is found,  discussions around these proposals are likely to regain momentum. In this article, we will lay some of the foundations for our readers to understand covenants. In follow-up pieces we will take a deep dive into individual proposals. To understand covenant proposals, it is necessary to grasp the basic validation flow for Bitcoin transactions. Bitcoin locking conditions are expressed in a stack-based, non-Turing-complete language called Bitcoin Script. The sender of a Bitcoin transaction specifies the spending conditions in this language by creating a so-called locking script (also known as scriptPubKey). When the recipient of the funds later wants to spend the outputs, they must provide the corresponding unlocking script (also known as scriptSig) that fulfills these conditions. Bitcoin’s scripting language can express a variety of validation conditions. It can verify public key signatures, enforce timelocks, verify hash preimages, and combine spending conditions with propositional logic. An entity with the correct unlocking script can move the Bitcoin to any arbitrary location, i.e., encumber them with any arbitrary scriptPubKey. However, it cannot put restrictions on where funds are sent after the correct scriptSig is provided.It is this feature that covenants aim to enable. Covenants would allow users to impose restrictions on how coins can be spent in the future. The concept was introduced by Gregory Maxwell all the way back in 2013 to improve the scalability and flexibility of Bitcoin. It was later popularised by Möser, Eyal, and Sirer in 2016. Maxwell initially proposed using zk-SNARKs to impose spending restrictions. Since then, the discussion has seen an explosion of different proposals, culminating in some that may sidestep the requirement for a soft fork.Basic (or precomputed) versus General (or recursive) covenantsA key distinction in covenant proposals lies between basic (or precomputed) and general (or recursive) covenants. In principle, basic covenants only impose restrictions on the next transaction in line. However, by chaining together encumbered addresses, basic covenants can also be used to define a finite sequence of transactions in advance. While this sequence of permitted transactions can be arbitrarily long or complex, it must be specified beforehand. General covenants would be able to express recursive spending rules directly within Bitcoin Script. This allows a spending condition to be reapplied indefinitely. For example, if Alice sent Bob 1 BTC, a basic covenant could ensure Bob can only send the funds to a specific address or encumbers it for a fixed number of steps. Under a general covenant, however, the UTXO worth 1 BTC would retain its same spending restrictions when Bob sends it to Steve, and again when Steve transfers it further, without any predefined endpoint. Although general covenants would offer greater versatility, they face significant technical hurdles and are viewed critically by the community. Their implementation would also require major protocol updates.Proposed Covenant Implementations and Their ApplicationsVarious implementation proposals and debates have shaped our understanding of how covenants could enhance Bitcoin’s functionality. To navigate this topic clearly, it is important to distinguish the proposed changes into four categories:Opcodes that fully implement covenant functionality. They directly impose spending restrictions on Bitcoin transactions. This includes OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT.Opcodes that serve as supporting tools. These extend the expressiveness of Bitcoin script or data handling but do not implement covenant functionality unless combined with other opcodes. In this category, we will discuss OP_CHECKSIGFROMSTACK and OP_CAT.Opcodes for specialized applications. We consider OP_VAULT, OP_UNVAULT and OP_EVICT.Proposals that approximate covenant behavior without a soft fork. These rely on cryptographic constructions within existing consensus rules or trust-minimized infrastructure rather than new opcodes. Within this category, we will discuss ColliderScript, Bitcoin PIPE and FE-based covenants. In our next article we will commence our discussion of the first category of covenant proposals by covering OP_CHECKTEMPLATEVERIFY — one of the most popular proposals so far.