In the world of Bitcoin, covenants have become a hot topic of discussion, with people eager to explore their potential and the existing covenants on the Liquid Network. This article takes a closer look at the history of covenants on Liquid, comparing them to leading proposals on Bitcoin and examining their various use cases. It also delves into the concept of introspection opcodes and how they simplify covenant construction. Additionally, the article highlights the leading covenant proposals in the Bitcoin community and explores the possibility of achieving similar functionality with Liquid opcodes. With several examples of applications already leveraging covenant opcodes on Liquid, such as fidelity bonds and stablecoin issuance, the article showcases the potential of these tools. Finally, the article suggests that exploring covenant ideas first on Liquid can be a valuable approach, given its history of embracing innovative ideas that later make their way to Bitcoin.
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 others, to Elements. The introduction of these opcodes improved the expressivity of the version of Bitcoin Script available in Elements. A proof-of-concept Möser-Eyal-Sirer vault was developed using CSFS to showcase the new possibilities.
However, implementing CSFS revealed that it made covenants more complex by requiring transaction data to be pushed on the stack during a covenant spend. Developers also found that reconstructing the transaction data on the stack could force them to push irrelevant data, adding unnecessary complexity.
To simplify covenant construction, Liquid introduced more than 30 new opcodes called introspection opcodes during the Taproot upgrade. Introspection opcodes, when used in conjunction with CSFS, enable the inspection of specific parts of the transaction during a spend by placing it on the stack. This eliminates the need to assemble partial transaction data via the witness, making covenant construction more straightforward.
Leading Covenant Proposals
Currently, the Bitcoin community is discussing several potential covenant proposals, including SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT, and OP_CHECKTEMPLATEVERIFY (CTV). Simplicity, a next-generation scripting language, is also being considered as a potential route for implementing covenant functionality in Bitcoin.
One opcode that has generated significant discussion is OP_VAULT, which was designed to address the need for easier ways to secure bitcoin. OP_VAULT allows 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. However, adopting OP_VAULT depends on the adoption of CTV first.
CTV is another opcode that has gained attention due to its flexibility in enabling a diverse set of applications, including congestion control, vaults, and rudimentary payment pools.
There are also proposals for sighashes to enable covenants, with APO and SIGHASH_GROUP being the most popular options. APO is an evolution of the SIGHASH_NOINPUT opcode, and it is seen as a prerequisite for implementing eltoo, which eliminates the penalty mechanism in outdated channel state broadcasting, making the Lightning Network more user-friendly and efficient.
Achieving Similar Functionality with Liquid Opcodes
While Liquid may not have the exact opcodes like CTV and OP_VAULT, it offers its own set of covenant opcodes that provide similar functionality. Liquid has CSFS and CAT opcodes for covenant implementation. Developers have embraced these opcodes along with introspection opcodes to create new financial possibilities on the Liquid sidechain.
For example, a Liquid developer named Burak has demonstrated an emulation of the OP_VAULT using Liquid covenant opcodes. This emulation allows coins to be locked in an address and spent to either a hot wallet after a timelock or immediately to a cold wallet.
Similarly, achieving APO functionality is possible with CSFS on Liquid. Developers have utilized various opcodes to enable layer-2 protocols like eltoo on Liquid, demonstrating similar functionality to APO. However, this approach adds complexity and increases the transaction size compared to the proposed usage of APO. It is worth noting that this construction doesn’t apply to Taproot transactions, which would introduce their own complexities.
Liquid Opcodes in Action
Several applications have already taken advantage of covenant opcodes on Liquid. For example, Steven Roose has developed an application called Doubletake that utilizes a covenant for fidelity bonds. This covenant is placed on funds that would be burned if evidence of a double spend is presented in the witness.
Fuji USD (FUSD), an algorithmic stablecoin developed by Vulpem Ventures, is another notable example. FUSD relies 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, providing auditable on-chain functionality.
Other applications of covenants on Liquid include options contracts and confidential asset-based loans. The Blockstream Research team has released a whitepaper explaining how options contracts can be constructed using introspective opcodes on Liquid. These contracts allow users to create tokens representing both sides of a covered call option contract and sell the opposite position they wish to take.
Why Not on Liquid First?
As the Bitcoin community continues to debate covenant opcodes, Liquid offers its own set of tools with distinct implementations but catering to similar objectives. While Bitcoin’s native proposals are still being refined, Liquid provides concrete and live features related to covenants.
Another upcoming technology is Simplicity, a verifiable programming language for the blockchain. Simplicity allows for expressive programs when operations with narrow semantics are composed together. This language is also verifiable, meaning assertions made on Simplicity programs can be mathematically proven. Sanket Kanjalkar has already replicated the semantics of CTV using s-lang, a Bitcoin-centric programming language that compiles down to Simplicity.
Liquid’s integration of Simplicity, targeted for Q2 2024, will bring the construction of more complex applications to the platform. With Liquid’s track record of adopting ideas later ported to Bitcoin, developers may consider trying their covenant proposals on Liquid first to validate their ideas. Several covenant-related opcodes have already been emulated on Liquid using existing covenant and introspection opcodes.
In conclusion, as the Bitcoin ecosystem explores covenant opcodes, Liquid offers its own set of covenant tools and opcodes. These opcodes provide similar functionality to leading proposals on Bitcoin, allowing developers to create innovative applications and financial products. By trying covenant proposals on Liquid first, developers can validate their ideas and potentially contribute to the evolution of covenant implementations on both Liquid and Bitcoin.