Ever since the Bitcoin community embarked on discussions surrounding the optimization of covenants, there’s been a growing interest in learning more about their tradeoffs and the covenants already deployed on the Liquid Network.
In light of this renewed interest and to encourage further discussion, let’s review some of Liquid’s current covenant offerings, comparing them with the leading proposals on Bitcoin and examining their respective use cases.
History of Covenants on Liquid
Covenants on Liquid can be traced back to the deployment of the first Elements sidechain, Alpha. This sidechain introduced the opcodes OP_CHECKSIGFROMSTACK (CSFS) and OP_DETERMINISTICRANDOM along with a number of others to Elements. Alpha also enabled fixed versions of opcodes disabled in early Bitcoin, such as OP_CAT—an opcode many are choosing to revisit in the growing dialogue across social media. These new opcodes further improved the expressivity of the version of Bitcoin Script available in Elements, and a proof-of-concept Möser-Eyal-Sirer vault was developed utilizing CSFS to illustrate the new possibilities.
One of the learnings from implementing CSFS was that it makes covenants more complex by requiring transaction data to be pushed on the stack when performing a covenant spend. It was also observed from developer experience that with CSFS covenants, the transaction data that make up the signature hash has to be reconstructed on the stack, potentially forcing developers to push data irrelevant to the transaction inputs/outputs they are interested in.
To simplify covenant construction, more than 30 new opcodes called introspection opcodes were introduced in Liquid’s Taproot upgrade for a more modular approach. Introspection opcodes with CSFS, for example, enable the inspection of more granular parts of the transaction during a spend by placing it on the stack. This alleviates the responsibility of assembling partial transaction data via the witness and, therefore, the signature hash on the stack.
Leading Covenant Proposals
Currently, the Bitcoin community is discussing a laundry list of potential covenant proposals, including SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, the MATT opcode OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT, and OP_CHECKTEMPLATEVERIFY (CTV). Simplicity, a next-generation scripting language that could implement functionality similar to many covenants at a lower level, is also a potential route for Bitcoin (we’ll revisit this later).
There has been a lot of talk about the VAULT opcode, which was created to address the need for easier ways to secure bitcoin for users. This opcode would allow coins to be locked in an address that can only spend to two addresses: a hot wallet after a timelock or immediately to a cold wallet. Several other variant schemes have been proposed, but they depend on adopting CTV first.
CTV is an opcode that reads a hash from the stack and compares it to a hash of a specified subset of the spending transaction’s data. Its flexibility promises to enable a diverse set of applications including but not limited to: congestion control, vaults, and rudimentary payment pools.
Apart from opcodes, there have been proposals for sighashes to enable covenants. The two most popular proposals for this purpose are APO and SIGHASH_GROUP. APO is an evolution of the SIGHASH_NOINPUT opcode, which is widely recognized as a prerequisite for implementing eltoo. One of the many improvements made possible with eltoo is the elimination of the penalty mechanism that forces the other party to forfeit funds when broadcasting an outdated channel state. This allows for a more user-friendly and efficient Lightning Network.
Achieving Similar Functionality with Liquid Opcodes
While Liquid doesn’t have the CTV and VAULT opcodes, it does have CSFS and CAT for covenants. By using these more narrowly defined opcodes with the aforementioned introspection opcodes, developers have opened up new financial possibilities with functionality similar to CTV and VAULT to augment the sidechain.
For example, Burak, a seasoned Liquid developer and creator of the layer-2 protocol Ark, has demonstrated an emulation of VAULT using Liquid covenant opcodes in one discussion with James O’Beirne on X.
Similarly, a way to achieve APO functionality was made possible with CSFS. This demo utilized various opcodes that would enable layer-2 protocols like eltoo on Liquid today but suffers from added complexity and a larger transaction size compared to the proposed usage of the APO-type covenant. Moreover, the construction doesn’t apply to Taproot transactions, which would introduce its own form of added complexity.
Liquid Opcodes in Action
Many applications have already taken advantage of covenant opcodes on Liquid. Steven Roose, a covenant proponent who recently defined a specification for the previously ideated OP_TXHASH, has developed an application for fidelity bonds on Liquid. This covenant is placed on funds that would be burned if evidence of a double spend is presented in the witness.
Fuji Money’s Fuji USD (FUSD), an algorithmic stablecoin developed by Vulpem Ventures is another notable example. It relies purely on oracle information to maintain its peg and can be issued in a decentralized manner. It uses a combination of signature verifications and introspection opcodes to accomplish this, and the most important part is it’s all auditable on chain.
Other applications of covenants on Liquid include options contracts and confidential asset-based loans. The Blockstream Research team released a whitepaper last year (see accompanying blog post) about the former, explaining how such an options contract could be constructed using the new set of introspective opcodes.These new opcodes allow users to trustlessly create tokens representing both sides of a covered call option contract and sell the opposite position they wish to take. Contracts made in this fashion also support partial fills, meaning the user who created the contract can sell positions representing a multiple of a user-specified minimum amount of the collateral asset, called the ‘contract size.’
Why Not on Liquid First?
As the Bitcoin ecosystem continues to have a healthy debate regarding covenant opcodes, Liquid offers its own set of tools, catering to similar objectives but with distinct implementations. As the dialogue evolves, it’ll be intriguing to witness the interplay between Bitcoin’s native proposals and Liquid’s already concrete and live covenant-related features and emulation of Bitcoin covenant proposals implemented using Elements Script.
Another new technology on the horizon is Simplicity, a verifiable programming language for the blockchain. The Simplicity language is defined by operations with very narrow semantics that can make expressive programs when composed together. The language is also verifiable, which means methods can be established to mathematically prove assertions made on Simplicity programs.
Simplicity’s expressive nature allows covenant opcodes from Script to be seamlessly ported, ensuring greater reliability and fewer unexpected behaviors. Bitcoin researcher Sanket Kanjalkar has already done this work for CTV. Using s-lang, a more readable Bitcoin-centric programming language that compiles down to Simplicity, he was able to replicate the semantics in a workable proof-of-concept available for anyone to try today.
Bitcoin developers will soon have the opportunity to use s-lang in a real environment thanks to Liquid’s integration of Simplicity, targeted for Q2 2024. s-lang will bring the construction of more complex applications to Liquid, such as vaults and delegation. The draft PR is available for review at the following link.
With a long history of Liquid as an early adopter of ideas that have been later ported to Bitcoin, a suggestion for those looking to showcase the viability of their proposals is to try it live on Liquid to validate ideas first—as multiple covenant-related opcodes have been shown to be emulatable using existing Liquid covenant and introspection opcodes.
So, the next time someone suggests a new covenant, it’s worth asking: why not try it on Liquid first?
This is a guest post by Randy Naar. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.