From 91543448cc1845c4776a3d61c49f6b6342d4da0a Mon Sep 17 00:00:00 2001 From: Rigidity Date: Tue, 11 Mar 2025 19:52:00 -0400 Subject: [PATCH 01/12] Add options --- CHIPs/chip-rigidity-options.md | 203 +++++++++++++++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 CHIPs/chip-rigidity-options.md diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md new file mode 100644 index 00000000..df3a735f --- /dev/null +++ b/CHIPs/chip-rigidity-options.md @@ -0,0 +1,203 @@ +| CHIP Number | < Creator must leave this blank. Editor will assign a number.> | +| :------------ | :------------------------------------------------------------------------- | +| Title | Option Contracts | +| Description | Put and call options on the Chia blockchain. | +| Author | [Brandon Haggstrom](https://github.com/Rigidity) | +| Editor | < Creator must leave this blank. Editor will be assigned.> | +| Comments-URI | < Creator must leave this blank. Editor will assign a URI.> | +| Status | < Creator must leave this blank. Editor will assign a status.> | +| Category | Standards Track | +| Sub-Category | Chialisp | +| Created | 2025-03-05 | +| Requires | [0020](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0020.md) | +| Replaces | None | +| Superseded-By | None | + +## Abstract + +American style put and call options for assets (including securities) can be peer-to-peer minted, traded, and exercised on the Chia blockchain, without intermediaries. This makes use of Chia's powerful coin set model and many existing primitives (including offer files) built on top of it. + +## Motivation + +With more assets coming to the Chia blockchain, including securities such as the certificates issued by Permuto, it's desirable to not only trade them, but also create an options market around these assets. By composing existing primitives, it shouldn't be too difficult to integrate this into the existing ecosystem. + +## Backwards Compatibility + +Even though option contract singletons are non-fungible, they don't follow the NFT1 standard. This is for a multitude of reasons: + +1. NFTs typically include metadata that are undesirable for on-chain options, including images, off-chain JSON files, and licenses. If excluded, there could be subtle incompatibilities with existing display services and wallets. +2. Option contracts do not need royalties to be paid when traded. Once the premium is paid, it's fully owned by the buyer and up to them what to do with it. +3. NFTs cannot be melted, so using a custom singleton puzzle allows options to be melted instead of burned when they have been exercised. +4. Options don't need the ability to be assigned to DID profiles. In fact, if NFTs were used for options, changing the DID owner or metadata would affect the puzzle and therefore prevent them from being exercised (due to burning the NFT being a requirement). In some cases, this could permanently and unintentionally brick the option. +5. It would be relatively trivial to create a fake NFT that looks like an option contract, but doesn't in fact have the correct details (or any coin locked up in it at all). While display services and wallets could help differentiate between the two, backwards compatibility here would actually lead to misleading buyers. Therefore, this puzzle intentionally makes it so websites and apps have to opt-in to displaying them. + +## Rationale + +The rationale around the backwards incompatibility with the NFT1 standard is described above. However, there are other aspects that were considered but decided against. + +It would have been possible to hard code the underlying coin spend paths as a list of conditions rather than a p2_1_of_n with a p2_singleton and clawback path inside. Although it's conceptually simpler, the p2_1_of_n allows revealing only the spend path you actually use, which can save on cost. The minter also automatically has full custody to spend the coin however they choose after it expires, rather than needing an intermediate spend to send it to their address first. + +The metadata is stored once in the singleton launcher, so that intermediate transfers of the singleton don't incur additional cost by repeating the curried metadata in each coin spend. However, it's stored on-chain so that display services and wallets don't need to call centralized APIs or access off-chain information to validate the option and construct the offer file for exercising it. + +## Specification + +There are several moving parts to this standard, and it's important to get the implementation right. It combines many existing primitives rather than using only new Chialisp. + +### Option Contract + +The option contract itself is represented as a singleton with a custom inner puzzle (the Chialisp source code for this puzzle is attached). It's an asset that can be owned by a puzzle hash, transferred elsewhere, and traded with offer files. + +When the option singleton is minted, the following metadata structure is included in the `key_value_list` parameter of the singleton launcher solution: + +``` +(expiration_seconds strike_type) +``` + +Where `strike_type` can be one of the following: + +1. XCH `(0 amount)` +2. CAT `(1 asset_id amount hidden_puzzle_hash)` + +The `hidden_puzzle_hash` can be optionally set to nil, and requires the requested CAT be wrapped in the revocation layer if specified. + +Note that these values are proper nil-terminated lists, in order to leave room for extensions to this standard in the future. For example, NFTs could be supported as a new `strike_type`. However, for now this is limited to XCH and CATs. + +### Underlying Coin + +The underlying asset is locked in a coin with a p2_1_of_n puzzle. These puzzle members must be included in the merkle tree: + +1. The exercise p2_singleton puzzle, controlled by the option contract singleton. For the purposes of standardization, the puzzle used by the reference implementation always follows the Meta Inner Puzzle Spec (MIPS), although this isn't strictly required. Specifically, a singleton member with no restrictions and a nonce of 0. Note, the p2_singleton puzzle itself is not wrapped in any conditions, since this is enforced by the option contract with the precommitted delegated puzzle hash. +2. The clawback puzzle, which is the minter's puzzle hash wrapped in augmented_condition to enforce the `ASSERT_SECONDS_ABSOLUTE` timelock. Essentially, the coin can be arbitrarily spent by the minter after it expires (custody automatically changes hands without any actions being taken). + +Memos (including the hint) are optional for the underlying coin, because the coin id is directly curried into the option contract singleton's inner puzzle. + +### Delegated Puzzle + +The delegated puzzle hash used to exercise the underlying coin is precommitted in the option singleton puzzle. It should be reproducible solely from the `strike_type` metadata parameter. + +It's a simple quoted list of these conditions: + +1. `(ASSERT_BEFORE_SECONDS_ABSOLUTE expiration_timestamp)` +2. `(ASSERT_PUZZLE_ANNOUNCEMENT payment_announcement_id)` +3. `(CREATE_COIN SETTLEMENT_PAYMENT_HASH amount)` + +Note that the created coin does not have a memo. This is because it can instead be added to the final coin created when the taker of the offer sends the coin to themselves. + +The announcement id consists of the following, hashed together: + +1. The requested settlement puzzle hash. For CATs, this is optionally wrapped in the revocation layer, and then wrapped in the CAT layer. +2. The notarized payment tree hash. The nonce is the launcher id of the option contract singleton, and the payment is made to the `minter_puzzle_hash` with a memo if it's a CAT. + +### Exercise Spend + +The option contract will be exercised if two conditions are output by the inner puzzle at the same time (in any order): + +1. `(CREATE_COIN () -113)` +2. `(SEND_MESSAGE 23 underlying_delegated_puzzle_hash underlying_coin_id)` + +The `CREATE_COIN` with `-113` amount is the standard singleton melt condition, which means the singleton will not be recreated after exercising it. + +The `SEND_MESSAGE` authorizes the p2_singleton puzzle of the underlying coin to be spent, but it must adhere to the specific delegated puzzle that has been precommitted (according to the section above). + +The underlying coin also needs to be manually spent to unlock the funds to the offer settlement puzzle. If either of the coins aren't spent, the other won't be valid (due to the message). The p2_singleton is one path of the p2_1_of_n puzzle used by the underlying coin, and it can be spent using MIPS. + +The settlement coin must be claimed by the taker of the offer, and its announcement can be asserted by the conditions output by either the singleton inner puzzle or the coin used to pay the requested payment. + +And finally, the requested payment must be made to fulfill the taker's side of the bargain. This allows an atomic swap with an offer file, even though there's a bit more complicated machinery going on under the hood than usual. + +### Clawback Spend + +The clawback spend path is the most straightforward. The sender's spend needs to be wrapped with the `ASSERT_SECONDS_ABSOLUTE` condition, by using the augmented_condition puzzle. + +Other than that, this can be used directly in the p2_1_of_n spend to do whatever the sender wants with the coin after expiration. + +### Option Contract Puzzle + +This is intended to be used as an inner puzzle to singleton_top_layer_v1_1. + +```lisp +(mod ( + MOD_HASH + UNDERLYING_COIN_ID + UNDERLYING_DELEGATED_PUZZLE_HASH + INNER_PUZZLE + inner_solution + ) + + (include curry.clib) + (include utility_macros.clib) + + (defconstant CREATE_COIN 51) + (defconstant SEND_MESSAGE 66) + + (defun-inline wrap_puzzle_hash (MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH inner_puzzle_hash) + (curry_hashes MOD_HASH + (sha256 1 MOD_HASH) + (sha256 1 UNDERLYING_COIN_ID) + (sha256 1 UNDERLYING_DELEGATED_PUZZLE_HASH) + inner_puzzle_hash + ) + ) + + (defun-inline wrap_create_coin (MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (inner_puzzle_hash . rest)) + (c CREATE_COIN (c (wrap_puzzle_hash MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH inner_puzzle_hash) rest)) + ) + + ; Wraps CREATE_COIN conditions in the option contract layer + (defun morph_conditions (MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH conditions melted exercised) + (if conditions + (if (= (f (f conditions)) CREATE_COIN) + (if (= (f (r (r (f conditions)))) -113) + ; Allow melting but make sure it's tracked for later + (c + (f conditions) + (morph_conditions MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (r conditions) 1 exercised) + ) + ; Wrap the created coin in the option contract layer + (c + (wrap_create_coin MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (r (f conditions))) + (morph_conditions MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (r conditions) melted exercised) + ) + ) + (if (and (= (f (f conditions)) SEND_MESSAGE) (all + (= (f (r (f conditions))) 23) ; Puzzle hash => coin id + (= (f (r (r (r (f conditions))))) UNDERLYING_COIN_ID) ; Received by underlying coin id + )) + (assert (= (f (r (r (f conditions)))) UNDERLYING_DELEGATED_PUZZLE_HASH) + ; Make note that the option has been exercised + (c + (f conditions) + (morph_conditions MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (r conditions) melted 1) + ) + ) + (c + (f conditions) + (morph_conditions MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (r conditions) melted exercised) + ) + ) + ) + (assert (= melted exercised) ; If melted, must also be exercised and vice versa + () + ) + ) + ) + + (morph_conditions MOD_HASH UNDERLYING_COIN_ID UNDERLYING_DELEGATED_PUZZLE_HASH (a INNER_PUZZLE inner_solution) () ()) +) +``` + +## Test Cases + +## Reference Implementation + +## Security + +It's important to verify the authenticity of an option contract before displaying it, since although a singleton may adhere to the correct puzzle, the metadata and underlying coin might not line up as expected. This could mislead people into buying something that should be guaranteed but isn't. + +## Additional Assets + +None + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 25687fccc1aefc218d1a97747ffdcd5e1ba51f0e Mon Sep 17 00:00:00 2001 From: Rigidity Date: Tue, 11 Mar 2025 21:36:40 -0400 Subject: [PATCH 02/12] Revocable CATs are their own type --- CHIPs/chip-rigidity-options.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index df3a735f..8f9b1754 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -56,9 +56,8 @@ When the option singleton is minted, the following metadata structure is include Where `strike_type` can be one of the following: 1. XCH `(0 amount)` -2. CAT `(1 asset_id amount hidden_puzzle_hash)` - -The `hidden_puzzle_hash` can be optionally set to nil, and requires the requested CAT be wrapped in the revocation layer if specified. +2. CAT `(1 asset_id amount)` +3. Revocable CAT `(2 asset_id hidden_puzzle_hash amount)` Note that these values are proper nil-terminated lists, in order to leave room for extensions to this standard in the future. For example, NFTs could be supported as a new `strike_type`. However, for now this is limited to XCH and CATs. From ce025e7551eb10a3db7087202a9f15bf1038a944 Mon Sep 17 00:00:00 2001 From: Rigidity Date: Wed, 12 Mar 2025 00:03:44 -0400 Subject: [PATCH 03/12] NFT and more security considerations --- CHIPs/chip-rigidity-options.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index 8f9b1754..f30b87fa 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -58,6 +58,9 @@ Where `strike_type` can be one of the following: 1. XCH `(0 amount)` 2. CAT `(1 asset_id amount)` 3. Revocable CAT `(2 asset_id hidden_puzzle_hash amount)` +4. NFT `(3 launcher_id settlement_puzzle_hash amount)` + +For NFTs, the `settlement_puzzle_hash` is what the _full_ puzzle hash of the NFT would be if its p2_puzzle_hash were `SETTLEMENT_PAYMENT_HASH`. Note that these values are proper nil-terminated lists, in order to leave room for extensions to this standard in the future. For example, NFTs could be supported as a new `strike_type`. However, for now this is limited to XCH and CATs. @@ -193,6 +196,10 @@ This is intended to be used as an inner puzzle to singleton_top_layer_v1_1. It's important to verify the authenticity of an option contract before displaying it, since although a singleton may adhere to the correct puzzle, the metadata and underlying coin might not line up as expected. This could mislead people into buying something that should be guaranteed but isn't. +The amount of the underlying coin or strike amount must be non-zero, due to a restriction in the settlement payments puzzle. Otherwise, the option cannot be exercised. + +Additionally, if an NFT is the strike asset used to exercise the option, the settlement_puzzle_hash must be the same as it was before. If it's not, the option won't be able to be exercised. This means the metadata must be the same as before, and there should be no precommitted owner DID. + ## Additional Assets None From ddc06fbd52caa931e4d0a4193c751c9e050b73f8 Mon Sep 17 00:00:00 2001 From: Rigidity Date: Wed, 12 Mar 2025 00:11:10 -0400 Subject: [PATCH 04/12] Add validations section --- CHIPs/chip-rigidity-options.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index f30b87fa..dea9ad49 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -113,6 +113,25 @@ The clawback spend path is the most straightforward. The sender's spend needs to Other than that, this can be used directly in the p2_1_of_n spend to do whatever the sender wants with the coin after expiration. +### Validations + +Display services and wallets must extensively verify the authenticity of the option contract. Just having a singleton with the correct inner puzzle doesn't necessarily mean it's a valid option. + +Here is a list of things that will need to be fetched: + +1. The singleton and option contract puzzle arguments +2. The launcher coin's `key_value_lists` solution parameter +3. The underlying coin (and possibly its parent or other related context) that matches the coin id in the option contract puzzle + +And these are the validations that must be performed, in no particular order: + +- The underlying coin exists, is unspent, and matches the claimed coin id +- The metadata is valid and the expiration timestamp hasn't been reached yet +- For revocable CAT strike assets, the correct hidden_puzzle_hash is used +- For NFT strike assets, the puzzle matches the settlement_puzzle_hash it's expecting +- The underlying coin's puzzle hash matches the expected p2_1_of_n puzzle hash +- The precommitted delegated puzzle hash matches the expected one + ### Option Contract Puzzle This is intended to be used as an inner puzzle to singleton_top_layer_v1_1. From ebef5a9fac8ad42c353582a8d5dd51c85966556a Mon Sep 17 00:00:00 2001 From: Rigidity Date: Wed, 12 Mar 2025 00:17:37 -0400 Subject: [PATCH 05/12] Add explanation of options --- CHIPs/chip-rigidity-options.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index dea9ad49..4ec158ea 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -21,6 +21,17 @@ American style put and call options for assets (including securities) can be pee With more assets coming to the Chia blockchain, including securities such as the certificates issued by Permuto, it's desirable to not only trade them, but also create an options market around these assets. By composing existing primitives, it shouldn't be too difficult to integrate this into the existing ecosystem. +Here's an example flow for how option contracts can be used: + +1. Alice wants to make an option contract with an underlying 10,000 SBX, a strike price of 2 XCH, and an expiration of 3 months later. +2. Alice makes an offer file wherein she mints the option contract, locks up the 10,000 SBX inside of it, and requests a 0.5 XCH premium. +3. Bob buys the option for 0.5 XCH and hangs onto it for 2 months. +4. Bob decides to exercise the option, so his wallet constructs an offer file to do so. +5. He takes the offer, by melting the option contract, unlocking the underlying 10,000 SBX, and paying the strike price of 2 XCH. +6. Alice gets 2 XCH and Bob gets 10,000 SBX. + +If Bob never wanted to exercise the option, he could have let it expire. Then, Alice owns the 10,000 SBX again and Bob only had to pay 0.5 XCH. + ## Backwards Compatibility Even though option contract singletons are non-fungible, they don't follow the NFT1 standard. This is for a multitude of reasons: From 2efae3da0d971a7cc99dc91da36fd7d98e9dd113 Mon Sep 17 00:00:00 2001 From: Rigidity Date: Wed, 12 Mar 2025 00:23:48 -0400 Subject: [PATCH 06/12] Add permalinks to the implementation --- CHIPs/chip-rigidity-options.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index 4ec158ea..eafdfe8e 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -220,8 +220,19 @@ This is intended to be used as an inner puzzle to singleton_top_layer_v1_1. ## Test Cases +In the [wallet sdk implementation](https://github.com/xch-dev/chia-wallet-sdk/blob/4d7d666d2e7e9f4713b5b76af11ff073d7eda152/crates/chia-sdk-driver/src/primitives/option/option_contract.rs), there are tests for all of the following: + +1. Minting +2. Transferring +3. Exercising (including ensuring it fails after expiration and without paying) +4. Clawback (including ensuring it fails before expiration) +5. XCH, CATs, Revocable CATs, and NFTs +6. Ensuring melting fails without exercising and vice versa + ## Reference Implementation +There is a comprehensive [option contract implementation](https://github.com/xch-dev/chia-wallet-sdk/tree/4d7d666d2e7e9f4713b5b76af11ff073d7eda152/crates/chia-sdk-driver/src/primitives/option) in the chia-wallet-sdk repo. + ## Security It's important to verify the authenticity of an option contract before displaying it, since although a singleton may adhere to the correct puzzle, the metadata and underlying coin might not line up as expected. This could mislead people into buying something that should be guaranteed but isn't. From 255a787073329453574254065afafecd288a7519 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 12 Mar 2025 12:39:48 +0800 Subject: [PATCH 07/12] Open CHIP-45 as a Draft --- CHIPs/chip-rigidity-options.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index eafdfe8e..a200bbd9 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -1,11 +1,11 @@ -| CHIP Number | < Creator must leave this blank. Editor will assign a number.> | +| CHIP Number | 0045 | | :------------ | :------------------------------------------------------------------------- | | Title | Option Contracts | | Description | Put and call options on the Chia blockchain. | | Author | [Brandon Haggstrom](https://github.com/Rigidity) | -| Editor | < Creator must leave this blank. Editor will be assigned.> | -| Comments-URI | < Creator must leave this blank. Editor will assign a URI.> | -| Status | < Creator must leave this blank. Editor will assign a status.> | +| Editor | [Dan Perry](https://github.com/danieljperry) | +| Comments-URI | [CHIPs repo, PR #125](https://github.com/Chia-Network/chips/pull/125) | +| Status | Draft | | Category | Standards Track | | Sub-Category | Chialisp | | Created | 2025-03-05 | From 669680119dfdc3f07a1a3e821d54ce81cc78856b Mon Sep 17 00:00:00 2001 From: danieljperry Date: Sun, 23 Mar 2025 07:02:40 +0800 Subject: [PATCH 08/12] Update comments link --- CHIPs/chip-rigidity-options.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-rigidity-options.md index a200bbd9..a5dd0dd0 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-rigidity-options.md @@ -4,7 +4,7 @@ | Description | Put and call options on the Chia blockchain. | | Author | [Brandon Haggstrom](https://github.com/Rigidity) | | Editor | [Dan Perry](https://github.com/danieljperry) | -| Comments-URI | [CHIPs repo, PR #125](https://github.com/Chia-Network/chips/pull/125) | +| Comments-URI | [CHIPs repo, PR #152](https://github.com/Chia-Network/chips/pull/152) | | Status | Draft | | Category | Standards Track | | Sub-Category | Chialisp | From d0cb75f00c77d19061d1b958e265c06030214410 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 20 Aug 2025 09:02:16 +0800 Subject: [PATCH 09/12] Move CHIP-45 to Review status --- CHIPs/{chip-rigidity-options.md => chip-0045.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename CHIPs/{chip-rigidity-options.md => chip-0045.md} (99%) diff --git a/CHIPs/chip-rigidity-options.md b/CHIPs/chip-0045.md similarity index 99% rename from CHIPs/chip-rigidity-options.md rename to CHIPs/chip-0045.md index a5dd0dd0..5911daa0 100644 --- a/CHIPs/chip-rigidity-options.md +++ b/CHIPs/chip-0045.md @@ -5,9 +5,9 @@ | Author | [Brandon Haggstrom](https://github.com/Rigidity) | | Editor | [Dan Perry](https://github.com/danieljperry) | | Comments-URI | [CHIPs repo, PR #152](https://github.com/Chia-Network/chips/pull/152) | -| Status | Draft | +| Status | Review | | Category | Standards Track | -| Sub-Category | Chialisp | +| Sub-Category | Primitive | | Created | 2025-03-05 | | Requires | [0020](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0020.md) | | Replaces | None | From 9772e22cacd7355dd325f95397664cfda2a04614 Mon Sep 17 00:00:00 2001 From: Rigidity Date: Thu, 25 Sep 2025 21:39:59 -0400 Subject: [PATCH 10/12] Clarify that NFTs as underlying need royalties, and NFTs should not be the strike price --- CHIPs/chip-0045.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/CHIPs/chip-0045.md b/CHIPs/chip-0045.md index 5911daa0..47bc8716 100644 --- a/CHIPs/chip-0045.md +++ b/CHIPs/chip-0045.md @@ -69,11 +69,8 @@ Where `strike_type` can be one of the following: 1. XCH `(0 amount)` 2. CAT `(1 asset_id amount)` 3. Revocable CAT `(2 asset_id hidden_puzzle_hash amount)` -4. NFT `(3 launcher_id settlement_puzzle_hash amount)` -For NFTs, the `settlement_puzzle_hash` is what the _full_ puzzle hash of the NFT would be if its p2_puzzle_hash were `SETTLEMENT_PAYMENT_HASH`. - -Note that these values are proper nil-terminated lists, in order to leave room for extensions to this standard in the future. For example, NFTs could be supported as a new `strike_type`. However, for now this is limited to XCH and CATs. +Note that these values are proper nil-terminated lists, in order to leave room for extensions to this standard in the future. ### Underlying Coin @@ -101,6 +98,8 @@ The announcement id consists of the following, hashed together: 1. The requested settlement puzzle hash. For CATs, this is optionally wrapped in the revocation layer, and then wrapped in the CAT layer. 2. The notarized payment tree hash. The nonce is the launcher id of the option contract singleton, and the payment is made to the `minter_puzzle_hash` with a memo if it's a CAT. +If the underlying asset is an NFT, add the NFT transfer condition to reveal the strike price as the trade prices list. NFTs are not supported as the strike price in this version of the standard. + ### Exercise Spend The option contract will be exercised if two conditions are output by the inner puzzle at the same time (in any order): @@ -139,7 +138,6 @@ And these are the validations that must be performed, in no particular order: - The underlying coin exists, is unspent, and matches the claimed coin id - The metadata is valid and the expiration timestamp hasn't been reached yet - For revocable CAT strike assets, the correct hidden_puzzle_hash is used -- For NFT strike assets, the puzzle matches the settlement_puzzle_hash it's expecting - The underlying coin's puzzle hash matches the expected p2_1_of_n puzzle hash - The precommitted delegated puzzle hash matches the expected one @@ -239,8 +237,6 @@ It's important to verify the authenticity of an option contract before displayin The amount of the underlying coin or strike amount must be non-zero, due to a restriction in the settlement payments puzzle. Otherwise, the option cannot be exercised. -Additionally, if an NFT is the strike asset used to exercise the option, the settlement_puzzle_hash must be the same as it was before. If it's not, the option won't be able to be exercised. This means the metadata must be the same as before, and there should be no precommitted owner DID. - ## Additional Assets None From 63cfe4507210d469580a73f6acc8e959e7acc76e Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 1 Oct 2025 12:50:22 +0800 Subject: [PATCH 11/12] Move CHIP-45 to Last Call --- CHIPs/chip-0045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0045.md b/CHIPs/chip-0045.md index 47bc8716..9e2f6cad 100644 --- a/CHIPs/chip-0045.md +++ b/CHIPs/chip-0045.md @@ -5,7 +5,7 @@ | Author | [Brandon Haggstrom](https://github.com/Rigidity) | | Editor | [Dan Perry](https://github.com/danieljperry) | | Comments-URI | [CHIPs repo, PR #152](https://github.com/Chia-Network/chips/pull/152) | -| Status | Review | +| Status | Last Call | | Category | Standards Track | | Sub-Category | Primitive | | Created | 2025-03-05 | From c6b91d351f495367d4514c896bc4299825d99c28 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 15 Oct 2025 15:30:50 +0800 Subject: [PATCH 12/12] Move CHIP-45 to Final status --- CHIPs/chip-0045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0045.md b/CHIPs/chip-0045.md index 9e2f6cad..170171a5 100644 --- a/CHIPs/chip-0045.md +++ b/CHIPs/chip-0045.md @@ -5,7 +5,7 @@ | Author | [Brandon Haggstrom](https://github.com/Rigidity) | | Editor | [Dan Perry](https://github.com/danieljperry) | | Comments-URI | [CHIPs repo, PR #152](https://github.com/Chia-Network/chips/pull/152) | -| Status | Last Call | +| Status | Final | | Category | Standards Track | | Sub-Category | Primitive | | Created | 2025-03-05 |