<p>The design of OP_VAULT at the time of writing (April 2023) seems to be <a href="https://github.com/bitcoin/bips/pull/1421" rel="nofollow noreferrer">in flux</a> and isn't yet finalized. Unlike OP_CTV it <strong>is</strong> a <a href="https://bitcoin.stackexchange.com/questions/112242/is-it-possible-to-design-a-recursive-covenant-opcode-that-results-in-a-full-node">recursive covenant</a> opcode and the safety of recursive covenants has been discussed extensively on the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html" rel="nofollow noreferrer">bitcoin-dev</a> mailing list. It shouldn't pose a network risk or a DoS vector to a node verifying OP_VAULT rules (assuming it was activated on mainnet).</p>
<p>The axis that is more relevant to these more limited covenant opcodes is the utility axis rather than the safety axis i.e. when compared to competing alternatives (SIGHASH_ANYPREVOUT, <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html" rel="nofollow noreferrer">OP_TLUV</a>, <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html" rel="nofollow noreferrer">OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY</a> etc) is this the optimal proposal for enabling this kind of functionality? Burak <a href="https://burakkeceli.medium.com/emulating-op-vault-with-elements-opcodes-bdc7d8b0fe71" rel="nofollow noreferrer">posted</a> that OP_VAULT functionality could be emulated by other opcodes currently active on <a href="https://bitcoin.stackexchange.com/questions/109766/elements-liquid-tapscript-opcodes">Elements</a>.</p>
<p>The design space for opcodes is very large and we can't/shouldn't enable every single possible opcode on mainnet. For more explanation on why see this <a href="https://bitcoin.stackexchange.com/questions/106851/what-are-the-downsides-to-enabling-potentially-suboptimal-or-unused-opcodes-in-a">post</a>. Hence the major risk here is probably that no one would end up using it especially if an alternative superior proposal was activated some time later. And having a slightly inferior proposal active onchain may impact whether that alternative superior proposal ends up getting activated at all. Hence there are lots of factors to consider and assuming we don't want to clog up the consensus rules with lots of unused opcodes we should be extremely selective on what we end up activating on mainnet (ignoring the activation chain split risks that are present with every attempted activation).</p>
<p>There are risks and trade-offs when assessing whether to use a particular vault design that could impact the usage of a covenant opcode like OP_VAULT. Some of the risks of using the Revault vault design are discussed <a href="https://github.com/revault/practical-revault/blob/master/introduction.md#risk" rel="nofollow noreferrer">here</a>. However, these aren't systemic risks to the network, just risks to the user of a particular vault design.</p>
<p>edit (September 2023): A tweet thread on OP_VAULT by James O'Beirne is <a href="https://twitter.com/jamesob/status/1639019107432513537?s=20" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 4.0
2023-04-17T14:21:35.643Z
2023-09-11T10:56:58.843Z
2023-09-11T10:56:58.843Z
Michael Folkson
<p>I think the main risk with activating a &quot;feature-specific&quot; opcode, like <code>OP_VAULT</code>, is that users will at some point find out a better way to do &quot;vaults&quot; and the opcode won't support it. By the very nature of softforks, users and developers only <em>really</em> start to use the new feature after it is activated. Thinkers, protocol developers etc might conceptualize use-cases and develop proof-of-concepts, but the truth is that the majority of actual usage comes after activation and with it comes all the creative brain power of people figuring out what they actually want to do.</p>
<p>It's very much possible that when <code>OP_VAULT</code> activates, we realize that there is a sub-optimal aspect to the implementation that now everyone has to stick with. It means that &quot;vaults v2&quot; requires a new version of the opcode and another softfork.</p>
<p>This of course not an answer to &quot;how could the Bitcoin community suffer from the activation of <code>OP_VAULT</code>&quot;, but rather &quot;how could the Bitcoin community suffer from the activation of <code>OP_VAULT</code> instead of more general introspection-enabling mechanisms&quot;.</p>

