# OP\_CHECKCONTRACTVERIFY and its amount semantic

**URL:** <https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527>\
**Category:** Protocol Design\
**Tags:** softfork, bitcoin-core\
**Created:** [March 17, 2025, 5:57am UTC](https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527 "2025-03-17T05:57:39Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![AntoineP](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/antoinep/32/483_2.png) [@AntoineP](https://delvingbitcoin.org/u/AntoineP)\
**Post date:** [June 13, 2025, 1:12pm UTC](https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527/13 "2025-06-13T13:12:08Z")

</div>

Nice, good to see more practical exploration on this.

> [@halseth](#):
>
> With this approach you would reduce the CCV opcode to just do “annex assertion” not really caring what the annex means. I believe that would make it easier to add more meaning to the annex at a later point (via a soft fork) and immediately have it available for assertion by CCV without touching the script engine.

I think my preference would be to separate concerns entirely and have an opcode that does the assertion. `OP_CHECKAMOUNT`? Then CCV can take care of the scripts.

---

_[View the full topic](https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527)._