From 104b6c484ace299804360ffe5cc0ac74f7e206fa Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Wed, 15 Jun 2022 00:12:25 -0500 Subject: [PATCH 01/24] yuuuuuuuup --- CHIPs/chip-joshpainter-auctions.md | 86 ++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 CHIPs/chip-joshpainter-auctions.md diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md new file mode 100644 index 00000000..23d20873 --- /dev/null +++ b/CHIPs/chip-joshpainter-auctions.md @@ -0,0 +1,86 @@ +CHIP Number | < Creator must leave this blank. Editor will assign a number.> +:-------------|:---- +Title | Auctions +Description | A method for holding decentralized, zero-risk auctions for digital assets on the Chia blockchain +Author | [Josh Painter](https://github.com/joshpainter) ([@endertown](https://twitter.com/endertown) on Keybase and Twitter) +Comments-URI | < Creator must leave this blank. Editor will assign a URI.> +Status | < Creator must leave this blank. Editor will assign a status.> +Category | Informational +Sub-Category | Guideline +Created | 2022-05-22 +Requires | none +Replaces | none +Superseded-By | none + +## Abstract +Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held annual auctions for attractive maidens who had reached marrying age. Ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. Romans also used auctions to liquidate assets and pay off debt. Surprisingly, the entire Roman Empire was put up for auction on March 28th, 193 AD by the Praetorian Guard and purchased by Didius Julianus! Although it couldn't be built in a day, apparently Rome could at least be *purchased* within that timeframe. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. + +However, even with all this history, auctions still have unsolved risks for the buyer, the seller, and especially the auction house holding the auction itself. The Chia blockchain, along with the coinset model and Chialisp, brings about new and unique opportunities to improve on this millenia-old practice and eliminate risk for all parties. This document will explore the counterparty risks and issues with modern-day auction. It will then propose high-level solutions to these problems using puzzles created in Chialisp and executed directly on the Chia blockchain. Finally, it will recommend detailed specifications that can be used to build these Chialisp puzzles to enable these solutions. + +## Motivation +Modern-day auctions continue to be a valuable tool for finding market value of new assets, quickly liquidating old assets, and everything in between. However, multiple risks still exist for the bidders, the sellers, and especially the auction house responsible for promoting and organizing the auction itself. + + * Seller risks + * High bidder may not complete transaction after auction ends. This forces seller to find another buyer who will usually not be willing to pay the same price. The best case is probably offering the auctioned item to the second-highest bidder at their second highest bid, but usually the second-highest bidder will recognize their negotiating power and drive the price even lower. Current solutions to this problem involve legal contracts and bidder deposits, both of which can add significant friction to the auction event itself. + * High bidders might hold back bids until the last minute, hoping to “snipe” other users. Ideally users would be incentivized to make lots of small bids over the entire auction event instead of a few large bids in a short time near the end. This promotes more engagement with the auction itself and might result in a higher price for the seller. + * The auction house might not properly market the auction resulting in low bidder attendance and a lower winning bid. Ideally the auction would at least be publicly discoverable via simple searching tools. The auction house might add additional marketing value above this baseline discoverability such as featured auctions, push notifications to interested buyers, etc. + * Bidder risks + * Seller may not complete transaction after auction ends. Perhaps the winning bid was lower than they expected and they now wish to rescind their decision to auction the item. Again, these risks can be mitigated with legal contracts binding the seller to the auction sale, but again these add friction to the process and still do not deter sellers if the cost of litigation is less than the perceived loss of value. + * High-bidders might be bidding against "dummy bids." In this context, a dummy bid is one that the seller (or someone working on behalf of the seller) creates in order to bid against the current high bidder to drive the price up. + * High-bidders might be “sniped.” In this context, being sniped means that another bidder bids at the last possible time before an auction ends and the current high bidder does not have enough time to respond. + * Auction House risks + * The auction house itself must worry about all risks above simultaneously to protect their reputation while also allocating and spending funds up front to market and operate the auction on behalf of the seller. If the buyer or seller ties up the finalization of the transaction, the auction house must usually wait for payment until the terms are finally settled. In some cases, and especially concerning items of very high value such as large properties or blue-chip art, the winning of the auction itself can sometimes simply be considered the opening offer of a long and strenuous transfer-of-ownership between two legal teams. + +By presenting solutions for all of these risks using the Chia blockchain and Chialisp, it is hoped that Chia's overall ecosystem will benefit from the inflow of digital assets as well as the transactions and fees used to fund bids. Auctions are also a natural sales method for NFTs and CATs and a great way to find the market value of these new digital assets. Furthermore, it is hoped that Auctions will be a natural fit for carbon credit asset trading, enabling advancement of Chia's commitment to improve and support the Climate Warehouse for World Bank. + +Although there are many auction variations, this proposal will focus on the use-cases of the two most popular methods of auction in use today: English and Dutch. However, the specification will be designed in such a way that almost any kind of auction can be defined, limited only by the power of Chialisp and the auction author's imagination. + +* English Auction + + This is by far the most popular auction type in use today and is also known as an "ascending price auction." It is well-suited for unique or single assets, including NFTs. It begins with the minimum or opening bid, and each successive bid must be greater than or equal to the current bid increment. The auction ends when there are no further high bids. At that point, the high-bidder is declared the winner of the item for sale. + +* Dutch Auction + + This type of auction is also known as a "descending price auction" and it is well-suited for commmodities or lots of the same asset, including CATs. It begins with a high asking price and is successively lowered by the bid increment until a bidder is willing to pay it. The bidder may request any quantity of lots of the item at that bid price. If there are remaining lots of the asset left after the high bidder declares their lot quantity selection, the auction continues until another bidder is willing to pay the descending bid price. That second-highest bidder is also allowed to choose the quantity of lots that they desire, and the auction will continue on until the quantity of lots of the asset is exhausted or the minimum bid amount is met and no more bids are received. + +## Conceptual Design +CONCEPTUALIZING... + +## Specification +SPECULATING... + +## Test Cases +TESTING... + +## Reference Implementation +IMPLEMENTING... + +## Security +SECURING... + +## Terminology +This section describes common auction terminology for which the reader might not be familiar. Even more detailed information, including terminology, history and descriptions of different auction types can be found at https://en.wikipedia.org/wiki/Auction. The terms below are a subset of those found at the preceding link. + + * Auction house – the company operating the auction (i.e., establishing the date and time of the auction, the auction rules, determining which items are to be included in the auction, registering bidders, taking payments, and delivering the goods to the winning bidders). + * Buyer's premium – a fee paid by the buyer to the auction house; it is typically calculated as a percentage of the winning bid and added to it. Depending on the jurisdiction the buyer's premium, in addition to the sales price, may be subject to VAT or sales tax. + * Commission – a fee paid by a consignor/seller to the auction house; it is typically calculated as a percentage of the winning bid and deducted from the gross proceeds due to the consignor/seller. + * Consignee and consignor – as pertaining to auctions, the consignor (also called the seller, and in some contexts the vendor) is the person owning the item to be auctioned or the owner's representative, while the consignee is the auction house. The consignor maintains title until such time that an item is purchased by a bidder and the bidder pays the auction house. + * Dummy bid (a/k/a "ghost bid") – a false bid, made by someone in collusion with the seller or auctioneer, designed to create a sense of increased interest in the item (and, thus, increased bids). + * Dynamic closing – a mechanism used to prevent auction sniping, by which the closing time is extended for a small period to allow other bidders to increase their bids. + * Earnest money deposit (a/k/a "caution money deposit" or "registration deposit") – a payment that must be made by prospective bidders ahead of time in order to participate in an auction. + * Escrow – an arrangement in which the winning bidder pays the amount of his/her bid to a third party, who in turn releases the funds to the seller under agreed-upon terms. + * Hammer price – the nominal price at which a lot is sold; the winner is responsible for paying any additional fees and taxes on top of this amount + * Increment – a minimum amount by which a new bid must exceed the previous bid. An auctioneer may decrease the increment when it appears that bidding on an item may stop, so as to get a higher hammer price. + * Minimum bid – The smallest opening bid that will be accepted + * Opening bid – the first bid placed on a particular lot. The opening bid must be at least the minimum bid, but may be higher (e.g., a bidder may shout out a considerably larger bid than minimum, to discourage other bidders from bidding). + * Protecting a market – when a dealer places a bid on behalf of an artist he or she represents or otherwise has a financial interest in ensuring a high price. Artists represented by major galleries typically expect this kind of protection from their dealers. + * Reserve price – A minimum acceptable price established by the seller prior to the auction, which may or may not be disclosed to the bidders. + * Sealed bid – a submitted bid whose value is unknown to competitors. + * Sniping – the act of placing a bid just before the end of a timed auction, thus giving other bidders no time to enter new bids. + * Soft Close – When someone places a bid in the last set amount of minutes and the auction automatically extends a set period of time. Soft close prevents sniping. + +## Additional Assets +NONE YET... + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From d4d4b2c5d37c74e0531aec7d772640c59a85cc14 Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Wed, 15 Jun 2022 08:12:22 -0500 Subject: [PATCH 02/24] Add conceptual design and specs first drafts --- CHIPs/chip-joshpainter-auctions.md | 40 ++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2 deletions(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index 23d20873..a71070d8 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -44,10 +44,46 @@ Although there are many auction variations, this proposal will focus on the use- This type of auction is also known as a "descending price auction" and it is well-suited for commmodities or lots of the same asset, including CATs. It begins with a high asking price and is successively lowered by the bid increment until a bidder is willing to pay it. The bidder may request any quantity of lots of the item at that bid price. If there are remaining lots of the asset left after the high bidder declares their lot quantity selection, the auction continues until another bidder is willing to pay the descending bid price. That second-highest bidder is also allowed to choose the quantity of lots that they desire, and the auction will continue on until the quantity of lots of the asset is exhausted or the minimum bid amount is met and no more bids are received. ## Conceptual Design -CONCEPTUALIZING... +An auction on the Chia blockchain will be represented by a singleton that wraps an asset, represented by an inner puzzle. A single-lot auction wraps an asset that represents a single unique item, such as an NFT. A multi-lot auction wraps an asset that represents multiple amounts of the same item, such as a CAT. + +The auction singleton puzzle will include several parameters that allow customization of the auction event itself. Bidders must follow all rules and parameters set by the auctioneer. + +The seller may not be the same entity as the auctioneer. This differentiation allows commissions and/or buyer's premiums to be paid to the auction house to cover promotion, marketing and any other expenses incurred for the real-world execution of the auction. Of course, the seller may also hold the auction on their own behalf. + +A normal real-world auction does not settle until after it has closed, which introduces all of the counterparty risks mentioned above. But by using a unique and novel auction protocol, we can completely "settle" each high bid as it happens in real-time. For *every successful high bid* the asset immediately trades ownership and all bid payments, commissions and fees are sent and confirmed at the same time. This means that an auction running on Chia blockchain does not have *any* of the counter-party risks mentioned above. Because the high bid itself actually contains the payment transactions, it is not necessary to trust that either party will follow through with the agreed-upon sale after the auction has concluded. When a high-bidder successfully makes a high bid, the seller has been paid and the high-bidder now officially owns the asset. The only reason they will not hold the asset at the end of the auction is if another high-bidder successfully "steals" it from them by bidding higher. Of course, the original high-bidder then can "steal" it back, and so on. But if no other bidding action happens after a successful high bid, the auction will close and the high-bidder can then claim the wrapped asset. + +This concept is easy to understand for the first successful high bid. The high bidder actually sends their high bid amount to the seller as a normal transaction. The high bidder may also be required to send an additional buyer's premium fee and/or commission fees to the auctioneer, depending on the settings chosen when the auction singleton is minted. + +However, the second and subsequent successful high bids work quite differently. The new high bidder will first reimburse the current high bidder for their current high bid and commission fees via a normal transaction. The current high bidder is now "whole" and loses the ownership of the asset contained within the auction singleton. Ownership is now transferred to the new high bidder. The difference between the new high bid and the current high bid is sent to the seller, along with any required buyer's premium fees and/or commission fees. The seller has now received the initial high bid amount (from the first high bidder) plus the difference between the initial high bid and the new high bidn (from the second high bidder). This process continues until the auction has concluded. + +It should be understood that all of this happens "behind the scenes" from the user's perspective. The user's experience will be very familiar to all who have used any existing auction software. All of this complexity should be accessible via transaction logs of course, but most users will just make high bids on auctions as they always have. Perhaps the only new user education that needs to happen is to make sure that users understand the true immediacy and finality of high bids. Auction houses will be particularly excited with this technology as they will no longer be caught in the middle of buyer and seller disagreements that can arise during the time that the auction has concluded but has not yet settled. All auctions are now actually settled *before* they are concluded! ## Specification -SPECULATING... +* Singleton launcher puzzle Parameters + * ASSET_PUZZLE - can be any inner-puzzle coin such as NFTs, CATs, etc. + * ORIGINAL_OWNER_PH - the original owner's puzzle hash to which the high bid payments should be sent. + * STARTING_BID_AMOUNT - the starting minimum bid amount, in mojos. + * CALC_MIN_LOT_AMOUNT - the Lisp program that calculates the minimum amount per lot. For a single-item auction, this value will be the same as TOTAL_ASSET_AMOUNT. + * TOTAL_ASSET_AMOUNT - The total amount of the asset, in mojos. + * CALC_MIN_BID_AMOUNT - the Lisp program that calculates the minimum bid amount required to make a new high bid. This allows smaller increments for lower amounts, larger increments for larger amounts, or any other custom logic. The program should output a minimum bid amount given the current_high_bid. + * CALC_HAMMER_TIME - the Lisp program that returns either the datetime or the blockheight after which the auction is considered closed. The could be either a static value (pre-committed datetime or blockheight) or a dynamic value (automatically extend until no more bids received). + * CALC_BUYERS_PREMIUM - the Lisp program that returns conditions for the Buyer's Premium, if applicable. + * CALC_COMMISSION - the Lisp program that returns conditions for the Commission, if applicable. + * PAY_HIGH_BID - the Lisp program that returns conditions for the High Bid payment. + * If this is the first bid + * Send new_high_bid amount to ORIGINAL_OWNER_PH. At this point, the original owner has been paid and the new owner officially owns the asset with the caveat that the asset may be "stolen" by another high bidder before the auction has ended. + * Else + * Send current_high_bid amount to current_owner_ph. This repays the last high bidder for their bid. The last high bidder no longer officially owns this asset, but they have been reimbursed for their previous bid by the new high bidder. The new high bidder now officially owns the asset. + * Send difference between new_high_bid and current_high_bid to ORIGINAL_OWNER_PH. This adds to the original owner's other high bid payments so total payments received equals current high bid at all times. + * Include conditions returned from CALC_BUYERS_PREMIUM, if any. This guarantees that the Buyer's Premium is paid for every bid. + * Include conditions returned from CALC_COMMISSION, if any. This guarantees that the Commission is paid for every bid. + * CLAIM_ASSET - the Lisp program that returns conditions needed to claim the asset after the auction has ended. This program is also responsible for melting this Auction singleton once the wrapped assets are claimed. + +* Singleton puzzle Parameters + * current_high_bid - the amount of the current high bid, in mojos. + * current_owner_ph - the puzzlehash to be used when assigning this asset to the Auction Winner when the auction has completed. + * new_high_bid - the amount of this newly submitted high bid, in mojos. + * new_owner_ph - the puzzle hash of this new high bidder. ## Test Cases TESTING... From 1b1c23bfca7a377a9b1f30afc704c673024ad660 Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Wed, 15 Jun 2022 09:56:14 -0500 Subject: [PATCH 03/24] Added community feedback from @Engarneering --- CHIPs/chip-joshpainter-auctions.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index a71070d8..13e603f2 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -13,7 +13,7 @@ Replaces | none Superseded-By | none ## Abstract -Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held annual auctions for attractive maidens who had reached marrying age. Ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. Romans also used auctions to liquidate assets and pay off debt. Surprisingly, the entire Roman Empire was put up for auction on March 28th, 193 AD by the Praetorian Guard and purchased by Didius Julianus! Although it couldn't be built in a day, apparently Rome could at least be *purchased* within that timeframe. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. +Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held annual auctions for attractive maidens who had reached marrying age*. Ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. Romans also used auctions to liquidate assets and pay off debt. Surprisingly, the entire Roman Empire was put up for auction on March 28th, 193 AD by the Praetorian Guard and purchased by Didius Julianus! Although it couldn't be built in a day, apparently Rome could at least be *purchased* within that timeframe. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. However, even with all this history, auctions still have unsolved risks for the buyer, the seller, and especially the auction house holding the auction itself. The Chia blockchain, along with the coinset model and Chialisp, brings about new and unique opportunities to improve on this millenia-old practice and eliminate risk for all parties. This document will explore the counterparty risks and issues with modern-day auction. It will then propose high-level solutions to these problems using puzzles created in Chialisp and executed directly on the Chia blockchain. Finally, it will recommend detailed specifications that can be used to build these Chialisp puzzles to enable these solutions. @@ -94,6 +94,9 @@ IMPLEMENTING... ## Security SECURING... +## Community Feedback +6/15/2022: Twitter user @Engarneering suggested removing the historical fact about Babylonian auctions from the Abstract because "I mean, really??" This has been taken under advisement and in the meantime, a footnote has been added to the offending sentence. + ## Terminology This section describes common auction terminology for which the reader might not be familiar. Even more detailed information, including terminology, history and descriptions of different auction types can be found at https://en.wikipedia.org/wiki/Auction. The terms below are a subset of those found at the preceding link. @@ -119,4 +122,7 @@ This section describes common auction terminology for which the reader might not NONE YET... ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## Footnotes +* Relaying historical fact of first recorded auction does not mean author endorses such auctions. \ No newline at end of file From 7c0875a43c0b628f2eb35cede22fc3797eb8148b Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Fri, 17 Jun 2022 01:10:18 -0500 Subject: [PATCH 04/24] Community feedback and credit updates --- CHIPs/chip-joshpainter-auctions.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index 13e603f2..df7cac26 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -13,7 +13,7 @@ Replaces | none Superseded-By | none ## Abstract -Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held annual auctions for attractive maidens who had reached marrying age*. Ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. Romans also used auctions to liquidate assets and pay off debt. Surprisingly, the entire Roman Empire was put up for auction on March 28th, 193 AD by the Praetorian Guard and purchased by Didius Julianus! Although it couldn't be built in a day, apparently Rome could at least be *purchased* within that timeframe. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. +Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held auctions. Later, ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. However, even with all this history, auctions still have unsolved risks for the buyer, the seller, and especially the auction house holding the auction itself. The Chia blockchain, along with the coinset model and Chialisp, brings about new and unique opportunities to improve on this millenia-old practice and eliminate risk for all parties. This document will explore the counterparty risks and issues with modern-day auction. It will then propose high-level solutions to these problems using puzzles created in Chialisp and executed directly on the Chia blockchain. Finally, it will recommend detailed specifications that can be used to build these Chialisp puzzles to enable these solutions. @@ -54,7 +54,7 @@ A normal real-world auction does not settle until after it has closed, which int This concept is easy to understand for the first successful high bid. The high bidder actually sends their high bid amount to the seller as a normal transaction. The high bidder may also be required to send an additional buyer's premium fee and/or commission fees to the auctioneer, depending on the settings chosen when the auction singleton is minted. -However, the second and subsequent successful high bids work quite differently. The new high bidder will first reimburse the current high bidder for their current high bid and commission fees via a normal transaction. The current high bidder is now "whole" and loses the ownership of the asset contained within the auction singleton. Ownership is now transferred to the new high bidder. The difference between the new high bid and the current high bid is sent to the seller, along with any required buyer's premium fees and/or commission fees. The seller has now received the initial high bid amount (from the first high bidder) plus the difference between the initial high bid and the new high bidn (from the second high bidder). This process continues until the auction has concluded. +However, the second and subsequent successful high bids work quite differently. The new high bidder will first reimburse the current high bidder for their current high bid and commission fees via a normal transaction. The current high bidder is now "whole" and loses the ownership of the asset contained within the auction singleton. Ownership is now transferred to the new high bidder. The difference between the new high bid and the current high bid is sent to the seller, along with any required buyer's premium fees and/or commission fees. The seller has now received the initial high bid amount (from the first high bidder) plus the difference between the initial high bid and the new high bid (from the second high bidder). This process continues until the auction has concluded. It should be understood that all of this happens "behind the scenes" from the user's perspective. The user's experience will be very familiar to all who have used any existing auction software. All of this complexity should be accessible via transaction logs of course, but most users will just make high bids on auctions as they always have. Perhaps the only new user education that needs to happen is to make sure that users understand the true immediacy and finality of high bids. Auction houses will be particularly excited with this technology as they will no longer be caught in the middle of buyer and seller disagreements that can arise during the time that the auction has concluded but has not yet settled. All auctions are now actually settled *before* they are concluded! @@ -96,6 +96,17 @@ SECURING... ## Community Feedback 6/15/2022: Twitter user @Engarneering suggested removing the historical fact about Babylonian auctions from the Abstract because "I mean, really??" This has been taken under advisement and in the meantime, a footnote has been added to the offending sentence. +6/15/2022: Twitter user @_nezzee suggested shortening the intro and notes that most intros just start with a simple definition. + +## Updates +6/15/2022: + * Added Community Feedback section + * Added feedback from @Engarneering and @nezzee +6/17/2022: + * Added this Updates section + * Shorted intro to take into account community feedback. Thank you @Engarneering and @_nezzee! + * Added Credit section + * Added credit paragraph for @Omakasea_ - thank you! ## Terminology This section describes common auction terminology for which the reader might not be familiar. Even more detailed information, including terminology, history and descriptions of different auction types can be found at https://en.wikipedia.org/wiki/Auction. The terms below are a subset of those found at the preceding link. @@ -121,6 +132,10 @@ This section describes common auction terminology for which the reader might not ## Additional Assets NONE YET... +## Credit + * Around the end of April 2022, @Omakasea_ and team released the "onchain unicorn" on the Ethereum network. One of the features was the ability for it to be "stolen" from the current owner by a new buyer. Authors recognized the ability for this idea to be the basis of an auction protocol running on the Chia blockchain and began working on the basic idea in early May. Authors would like to thank @Omakasea_ for his brilliant original "onchain unicorn" idea! + * Dan Perry (@DanPerry_Chia) and Ken Griggs (@fizpawiz) were instrumental in providing early feedback for the idea itself, along with great improvement ideas and lots of knowledge and motivation. Thank you both! + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 8e4aebc9a32caebe67aeaa2f0ef3a1d57b904843 Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Fri, 17 Jun 2022 01:17:48 -0500 Subject: [PATCH 05/24] removed footnote --- CHIPs/chip-joshpainter-auctions.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index df7cac26..2f75e629 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -140,4 +140,3 @@ NONE YET... Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## Footnotes -* Relaying historical fact of first recorded auction does not mean author endorses such auctions. \ No newline at end of file From ec53f4bc9eeb34edfb3012e18b98a6d6c4bf4e8a Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Fri, 17 Jun 2022 01:22:51 -0500 Subject: [PATCH 06/24] fix update section typo --- CHIPs/chip-joshpainter-auctions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index 2f75e629..d136f411 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -102,6 +102,7 @@ SECURING... 6/15/2022: * Added Community Feedback section * Added feedback from @Engarneering and @nezzee + 6/17/2022: * Added this Updates section * Shorted intro to take into account community feedback. Thank you @Engarneering and @_nezzee! From 0e8ee450c74fa48c63ee6fe9a707640177811e41 Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Thu, 23 Jun 2022 17:29:46 -0500 Subject: [PATCH 07/24] added summary and hammer time feedback from Dan --- CHIPs/chip-joshpainter-auctions.md | 40 +++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 9 deletions(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index d136f411..7a35b809 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -13,7 +13,7 @@ Replaces | none Superseded-By | none ## Abstract -Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. As early as 500 BC, Babylonians held auctions. Later, ancient Greeks and Romans would auction off their spoils of battle to gain treasure for the war effort. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. +Auction is one of the oldest methods of negotiating the exchange of goods and commodities between buyers and sellers. Babylonians held auctions as early as 500 BC. Later, ancient Greeks and Romans auctioned off their spoils of battle to gain treasure for the war effort. More recently, the Internet has enabled a massive new market for online auctions. Starting with eBay in 1995 and growing every year, online auctions continue to be an important method for trading assets to this day. However, even with all this history, auctions still have unsolved risks for the buyer, the seller, and especially the auction house holding the auction itself. The Chia blockchain, along with the coinset model and Chialisp, brings about new and unique opportunities to improve on this millenia-old practice and eliminate risk for all parties. This document will explore the counterparty risks and issues with modern-day auction. It will then propose high-level solutions to these problems using puzzles created in Chialisp and executed directly on the Chia blockchain. Finally, it will recommend detailed specifications that can be used to build these Chialisp puzzles to enable these solutions. @@ -33,7 +33,7 @@ Modern-day auctions continue to be a valuable tool for finding market value of n By presenting solutions for all of these risks using the Chia blockchain and Chialisp, it is hoped that Chia's overall ecosystem will benefit from the inflow of digital assets as well as the transactions and fees used to fund bids. Auctions are also a natural sales method for NFTs and CATs and a great way to find the market value of these new digital assets. Furthermore, it is hoped that Auctions will be a natural fit for carbon credit asset trading, enabling advancement of Chia's commitment to improve and support the Climate Warehouse for World Bank. -Although there are many auction variations, this proposal will focus on the use-cases of the two most popular methods of auction in use today: English and Dutch. However, the specification will be designed in such a way that almost any kind of auction can be defined, limited only by the power of Chialisp and the auction author's imagination. +Although there are many auction variations, this proposal will focus on the use-cases of the two most popular methods of auction in use today: English and Dutch. * English Auction @@ -43,18 +43,35 @@ Although there are many auction variations, this proposal will focus on the use- This type of auction is also known as a "descending price auction" and it is well-suited for commmodities or lots of the same asset, including CATs. It begins with a high asking price and is successively lowered by the bid increment until a bidder is willing to pay it. The bidder may request any quantity of lots of the item at that bid price. If there are remaining lots of the asset left after the high bidder declares their lot quantity selection, the auction continues until another bidder is willing to pay the descending bid price. That second-highest bidder is also allowed to choose the quantity of lots that they desire, and the auction will continue on until the quantity of lots of the asset is exhausted or the minimum bid amount is met and no more bids are received. +However, the specification is designed so that almost any kind of auction can be defined, limited only by the power of Chialisp and the auction author's imagination. + +## Quick Summary + +1. The initial seller "mints" the "egg" that represents the auction. The egg wraps any Chia asset (i.e. NFTs, CATs, DIDs, DL, etc). +2. The first bidder makes a bid on the egg by paying the seller the minimum bid amount. +3. The first bidder now becomes the new owner of the egg. +4 However, the current owner of the egg cannot "crack" the egg and claim the asset inside until a certain future time or blockheight. +5. Any other bidder may make a higher bid on the egg while it is uncracked. The second and subsequent bidders must pay back the current owner for that owner's last bid and must now pay the original seller the *difference* between the last bidder's bid and this new higher bid. +6. Continues from step 3 above and loops until the current owner "cracks" the egg and claims the asset. + +This guarantees that every bid is settled immediately, which removes all counter-party risk associated with transfer of ownership after the auction ends, as discussed above. + ## Conceptual Design -An auction on the Chia blockchain will be represented by a singleton that wraps an asset, represented by an inner puzzle. A single-lot auction wraps an asset that represents a single unique item, such as an NFT. A multi-lot auction wraps an asset that represents multiple amounts of the same item, such as a CAT. +An auction on the Chia blockchain is a singleton (the "egg") that wraps any Chia asset, represented by an inner puzzle. A single-lot auction wraps an asset that represents a single unique item, such as an NFT. A multi-lot auction wraps an asset that represents multiple amounts of the same item, such as a CAT. The auction singleton puzzle will include several parameters that allow customization of the auction event itself. Bidders must follow all rules and parameters set by the auctioneer. The seller may not be the same entity as the auctioneer. This differentiation allows commissions and/or buyer's premiums to be paid to the auction house to cover promotion, marketing and any other expenses incurred for the real-world execution of the auction. Of course, the seller may also hold the auction on their own behalf. -A normal real-world auction does not settle until after it has closed, which introduces all of the counterparty risks mentioned above. But by using a unique and novel auction protocol, we can completely "settle" each high bid as it happens in real-time. For *every successful high bid* the asset immediately trades ownership and all bid payments, commissions and fees are sent and confirmed at the same time. This means that an auction running on Chia blockchain does not have *any* of the counter-party risks mentioned above. Because the high bid itself actually contains the payment transactions, it is not necessary to trust that either party will follow through with the agreed-upon sale after the auction has concluded. When a high-bidder successfully makes a high bid, the seller has been paid and the high-bidder now officially owns the asset. The only reason they will not hold the asset at the end of the auction is if another high-bidder successfully "steals" it from them by bidding higher. Of course, the original high-bidder then can "steal" it back, and so on. But if no other bidding action happens after a successful high bid, the auction will close and the high-bidder can then claim the wrapped asset. +A normal real-world auction does not settle until after it has closed, which introduces all of the counterparty risks mentioned above. But by using a unique and novel auction protocol, we can completely "settle" each high bid as it happens in real-time. + +For *every successful high bid* the asset immediately trades ownership and all bid payments, commissions and fees are sent and confirmed at the same time. This means that an auction running on Chia blockchain does not have *any* of the counter-party risks mentioned above. Because the bid itself actually contains the payment transactions, it is not necessary to trust that either party will follow through with the agreed-upon sale after the auction has concluded. + +When a high-bidder successfully makes a high bid, the seller has been paid and the high-bidder now officially owns the asset. The only reason they will not hold the asset at the end of the auction is if another high-bidder successfully "steals" it from them by bidding higher. Of course, the original high-bidder then can "steal" it back, and so on. But if no other bidding action happens after a successful high bid, the auction will close and the high-bidder can then claim the wrapped asset. This concept is easy to understand for the first successful high bid. The high bidder actually sends their high bid amount to the seller as a normal transaction. The high bidder may also be required to send an additional buyer's premium fee and/or commission fees to the auctioneer, depending on the settings chosen when the auction singleton is minted. -However, the second and subsequent successful high bids work quite differently. The new high bidder will first reimburse the current high bidder for their current high bid and commission fees via a normal transaction. The current high bidder is now "whole" and loses the ownership of the asset contained within the auction singleton. Ownership is now transferred to the new high bidder. The difference between the new high bid and the current high bid is sent to the seller, along with any required buyer's premium fees and/or commission fees. The seller has now received the initial high bid amount (from the first high bidder) plus the difference between the initial high bid and the new high bid (from the second high bidder). This process continues until the auction has concluded. +However, the second and subsequent successful high bids work quite differently. The new high bidder will first reimburse the current high bidder for their current high bid and commission fees via a normal transaction. The current high bidder is now "whole" and loses the ownership of the egg and also the asset contained within the auction singleton. Ownership is now transferred to the new high bidder. The difference between the new high bid and the current high bid is sent to the seller, along with any required buyer's premium fees and/or commission fees. The seller has now received the initial high bid amount (from the first high bidder) plus the difference between the initial high bid and the new high bid (from the second high bidder). This process continues until the auction has concluded. It should be understood that all of this happens "behind the scenes" from the user's perspective. The user's experience will be very familiar to all who have used any existing auction software. All of this complexity should be accessible via transaction logs of course, but most users will just make high bids on auctions as they always have. Perhaps the only new user education that needs to happen is to make sure that users understand the true immediacy and finality of high bids. Auction houses will be particularly excited with this technology as they will no longer be caught in the middle of buyer and seller disagreements that can arise during the time that the auction has concluded but has not yet settled. All auctions are now actually settled *before* they are concluded! @@ -69,7 +86,7 @@ It should be understood that all of this happens "behind the scenes" from the us * CALC_HAMMER_TIME - the Lisp program that returns either the datetime or the blockheight after which the auction is considered closed. The could be either a static value (pre-committed datetime or blockheight) or a dynamic value (automatically extend until no more bids received). * CALC_BUYERS_PREMIUM - the Lisp program that returns conditions for the Buyer's Premium, if applicable. * CALC_COMMISSION - the Lisp program that returns conditions for the Commission, if applicable. - * PAY_HIGH_BID - the Lisp program that returns conditions for the High Bid payment. + * PAY_HIGH_BID - the Lisp program that returns conditions for the High Bid payment. This is a public spend and can be made by anybody at any time. * If this is the first bid * Send new_high_bid amount to ORIGINAL_OWNER_PH. At this point, the original owner has been paid and the new owner officially owns the asset with the caveat that the asset may be "stolen" by another high bidder before the auction has ended. * Else @@ -77,7 +94,7 @@ It should be understood that all of this happens "behind the scenes" from the us * Send difference between new_high_bid and current_high_bid to ORIGINAL_OWNER_PH. This adds to the original owner's other high bid payments so total payments received equals current high bid at all times. * Include conditions returned from CALC_BUYERS_PREMIUM, if any. This guarantees that the Buyer's Premium is paid for every bid. * Include conditions returned from CALC_COMMISSION, if any. This guarantees that the Commission is paid for every bid. - * CLAIM_ASSET - the Lisp program that returns conditions needed to claim the asset after the auction has ended. This program is also responsible for melting this Auction singleton once the wrapped assets are claimed. + * CLAIM_ASSET - the Lisp program that returns conditions needed to claim the asset. The basic implementation should validate that this claim spend is happening after CALC_HAMMER_TIME and only by the current owner. This program is also responsible for melting this Auction singleton once the wrapped assets are claimed. * Singleton puzzle Parameters * current_high_bid - the amount of the current high bid, in mojos. @@ -105,10 +122,15 @@ SECURING... 6/17/2022: * Added this Updates section - * Shorted intro to take into account community feedback. Thank you @Engarneering and @_nezzee! + * Shortened intro to take into account community feedback. Thank you @Engarneering and @_nezzee! * Added Credit section * Added credit paragraph for @Omakasea_ - thank you! +6/23/2022: + * Added Quick Summary section to make it even easier to digest concept. + * Edited formatting + * Added more details to CLAIM_ASSET after discussion with @DanPerry_Chia about how to end auctions - thanks Dan! + ## Terminology This section describes common auction terminology for which the reader might not be familiar. Even more detailed information, including terminology, history and descriptions of different auction types can be found at https://en.wikipedia.org/wiki/Auction. The terms below are a subset of those found at the preceding link. @@ -134,7 +156,7 @@ This section describes common auction terminology for which the reader might not NONE YET... ## Credit - * Around the end of April 2022, @Omakasea_ and team released the "onchain unicorn" on the Ethereum network. One of the features was the ability for it to be "stolen" from the current owner by a new buyer. Authors recognized the ability for this idea to be the basis of an auction protocol running on the Chia blockchain and began working on the basic idea in early May. Authors would like to thank @Omakasea_ for his brilliant original "onchain unicorn" idea! + * Around the end of April 2022, Omakasea (@Omakasea_) and team released the "onchain unicorn" (@onchainunicorn) on the Ethereum network. One of the features was the ability for it to be "stolen" from the current owner by a new buyer. Author recognized the ability for this idea to be the basis of an auction protocol running on the Chia blockchain and began working on the basic idea in early May. Author would like to thank Omakasea for his brilliant original "onchain unicorn" idea! * Dan Perry (@DanPerry_Chia) and Ken Griggs (@fizpawiz) were instrumental in providing early feedback for the idea itself, along with great improvement ideas and lots of knowledge and motivation. Thank you both! ## Copyright From 47b268ea4fe1885f08994e5fd5a67e47be5ad883 Mon Sep 17 00:00:00 2001 From: Josh Painter Date: Thu, 23 Jun 2022 17:39:12 -0500 Subject: [PATCH 08/24] fix numbering --- CHIPs/chip-joshpainter-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-joshpainter-auctions.md b/CHIPs/chip-joshpainter-auctions.md index 7a35b809..35a5153a 100644 --- a/CHIPs/chip-joshpainter-auctions.md +++ b/CHIPs/chip-joshpainter-auctions.md @@ -50,7 +50,7 @@ However, the specification is designed so that almost any kind of auction can be 1. The initial seller "mints" the "egg" that represents the auction. The egg wraps any Chia asset (i.e. NFTs, CATs, DIDs, DL, etc). 2. The first bidder makes a bid on the egg by paying the seller the minimum bid amount. 3. The first bidder now becomes the new owner of the egg. -4 However, the current owner of the egg cannot "crack" the egg and claim the asset inside until a certain future time or blockheight. +4. However, the current owner of the egg cannot "crack" the egg and claim the asset inside until a certain future time or blockheight. 5. Any other bidder may make a higher bid on the egg while it is uncracked. The second and subsequent bidders must pay back the current owner for that owner's last bid and must now pay the original seller the *difference* between the last bidder's bid and this new higher bid. 6. Continues from step 3 above and loops until the current owner "cracks" the egg and claims the asset. From 67a0968c4ee85a02efa5e1bbac22f497ec530f67 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 04:02:43 -0500 Subject: [PATCH 09/24] Initial commit from template --- CHIPs/chip-joshpainter-editable-metadata | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 CHIPs/chip-joshpainter-editable-metadata diff --git a/CHIPs/chip-joshpainter-editable-metadata b/CHIPs/chip-joshpainter-editable-metadata new file mode 100644 index 00000000..cc0240b2 --- /dev/null +++ b/CHIPs/chip-joshpainter-editable-metadata @@ -0,0 +1,79 @@ +CHIP Number | < Creator must leave this blank. Editor will assign a number.> +:-------------|:---- +Title | Owner-Editable Metadata Format for NFT1 +Description | A standard that allows NFT owners to update some or all of the metadata attributes and store those updates on-chain. +Author | [Josh Painter](https://github.com/joshpainter) +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 | Process +Sub-Category | Informational +Created | 2022-10-17 +Requires | 0007 +Replaces | +Superseded-By | + +This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). All media associated with this CHIP should be added to the `assets/chip-` folder, which you may create after you receive your CHIP number. + +Copy the template file to the `chips` folder, rename it to `chip--`, fill it out, and submit it as a pull request. + +## Abstract +Give a single-paragraph description of your proposal. The abstract should stand on its own -- someone who reads it should be able to understand the gist of your proposal without reading anything else. + +## Motivation +Describe why you are creating this proposal. Make sure to include: + * What problem are you trying to solve? + * How would this proposal benefit Chia's overall ecosystem? + * What are the use cases for this proposal? + * How technically feasible will this be to implement? + +This section is especially critical if you are proposing changes to Chia's core protocols. It should clearly answer all of the above, as well as explain exactly why the current protocol is inadequate. + +## Backwards Compatibility +If your proposal has any backwards incompatibilities, you must list them here. Make sure to include: + * Which aspects of your proposal are not backwards compatible? + * Which alternatives did you consider, and why did you not propose them? + * How severe are the incompatibilities introduced? + * How does your proposal address these incompatibilities? + +## Rationale +Describe the reasons for designing your features in the way you have proposed. Make sure to include: + * Why did you choose your design? + * What design decisions did you make? + * What alternative designs did you consider? + * How have you achieved community consensus for your design? Provide links to discussions if available. + * What objections were raised during your discussions with the community, and how does your design address them? + +## Specification +List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. + +This section should be _detailed_. It needs to allow for competing interoperable implementations. When applicable, it may include technical diagrams to accompany your design. + +## Test Cases + * Most Standards Track proposals will require a suite of test cases, which you may add to the `assets/chip-` folder. + * Some Process proposals will require test cases, depending on the significance of new features being added. + * Informational proposals typically will not require test cases. + +Your proposal will have a greater chance of success if you err on the side of including more test cases. Use your best judgment. + +## Reference Implementation +Most Standards Track proposals, as well as some Process proposals, also will require a reference implementation to be included. It should be added to the same folder as your test cases, `assets/chip-`. + +Regardless of this proposal's category, the reference implementation does not need to be completed in order to move the CHIP into _Draft_. However, it must be provided before the CHIP can be moved into _Review_. + +## Security +This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: + * Security-related design decisions + * Important discussions + * Any security-related guidance + * All threats and risks, as well as how you are addressing them + +## Additional Assets +Give a listing of files associated with this CHIP. This list will be added upon as the CHIP moves along the process of approval. All new files should be added to the `assets/chip-` folder. You should link to each individual file here, using relative links. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + + + From cd6486e0d91390ede292b3cab41f70fa58bf29e5 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 04:09:06 -0500 Subject: [PATCH 10/24] abstract --- CHIPs/chip-joshpainter-editable-metadata | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata b/CHIPs/chip-joshpainter-editable-metadata index cc0240b2..5fb171ed 100644 --- a/CHIPs/chip-joshpainter-editable-metadata +++ b/CHIPs/chip-joshpainter-editable-metadata @@ -13,12 +13,8 @@ Requires | 0007 Replaces | Superseded-By | -This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). All media associated with this CHIP should be added to the `assets/chip-` folder, which you may create after you receive your CHIP number. - -Copy the template file to the `chips` folder, rename it to `chip--`, fill it out, and submit it as a pull request. - ## Abstract -Give a single-paragraph description of your proposal. The abstract should stand on its own -- someone who reads it should be able to understand the gist of your proposal without reading anything else. +The Chia NFT1 standard enables an off-chain metadata file to be referenced by Non-Fungible Tokens (NFTs) on chain, along with a hash of the file that ensures its immutability. The format and schema of this metadata file is described by [CHIP-0007](chip-0007.md). This CHIP describes an easy way to allow the owner of the NFT to update some or all of that metadata, depending on which attributes have been marked as editable by the creator. It is intended to supplement the metadata schema described in [CHIP-0007](chip-0007.md). ## Motivation Describe why you are creating this proposal. Make sure to include: From 2eafe4bf7ea8e73d8fc950aaa2a7332b5023baeb Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 04:09:55 -0500 Subject: [PATCH 11/24] Rename chip-joshpainter-editable-metadata to chip-joshpainter-editable-metadata.md --- ...er-editable-metadata => chip-joshpainter-editable-metadata.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename CHIPs/{chip-joshpainter-editable-metadata => chip-joshpainter-editable-metadata.md} (100%) diff --git a/CHIPs/chip-joshpainter-editable-metadata b/CHIPs/chip-joshpainter-editable-metadata.md similarity index 100% rename from CHIPs/chip-joshpainter-editable-metadata rename to CHIPs/chip-joshpainter-editable-metadata.md From 2b79a2fc86f9ae008c32277f9aeea6b9fc15cf4c Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 04:33:09 -0500 Subject: [PATCH 12/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 29 +++++++++------------ 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index 5fb171ed..1e7ee36d 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -17,30 +17,25 @@ Superseded-By | The Chia NFT1 standard enables an off-chain metadata file to be referenced by Non-Fungible Tokens (NFTs) on chain, along with a hash of the file that ensures its immutability. The format and schema of this metadata file is described by [CHIP-0007](chip-0007.md). This CHIP describes an easy way to allow the owner of the NFT to update some or all of that metadata, depending on which attributes have been marked as editable by the creator. It is intended to supplement the metadata schema described in [CHIP-0007](chip-0007.md). ## Motivation -Describe why you are creating this proposal. Make sure to include: - * What problem are you trying to solve? - * How would this proposal benefit Chia's overall ecosystem? - * What are the use cases for this proposal? - * How technically feasible will this be to implement? +[CHIP-0007](chip-0007.md) specifies the format and schema of the off-chain metadata file. By design, this metadata file is immutable. If any user attempts to update any of the metadata attributes in the referenced metadata file, the hash of the metadata file will change. The NFT viewer program is responsible for checking this hash to make sure the metadata has not been tampered. -This section is especially critical if you are proposing changes to Chia's core protocols. It should clearly answer all of the above, as well as explain exactly why the current protocol is inadequate. +However, the ability for the owner for a NFT to update some or all of the metadata for the NFT has some very interesting use-cases. Of particular interest is a Chia Name Service (CNS) that uses NFTs to resolve records. By allowing the owner to update their own NFT "pointer records," a CNS could enable full self-custody and self-sovereignty of these pointer records. + +Another simple use case is the addition of an editable "notes" attribute in an otherwise-normal NFT. The owner could update the notes with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to these notes, but the full history will always be stored on-chain as an additional bit of provenance! + +This CHIP will explain one method of enabling this feature using existing NFT1 and CHIP-0007 standards with no required changes, including full backwards-compatibility. ## Backwards Compatibility -If your proposal has any backwards incompatibilities, you must list them here. Make sure to include: - * Which aspects of your proposal are not backwards compatible? - * Which alternatives did you consider, and why did you not propose them? - * How severe are the incompatibilities introduced? - * How does your proposal address these incompatibilities? +This CHIP is fully backwards-compatible with CHIP-0007. In fact, it proposes to add just a single new attribute to the CHIP-0007 schema. NFT1 standard requires no changes whatsoever. ## Rationale -Describe the reasons for designing your features in the way you have proposed. Make sure to include: - * Why did you choose your design? - * What design decisions did you make? - * What alternative designs did you consider? - * How have you achieved community consensus for your design? Provide links to discussions if available. - * What objections were raised during your discussions with the community, and how does your design address them? +The method described below is possible today even if this CHIP is never published because it requires no changes to any existing standards. However, by standardizing the "editable" attribute schema, it is hoped that the Chia NFT viewer itself will be able to make use of these editable attributes, along with other future NFT viewers. + +Another possible method to accomplish a similar result would involve Chia Data Layer. Data Layer will no doubt be an important addition to these metadata standards in the future and will enable a much higher amount of data storage. However, Data Layer requires more user interaction and the user must opt-in to the data. By contrast, the method described below is much simpler and works with just a full node. For use cases involving small, rarely-updated data, the impact to the blockchain should be low. ## Specification + + List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. This section should be _detailed_. It needs to allow for competing interoperable implementations. When applicable, it may include technical diagrams to accompany your design. From 1d24b418e9f256d3a55471ee6a964a35c8ac0524 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 06:48:39 -0500 Subject: [PATCH 13/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index 1e7ee36d..63e77f35 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -33,8 +33,21 @@ The method described below is possible today even if this CHIP is never publishe Another possible method to accomplish a similar result would involve Chia Data Layer. Data Layer will no doubt be an important addition to these metadata standards in the future and will enable a much higher amount of data storage. However, Data Layer requires more user interaction and the user must opt-in to the data. By contrast, the method described below is much simpler and works with just a full node. For use cases involving small, rarely-updated data, the impact to the blockchain should be low. +Finally, this small addition to the work already done with CHIP-0007 is a good example of [Lateral Thinking with Withered Technology](https://medium.com/@uczlwha/nintendos-philosophy-lateral-thinking-with-withered-technology-f188f371e670). While the Chia NFT1 standard and CHIP-0007 are certainly not already "withered" according to the normally-accepted definition, a big benefit of this standard is that it uses these existing standards in a new way without breaking them. + ## Specification +This CHIP proposes a new optional boolean property on the "trait" attribute defined in CHIP-0007 called "editable." Here is an example of an "editable" attribute (surrounding metadata removed for brevity): + +``` +... +{ + "trait_type": "Target", + "value": "xch1v96m4cej23hpt4newv8hs9ejcsc760w3p8gh5p6989c7kyaq5juq9hzjgr", + "editable": true +}, +... +``` List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. From 746cc949eef36d55ad2162177627dafc4e6e6c6e Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 06:58:26 -0500 Subject: [PATCH 14/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 22 ++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index 63e77f35..aa24d09f 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -37,10 +37,14 @@ Finally, this small addition to the work already done with CHIP-0007 is a good e ## Specification -This CHIP proposes a new optional boolean property on the "trait" attribute defined in CHIP-0007 called "editable." Here is an example of an "editable" attribute (surrounding metadata removed for brevity): +This CHIP proposes a single new optional boolean property on the "trait" attribute defined in CHIP-0007 called "editable." Here is an example of both a normal and an "editable" attribute (surrounding metadata removed for brevity): ``` ... +{ + "trait_type": "Registered On", + "value": "{$registeredOn}" +}, { "trait_type": "Target", "value": "xch1v96m4cej23hpt4newv8hs9ejcsc760w3p8gh5p6989c7kyaq5juq9hzjgr", @@ -49,21 +53,21 @@ This CHIP proposes a new optional boolean property on the "trait" attribute defi ... ``` -List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. +Only the NFT attributes may include this optional property. The collection attributes mentioned in CHIP-0007 are meant to be the same for all NFTs in the collection and therefore should remain immutable. + +To edit this editable metadata, the owner of the NFT will add a new metadata URL to the NFT using the normal NFT1 standard. However, the URL will merely be a copy of the existing metadata URL with the addition of the editable names and values in the querystring. + +The querystring parameters will be ignored by the host that serves the metadata file and existing NFT viewers, including the official Chia Wallet, will continue to work because the hash has not changed. -This section should be _detailed_. It needs to allow for competing interoperable implementations. When applicable, it may include technical diagrams to accompany your design. +However, NFT viewers or applications with editing capability can now be supported. These new NFT viewers will recognize the "editable" property on metadata attributes and they will instead look to the latest metadata URL's querystring values first to resolve the metadata value. If these values don't exist as querystring values, the values from the metadata file will be used as normal. ## Test Cases - * Most Standards Track proposals will require a suite of test cases, which you may add to the `assets/chip-` folder. - * Some Process proposals will require test cases, depending on the significance of new features being added. - * Informational proposals typically will not require test cases. -Your proposal will have a greater chance of success if you err on the side of including more test cases. Use your best judgment. +Not applicable ## Reference Implementation -Most Standards Track proposals, as well as some Process proposals, also will require a reference implementation to be included. It should be added to the same folder as your test cases, `assets/chip-`. -Regardless of this proposal's category, the reference implementation does not need to be completed in order to move the CHIP into _Draft_. However, it must be provided before the CHIP can be moved into _Review_. +go4me ## Security This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: From bf83ef5d022cbe8334a9806a6d57cf140044c518 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 07:07:16 -0500 Subject: [PATCH 15/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index aa24d09f..ebc91c3b 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -57,10 +57,18 @@ Only the NFT attributes may include this optional property. The collection attri To edit this editable metadata, the owner of the NFT will add a new metadata URL to the NFT using the normal NFT1 standard. However, the URL will merely be a copy of the existing metadata URL with the addition of the editable names and values in the querystring. -The querystring parameters will be ignored by the host that serves the metadata file and existing NFT viewers, including the official Chia Wallet, will continue to work because the hash has not changed. +An example of a normal metadata URL: +https://bafkreig7fmhptchs2gv2o2l3bilkxtddr7r5eo7nkpr26rnetmx5icahvm.ipfs.nftstorage.link/ + +An example of a metadata URL that contains a new value for an editable attribute: +https://bafkreig7fmhptchs2gv2o2l3bilkxtddr7r5eo7nkpr26rnetmx5icahvm.ipfs.nftstorage.link/?Target=xch16nvgtzv2dcs86hmk99kfp3q09vj2k66x0t0z0ttk9k5zcx3yxzaqz9xxaf + +Notice that the second example has an additional querystring value that is ignored by the server - both URLs serve the same file regardless of querystring values. The hash is therefore unchanged. Existing NFT viewers, including the official Chia Wallet, will continue to "just work" with these enhanced URLs. However, NFT viewers or applications with editing capability can now be supported. These new NFT viewers will recognize the "editable" property on metadata attributes and they will instead look to the latest metadata URL's querystring values first to resolve the metadata value. If these values don't exist as querystring values, the values from the metadata file will be used as normal. +The same viewers could allow basic editing by directing the user to add a new URL via CLI or RPC. Perhaps they could even use a web wallet like Goby to sign the transaction that adds the new enhanced URL to the NFT! + ## Test Cases Not applicable From 801bec55c40fcb3e72a958553beb8ddd60f176b0 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Mon, 17 Oct 2022 07:32:47 -0500 Subject: [PATCH 16/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index ebc91c3b..f459d80d 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -23,6 +23,10 @@ However, the ability for the owner for a NFT to update some or all of the metada Another simple use case is the addition of an editable "notes" attribute in an otherwise-normal NFT. The owner could update the notes with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to these notes, but the full history will always be stored on-chain as an additional bit of provenance! +Imagine some sort of digital board game in which the player gets to choose where to place their token(s). These positions could be managed by updating the X/Y metadata attributes of NFTs that represents these digital player tokens! + +Finally, these metadata values could themselves be Merkel tree hashes, allowing proofs-of-inclusion while using minimal on-chain storage space! + This CHIP will explain one method of enabling this feature using existing NFT1 and CHIP-0007 standards with no required changes, including full backwards-compatibility. ## Backwards Compatibility From 5295bec842fcde8071f4a1327a276d9a1862f7a1 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Tue, 18 Oct 2022 22:07:25 -0500 Subject: [PATCH 17/24] Update chip-joshpainter-editable-metadata.md --- CHIPs/chip-joshpainter-editable-metadata.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index f459d80d..dbe96eca 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -21,9 +21,9 @@ The Chia NFT1 standard enables an off-chain metadata file to be referenced by No However, the ability for the owner for a NFT to update some or all of the metadata for the NFT has some very interesting use-cases. Of particular interest is a Chia Name Service (CNS) that uses NFTs to resolve records. By allowing the owner to update their own NFT "pointer records," a CNS could enable full self-custody and self-sovereignty of these pointer records. -Another simple use case is the addition of an editable "notes" attribute in an otherwise-normal NFT. The owner could update the notes with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to these notes, but the full history will always be stored on-chain as an additional bit of provenance! +Another simple use case is the addition of an editable "notes" attribute in an otherwise-normal NFT. The owner could update the notes with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to these notes, but the full history will always be stored on-chain as an additional bit of provenance. -Imagine some sort of digital board game in which the player gets to choose where to place their token(s). These positions could be managed by updating the X/Y metadata attributes of NFTs that represents these digital player tokens! +As another example, imagine some sort of digital board game in which the player gets to choose where to place their token(s). These positions could be managed by updating the X/Y metadata attributes of NFTs that represents these digital player tokens. Finally, these metadata values could themselves be Merkel tree hashes, allowing proofs-of-inclusion while using minimal on-chain storage space! @@ -79,17 +79,15 @@ Not applicable ## Reference Implementation -go4me +The go4.me Chia Name Service (CNS) uses this standard for owner-editable pointer records. See for more details about CNS standards. ## Security -This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: - * Security-related design decisions - * Important discussions - * Any security-related guidance - * All threats and risks, as well as how you are addressing them + +No changes or security issues result from this CHIP. It uses the same rules as the NFT1 standard - only the current owner of the NFT can add a metadata URL to the NFT. ## Additional Assets -Give a listing of files associated with this CHIP. This list will be added upon as the CHIP moves along the process of approval. All new files should be added to the `assets/chip-` folder. You should link to each individual file here, using relative links. + +Not applicable ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ee4d87be7003a12d9df283263c66ca135bd32366 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Tue, 18 Oct 2022 22:11:30 -0500 Subject: [PATCH 18/24] added links, ready to submit PR Ready for feedback --- CHIPs/chip-joshpainter-editable-metadata.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-joshpainter-editable-metadata.md index dbe96eca..9b3a9299 100644 --- a/CHIPs/chip-joshpainter-editable-metadata.md +++ b/CHIPs/chip-joshpainter-editable-metadata.md @@ -27,21 +27,21 @@ As another example, imagine some sort of digital board game in which the player Finally, these metadata values could themselves be Merkel tree hashes, allowing proofs-of-inclusion while using minimal on-chain storage space! -This CHIP will explain one method of enabling this feature using existing NFT1 and CHIP-0007 standards with no required changes, including full backwards-compatibility. +This CHIP will explain one method of enabling this feature using existing NFT1 and [CHIP-0007](chip-0007.md) standards with no required changes, including full backwards-compatibility. ## Backwards Compatibility -This CHIP is fully backwards-compatible with CHIP-0007. In fact, it proposes to add just a single new attribute to the CHIP-0007 schema. NFT1 standard requires no changes whatsoever. +This CHIP is fully backwards-compatible with [CHIP-0007](chip-0007.md). In fact, it proposes to add just a single new attribute to the [CHIP-0007](chip-0007.md) schema. NFT1 standard requires no changes whatsoever. ## Rationale The method described below is possible today even if this CHIP is never published because it requires no changes to any existing standards. However, by standardizing the "editable" attribute schema, it is hoped that the Chia NFT viewer itself will be able to make use of these editable attributes, along with other future NFT viewers. Another possible method to accomplish a similar result would involve Chia Data Layer. Data Layer will no doubt be an important addition to these metadata standards in the future and will enable a much higher amount of data storage. However, Data Layer requires more user interaction and the user must opt-in to the data. By contrast, the method described below is much simpler and works with just a full node. For use cases involving small, rarely-updated data, the impact to the blockchain should be low. -Finally, this small addition to the work already done with CHIP-0007 is a good example of [Lateral Thinking with Withered Technology](https://medium.com/@uczlwha/nintendos-philosophy-lateral-thinking-with-withered-technology-f188f371e670). While the Chia NFT1 standard and CHIP-0007 are certainly not already "withered" according to the normally-accepted definition, a big benefit of this standard is that it uses these existing standards in a new way without breaking them. +Finally, this small addition to the work already done with CHIP-0007 is a good example of [Lateral Thinking with Withered Technology](https://medium.com/@uczlwha/nintendos-philosophy-lateral-thinking-with-withered-technology-f188f371e670). While the Chia NFT1 standard and [CHIP-0007](chip-0007.md) are certainly not already "withered" according to the normally-accepted definition, a big benefit of this standard is that it uses these existing standards in a new way without breaking them. ## Specification -This CHIP proposes a single new optional boolean property on the "trait" attribute defined in CHIP-0007 called "editable." Here is an example of both a normal and an "editable" attribute (surrounding metadata removed for brevity): +This CHIP proposes a single new optional boolean property on the "trait" attribute defined in [CHIP-0007](chip-0007.md) called "editable." Here is an example of both a normal and an "editable" attribute (surrounding metadata removed for brevity): ``` ... @@ -57,7 +57,7 @@ This CHIP proposes a single new optional boolean property on the "trait" attribu ... ``` -Only the NFT attributes may include this optional property. The collection attributes mentioned in CHIP-0007 are meant to be the same for all NFTs in the collection and therefore should remain immutable. +Only the NFT attributes may include this optional property. The collection attributes mentioned in [CHIP-0007](chip-0007.md) are meant to be the same for all NFTs in the collection and therefore should remain immutable. To edit this editable metadata, the owner of the NFT will add a new metadata URL to the NFT using the normal NFT1 standard. However, the URL will merely be a copy of the existing metadata URL with the addition of the editable names and values in the querystring. From 71962105969520c7b9e16097fccc8e693f967b56 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Fri, 16 Jun 2023 13:26:32 -0500 Subject: [PATCH 19/24] Rename chip-joshpainter-editable-metadata.md to chip-0010.md --- CHIPs/{chip-joshpainter-editable-metadata.md => chip-0010.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename CHIPs/{chip-joshpainter-editable-metadata.md => chip-0010.md} (100%) diff --git a/CHIPs/chip-joshpainter-editable-metadata.md b/CHIPs/chip-0010.md similarity index 100% rename from CHIPs/chip-joshpainter-editable-metadata.md rename to CHIPs/chip-0010.md From 978631ff7f594132539259c4438eae4b7cfbfe4a Mon Sep 17 00:00:00 2001 From: joshpainter Date: Sun, 18 Jun 2023 21:34:29 -0500 Subject: [PATCH 20/24] Update chip-0010.md added Etchings description and spec --- CHIPs/chip-0010.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/CHIPs/chip-0010.md b/CHIPs/chip-0010.md index 9b3a9299..1756add3 100644 --- a/CHIPs/chip-0010.md +++ b/CHIPs/chip-0010.md @@ -73,6 +73,20 @@ However, NFT viewers or applications with editing capability can now be supporte The same viewers could allow basic editing by directing the user to add a new URL via CLI or RPC. Perhaps they could even use a web wallet like Goby to sign the transaction that adds the new enhanced URL to the NFT! +### Etchings + +Additionally, this specification describes a single additional editable metadata field that all new and existing NFTs can use called "Etching." An Etching is a simple text field attribute. It is not defined in the metadata json file. It only exists as a querystring name/value pair, like this: + +https://bafkreig7fmhptchs2gv2o2l3bilkxtddr7r5eo7nkpr26rnetmx5icahvm.ipfs.nftstorage.link/?Etching=this%20is%20my%20super-cool%20etching + +Any viewer that supports CHIP-0010 should always look for this "Etching" querystring value on the metadata URI *even if there are no other editable metadata attributes defined in the metadata* and display it in the UI as appropriate. The viewer should also allow the owner to edit the Etching using the same method described above for other editable metadata. + +An Etching could be used for any user-defined content, such as a story about how the owner acquired the NFT, or a critique of the art itself, or even structured data such as JSON or YAML. This data is stored on the blockchain in the metadata URI as querystring values just like the other editable metadata above. This feature allows existing NFTs minted before this CHIP was published to use a simple form of editable metadata too! + +Querystring names are not case-sensitive, so "?Etching=" and "?etching=" and ?ETCHING=" are all acceptable. + +### RPC Whitelist /nft_add_uri + ## Test Cases Not applicable @@ -87,7 +101,8 @@ No changes or security issues result from this CHIP. It uses the same rules as t ## Additional Assets -Not applicable +Presentation: https://bafybeieztz7kn7ykqao3dc6cop6t5kim4qg2ukvh6j32gk4e2r6i7heure.ipfs.nftstorage.link/Chia-CHIP-0010-01.webm +NFT Collection: https://mintgarden.io/collections/chip-0010-col1v6dnjyduum4pdw2r79wwz5mhvd0ejgjc2dqcf325lwwajddxzdpqymjhpr ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 2eb6902eccd460a1bd4034d8cbf347147c577cde Mon Sep 17 00:00:00 2001 From: joshpainter Date: Sun, 18 Jun 2023 21:38:04 -0500 Subject: [PATCH 21/24] Update chip-0010.md added bit about dApps --- CHIPs/chip-0010.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/CHIPs/chip-0010.md b/CHIPs/chip-0010.md index 1756add3..1d67f4d8 100644 --- a/CHIPs/chip-0010.md +++ b/CHIPs/chip-0010.md @@ -85,7 +85,11 @@ An Etching could be used for any user-defined content, such as a story about how Querystring names are not case-sensitive, so "?Etching=" and "?etching=" and ?ETCHING=" are all acceptable. -### RPC Whitelist /nft_add_uri +### dApps/WalletConnect RPC Whitelist + +Ideally the /nft_add_uri RPC endpoint should be added to https://github.com/Chia-Network/chia-blockchain-gui/blob/main/packages/gui/src/constants/WalletConnectCommands.tsx so it can be used by dApps. + +Other dApps like Goby may also add simple functionality similar to how /nft_add_uri to support this CHIP. ## Test Cases From 13f9d5084d693e86b3415ce6306cf4e2568a875e Mon Sep 17 00:00:00 2001 From: joshpainter Date: Sun, 18 Jun 2023 21:41:42 -0500 Subject: [PATCH 22/24] Update chip-0010.md update Etching info --- CHIPs/chip-0010.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHIPs/chip-0010.md b/CHIPs/chip-0010.md index 1d67f4d8..95c63518 100644 --- a/CHIPs/chip-0010.md +++ b/CHIPs/chip-0010.md @@ -21,10 +21,10 @@ The Chia NFT1 standard enables an off-chain metadata file to be referenced by No However, the ability for the owner for a NFT to update some or all of the metadata for the NFT has some very interesting use-cases. Of particular interest is a Chia Name Service (CNS) that uses NFTs to resolve records. By allowing the owner to update their own NFT "pointer records," a CNS could enable full self-custody and self-sovereignty of these pointer records. -Another simple use case is the addition of an editable "notes" attribute in an otherwise-normal NFT. The owner could update the notes with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to these notes, but the full history will always be stored on-chain as an additional bit of provenance. - As another example, imagine some sort of digital board game in which the player gets to choose where to place their token(s). These positions could be managed by updating the X/Y metadata attributes of NFTs that represents these digital player tokens. +Another feature is the "Etching" attribute that exists for all existing and newly-minted NFTs. The owner could update the Etching with any personal information about the NFT, a story about where they got it, etc. The next owner could overwrite or append to this Etching, but the full history will always be stored on-chain as an additional bit of provenance. + Finally, these metadata values could themselves be Merkel tree hashes, allowing proofs-of-inclusion while using minimal on-chain storage space! This CHIP will explain one method of enabling this feature using existing NFT1 and [CHIP-0007](chip-0007.md) standards with no required changes, including full backwards-compatibility. From a409b5daba92c96b2be3d7393cb6a0868eb86f1d Mon Sep 17 00:00:00 2001 From: joshpainter Date: Sun, 18 Jun 2023 21:42:34 -0500 Subject: [PATCH 23/24] Update chip-0010.md --- CHIPs/chip-0010.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0010.md b/CHIPs/chip-0010.md index 95c63518..149eb2c5 100644 --- a/CHIPs/chip-0010.md +++ b/CHIPs/chip-0010.md @@ -97,7 +97,7 @@ Not applicable ## Reference Implementation -The go4.me Chia Name Service (CNS) uses this standard for owner-editable pointer records. See for more details about CNS standards. +The go4.me Chia Name Service (CNS) uses this standard for owner-editable pointer records. ## Security From 5d50ac054190a9c69f87b5fe0cd7dca5ec1c36c0 Mon Sep 17 00:00:00 2001 From: joshpainter Date: Tue, 20 Jun 2023 14:51:40 -0500 Subject: [PATCH 24/24] more etching details --- CHIPs/chip-0010.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0010.md b/CHIPs/chip-0010.md index 149eb2c5..2e6767fd 100644 --- a/CHIPs/chip-0010.md +++ b/CHIPs/chip-0010.md @@ -79,7 +79,7 @@ Additionally, this specification describes a single additional editable metadata https://bafkreig7fmhptchs2gv2o2l3bilkxtddr7r5eo7nkpr26rnetmx5icahvm.ipfs.nftstorage.link/?Etching=this%20is%20my%20super-cool%20etching -Any viewer that supports CHIP-0010 should always look for this "Etching" querystring value on the metadata URI *even if there are no other editable metadata attributes defined in the metadata* and display it in the UI as appropriate. The viewer should also allow the owner to edit the Etching using the same method described above for other editable metadata. +Any viewer that supports CHIP-0010 should always look for this "Etching" querystring value on the metadata URI *even if there are no other editable metadata attributes defined in the metadata.* If the Etching attribute is defined in the metadata, it should be used as the default value like other editable attributes. The viewer should display it in the UI in addition to the other editable metadata. The viewer should allow the owner to edit the Etching using the same method described above for other editable metadata. An Etching could be used for any user-defined content, such as a story about how the owner acquired the NFT, or a critique of the art itself, or even structured data such as JSON or YAML. This data is stored on the blockchain in the metadata URI as querystring values just like the other editable metadata above. This feature allows existing NFTs minted before this CHIP was published to use a simple form of editable metadata too!