CC BY-SA 4.0
2023-10-02T01:26:47.143Z
2023-10-02T01:26:47.143Z
Steven Roose
<p>In the past it has been argued that some covenant schemes could be risky. However AFAIK OP_VAULT is a very specific and limited construction.</p>
<p>What are the risks associated with it, if any?</p>

<security><script><opcodes><covenants>
What are the risks of OP_VAULT?
Son Kaos999
# What are the risks of OP_VAULT?

(Asked by: username_0 on 2023-01-14)

In the past it has been argued that some covenant schemes could be risky. However AFAIK OP\_VAULT is a very specific and limited construction.

What are the risks associated with it, if any?

**Tags:** security, script, opcodes, covenants


---

## 2 answers

### Answer by username_1 on 2023-04-17. Score: 2

The design of OP\_VAULT at the time of writing (April 2023) seems to be [in flux](https://github.com/bitcoin/bips/pull/1421) and isn't yet finalized. Unlike OP\_CTV it **is** a [recursive covenant](https://bitcoin.stackexchange.com/questions/112242/is-it-possible-to-design-a-recursive-covenant-opcode-that-results-in-a-full-node) opcode and the safety of recursive covenants has been discussed extensively on the [bitcoin-dev](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html) mailing list. It shouldn't pose a network risk or a DoS vector to a node verifying OP\_VAULT rules (assuming it was activated on mainnet).

The axis that is more relevant to these more limited covenant opcodes is the utility axis rather than the safety axis i.e. when compared to competing alternatives (SIGHASH\_ANYPREVOUT, [OP\_TLUV](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html), [OP\_TXHASH and OP\_CHECKSIGFROMSTACKVERIFY](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html) etc) is this the optimal proposal for enabling this kind of functionality? Burak [posted](https://burakkeceli.medium.com/emulating-op-vault-with-elements-opcodes-bdc7d8b0fe71) that OP\_VAULT functionality could be emulated by other opcodes currently active on [Elements](https://bitcoin.stackexchange.com/questions/109766/elements-liquid-tapscript-opcodes).

The design space for opcodes is very large and we can't/shouldn't enable every single possible opcode on mainnet. For more explanation on why see this [post](https://bitcoin.stackexchange.com/questions/106851/what-are-the-downsides-to-enabling-potentially-suboptimal-or-unused-opcodes-in-a). Hence the major risk here is probably that no one would end up using it especially if an alternative superior proposal was activated some time later. And having a slightly inferior proposal active onchain may impact whether that alternative superior proposal ends up getting activated at all. Hence there are lots of factors to consider and assuming we don't want to clog up the consensus rules with lots of unused opcodes we should be extremely selective on what we end up activating on mainnet (ignoring the activation chain split risks that are present with every attempted activation).

There are risks and trade-offs when assessing whether to use a particular vault design that could impact the usage of a covenant opcode like OP\_VAULT. Some of the risks of using the Revault vault design are discussed [here](https://github.com/revault/practical-revault/blob/master/introduction.md#risk). However, these aren't systemic risks to the network, just risks to the user of a particular vault design.

edit (September 2023): A tweet thread on OP\_VAULT by James O'Beirne is [here](https://twitter.com/jamesob/status/1639019107432513537?s=20).


---

### Answer by username_2 on 2023-10-02. Score: 1

I think the main risk with activating a "feature-specific" opcode, like `OP_VAULT`, is that users will at some point find out a better way to do "vaults" and the opcode won't support it. By the very nature of softforks, users and developers only *really* start to use the new feature after it is activated. Thinkers, protocol developers etc might conceptualize use-cases and develop proof-of-concepts, but the truth is that the majority of actual usage comes after activation and with it comes all the creative brain power of people figuring out what they actually want to do.

It's very much possible that when `OP_VAULT` activates, we realize that there is a sub-optimal aspect to the implementation that now everyone has to stick with. It means that "vaults v2" requires a new version of the opcode and another softfork.

This of course not an answer to "how could the Bitcoin community suffer from the activation of `OP_VAULT`", but rather "how could the Bitcoin community suffer from the activation of `OP_VAULT` instead of more general introspection-enabling mechanisms".


---

