From 12fff4961e2701a7fb5e89766000e5324b813c50 Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Tue, 9 Aug 2022 14:02:18 +0100 Subject: [PATCH 1/8] Update hip-0000-template.md Signed-off-by: Matt Smithies --- hip-0000-template.md | 142 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 112 insertions(+), 30 deletions(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index ad05d3461..269818ecb 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -1,71 +1,153 @@ --- -hip: -title: -author: -working-group: a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s). -type: -category: -needs-council-approval: -status: -created: -discussions-to: -updated: -requires: -replaces: -superseded-by: +hip: xxx +title: Fractional NFTs +author: Matthew Smithies , Justyn Spooner , Jesse Whiteside +working-group: Guardian & ESG +type: Standards Track +category: Core +needs-council-approval: No +status: Draft +created: 2022-08-08 +discussions-to: TBA +updated: N/A --- ## Abstract -Please provide a short (~200 word) description of the issue being addressed. +This HIP specifies the need for fractional NFTs within the Hedera eco-system, the purview for this capability is specifically viewed through the lens of ESG assets, such as tokenised carbon credits, to be fractional when primarily created through the Guardian. As ESG assets created are unique they philosophically act more like an NFT as compare to fungible counterparts as they are backed by a real-world asset that is not interchangeable. + +Additionally, this HIP suggests a specification update for adding this capability, simply put to enable decimals within NFT token types. It also includes a view to deal with backwards capability issues for NFT token transfers. + +Naturally, outside the scope of ESG, fractional NFTs would be highly welcome in many other use cases on network as they are present on EVM ecosystems. ## Motivation -The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. +One of the current downsides of NFTs on Hedera are that they are incapable of having decimals, or in other words fractional. Particularly for ESG assets, like carbon credits, this is a particular problem as it becomes impossible to make micro payments due to the lack of fractional or divisable NFTs upon creation, is where one token equals one tonne of carbon. + +If we so wish to mint fractional tokens for emissions or credits at a sub-tonne granularity we require divisible NFTs on token creation. + +Here are some additional points: + +- Partial ownership/division of NFTs is already a thing in EVM land, the network should align with common patterns. +- It would be preferable to mirror specifications like CRUs (as NFTs) as Hashport has NFT bridge capability, thus all guardian derived ESG assets would be multi-chain by default. + - This would inevitably open up easier business development and integration between ecosystems, so DOVU’s generated credits could potentially be bundled into FlowCarbon’s GNT-type assets. + - Thus there would be a greater vector for pooling assets to back stable coins using a range of tokenised commodities (carbon, soya, wheat etc). +- We’re not going to get away from the need for micropayments, KG-level (or less) offsetting. +- In traditional markets, or centralised registries like Gold Standard, a carbon credit represents 1 tonne of removal or reduction. Without this and by potentially going against the grain by minting where 1 token equals 1 kg will result in non-compliant and standardised assets, as well as causing additional onboarding friction for external market actors due to the mis-smatch. +- All tokens are backed by a real asset (NFTs fit that definition moreso then fungible types) +- To be compliant to the [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) for minting carbon removals with fractional granularity we currently need to use Core Carbon Principles (CCP) token instead of the NFT equivalent, Carbon Removal Credits (CRUs). + +Leveraging Hashport as a key piece of infrastructure in ensuring that any ESG asset minted on Hedera is multi-chain (EVM) by default would be a killer application network-wide for both marketplaces, exchanges, and project owners to get access to more capital present on other networks. ## Rationale -The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. +In short, enable optional decimal usage on the creation of NFTs token types and add optional values for transfer functions. -The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. +With regards to Hashport's NFT bridging capability, it at present can only process a single NFT at a time, this would be a challenge for larger volumes of ESG assets but if a precedent was set by minting tokens with this method it would provide a provable route for migration of NFT collections across networks, perhaps with a specific ESG bridging module. ## User stories -Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).” - +1. As a carbon project owner I want to ensure that by carbon credits can be traded on as many platforms as possible +2. As a marketplace, minting with the guardian, I want to ensure client success by providing the largest vector to benefit my clients. + +*Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).”* + ## Specification -The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. +Below the specification will be focusing upon using with the JS SDK as a developer, however it can be applied to any SDK or core HAPI services. + +### Creating a NFT, with the adding of decimals to the Create Transactions + +The only difference here is *unlocking* decimals for NFTs, inside of any documentation we can refer to them as *fractional*, but we retain the same method names as per fungible token types. + +``` +const transaction = new TokenCreateTransaction() + .setTokenName(collection_name) + .setTokenType(TokenType.NonFungibleUnique) + .setSupplyType(TokenSupplyType.Finite) + .setSupplyKey(operatorPrivateKey) + .setTokenSymbol(symbol) + .setTreasuryAccountId(account_id) + .setMaxSupply(supply) + .setInitialSupply(0) + .setDecimals(4) // Allowing decimals +``` + +### Minting an NFT, using set amount + +The default functionality, seen below, will be backward compatible as previously expected that is NFTs will be generated in batches up to 10, based on the setMetadata array size. It will default to mint whole NFTs, if the decimals are set to zero. + +``` +const transaction = await new TokenMintTransaction() + .setTokenId(token_id) + .setMetadata(nftBatchBuffer) + .freezeWith(client) +``` + +However, there would need to be a slight update for minting, this is set below with 4 tokens being minted with the granularity of 4 decimal places. + +- If a NFT has decimals tokens cannot be batched, using an array inside of **setMetadata** must only have 1 entry. +- The amount is used to mint based on the **setAmount** value, as per how fungible HTS tokens work + +``` +const transaction = await new TokenMintTransaction() + .setTokenId(token_id) + .setMetadata(nftSingleBuffer) + .setAmount(4 * 4 ** 1000) + .freezeWith(client) +``` + +### Transfer an NFT + +Below is an example of transferring an NFT, for the *addNftTransfer* method amount has been optional for NFTs that have decimals. + +``` +const transfer = await new TransferTransaction() + .addNftTransfer(new NftId(token_id, serial_number), Config.accountId, receiver_id, amount) + .execute(client) +``` ## Backwards Compatibility -All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. +There are a number of effects of fractional NFT tokens in the ecosystem, these *shouldn't* cause immediate concern, and the ability to process them is opt-in based on a given external teams priority needs. + +All previous NFTs on network need to be considered "non-fractional" by default, this would imply that the "decimal" value of all historic NFTs would be zero. For any `addNftTransfer` inside of `TransferTransaction` calls we would require a forth field in the method signature to represent `value` + +In docs this could be the changes: + +Previous `addNftTransfer(, , )` + +New `addNftTransfer(, , , )` + +However, in particular SDK implementations, like JS, there are at present 4 fields within the signature of the `addNftTransfer` method which is on the cusp of being overloaded, there would need to be careful thought on whether it would be more appropriate to refractor some of these methods, or to include the optional `value` property inside of an `nftId` object. + +### Wallets and downstream clients + +All wallets or clients may behave in the same manner to view or manipulate NFTs, using the same code, however for fractional NFTs there would be a requirement to update codebases to handle updated decimal, in the same way fungible tokens are processed. ## Security Implications -If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. +None, other then NFTs working in the same fashion as using decimals on Fungible token types. ## How to Teach This -For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. +Update the documentation, updated blog post of the feature to cover the new feature, new code examples driven through the core developer advocates, perhaps with bounties. ## Reference Implementation -The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. +TBC (see specification for early approach/design) ## Rejected Ideas -Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. - -In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. ## Open Issues -While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. ## References -A collections of URLs used as references through the HIP. +1. [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) +2. [NFT porting Hashport](https://app.hashport.network/nft-port) + ## Copyright/license From ff62abbbff354c6d8b92fb1665c1474898091fe0 Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Wed, 10 Aug 2022 16:52:13 +0100 Subject: [PATCH 2/8] Revert template Signed-off-by: Matt Smithies --- hip-0000-template.md | 169 +++++++++++++++++++------------------------ 1 file changed, 75 insertions(+), 94 deletions(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index 269818ecb..0c8e87af5 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -1,153 +1,134 @@ --- -hip: xxx -title: Fractional NFTs -author: Matthew Smithies , Justyn Spooner , Jesse Whiteside -working-group: Guardian & ESG -type: Standards Track -category: Core -needs-council-approval: No -status: Draft -created: 2022-08-08 -discussions-to: TBA -updated: N/A +hip: +title: +author: +working-group: a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s). +type: +category: +needs-council-approval: +status: +created: +discussions-to: +updated: +requires: +replaces: +superseded-by: --- ## Abstract -This HIP specifies the need for fractional NFTs within the Hedera eco-system, the purview for this capability is specifically viewed through the lens of ESG assets, such as tokenised carbon credits, to be fractional when primarily created through the Guardian. As ESG assets created are unique they philosophically act more like an NFT as compare to fungible counterparts as they are backed by a real-world asset that is not interchangeable. +Introduce a recommended path of the implementation of minting and maintenance of ecological tokens based on [IWA sustainability](https://github.com/InterWorkAlliance/Sustainability) specifications from the voluntary ecological markets taskforce. This combines and is the first use-case of [dNFT/dFT](https://github.com/trustenterprises/hedera-dnft-specification) on hedera to provide an ability for tokens to attach an unlimited amount of evidence. -Additionally, this HIP suggests a specification update for adding this capability, simply put to enable decimals within NFT token types. It also includes a view to deal with backwards capability issues for NFT token transfers. - -Naturally, outside the scope of ESG, fractional NFTs would be highly welcome in many other use cases on network as they are present on EVM ecosystems. +_note: dNFTs will form a separate HIP at a generic level, but were initially designed to meet the needs of carbon offsetting._ ## Motivation -One of the current downsides of NFTs on Hedera are that they are incapable of having decimals, or in other words fractional. Particularly for ESG assets, like carbon credits, this is a particular problem as it becomes impossible to make micro payments due to the lack of fractional or divisable NFTs upon creation, is where one token equals one tonne of carbon. - -If we so wish to mint fractional tokens for emissions or credits at a sub-tonne granularity we require divisible NFTs on token creation. +There are not enough verified carbon credits globally to meet demand. In turn, corporates are overpaying for carbon credits to meet [ESG](https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp) targets. In addition current carbon credit systems are not fit for purpose due to a number of issues including accountability, leakage, and additionally. -Here are some additional points: - -- Partial ownership/division of NFTs is already a thing in EVM land, the network should align with common patterns. -- It would be preferable to mirror specifications like CRUs (as NFTs) as Hashport has NFT bridge capability, thus all guardian derived ESG assets would be multi-chain by default. - - This would inevitably open up easier business development and integration between ecosystems, so DOVU’s generated credits could potentially be bundled into FlowCarbon’s GNT-type assets. - - Thus there would be a greater vector for pooling assets to back stable coins using a range of tokenised commodities (carbon, soya, wheat etc). -- We’re not going to get away from the need for micropayments, KG-level (or less) offsetting. -- In traditional markets, or centralised registries like Gold Standard, a carbon credit represents 1 tonne of removal or reduction. Without this and by potentially going against the grain by minting where 1 token equals 1 kg will result in non-compliant and standardised assets, as well as causing additional onboarding friction for external market actors due to the mis-smatch. -- All tokens are backed by a real asset (NFTs fit that definition moreso then fungible types) -- To be compliant to the [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) for minting carbon removals with fractional granularity we currently need to use Core Carbon Principles (CCP) token instead of the NFT equivalent, Carbon Removal Credits (CRUs). +## Rationale -Leveraging Hashport as a key piece of infrastructure in ensuring that any ESG asset minted on Hedera is multi-chain (EVM) by default would be a killer application network-wide for both marketplaces, exchanges, and project owners to get access to more capital present on other networks. +Soil is the greatest land store of carbon, and if correct agricultural processes aren't followed this can [trigger a negative effect of carbon stores](https://hedera.com/blog/why-earth-day-2021-means-the-world-to-dovu). At DOVU we believe that such projects should include incentivization structures by default including a layer of accountability so that the carbon capture abilities of soil are optimized. -## Rationale +There are a number of elements that are required: -In short, enable optional decimal usage on the creation of NFTs token types and add optional values for transfer functions. +- A project owner that has been created and is linked to a new [Ecological Project (EP)](https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md). +- A link between HTS and HCS, a common format. +- A genesis message that would reference the initial asset in terms of a [CCP token](https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ccp.md). +- State changes of the CCP representation, with versions and updates including additionally and leakage. +- Continued messages, with a common schema that can be used as a mechanism to upload evidence. -With regards to Hashport's NFT bridging capability, it at present can only process a single NFT at a time, this would be a challenge for larger volumes of ESG assets but if a precedent was set by minting tokens with this method it would provide a provable route for migration of NFT collections across networks, perhaps with a specific ESG bridging module. +I expect that this work will continue to evolve and adjust over time. ## User stories -1. As a carbon project owner I want to ensure that by carbon credits can be traded on as many platforms as possible -2. As a marketplace, minting with the guardian, I want to ensure client success by providing the largest vector to benefit my clients. - -*Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).”* +Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).” ## Specification -Below the specification will be focusing upon using with the JS SDK as a developer, however it can be applied to any SDK or core HAPI services. +### Roles -### Creating a NFT, with the adding of decimals to the Create Transactions +Roles of the -The only difference here is *unlocking* decimals for NFTs, inside of any documentation we can refer to them as *fractional*, but we retain the same method names as per fungible token types. +### A project owner and the creation of an EP -``` -const transaction = new TokenCreateTransaction() - .setTokenName(collection_name) - .setTokenType(TokenType.NonFungibleUnique) - .setSupplyType(TokenSupplyType.Finite) - .setSupplyKey(operatorPrivateKey) - .setTokenSymbol(symbol) - .setTreasuryAccountId(account_id) - .setMaxSupply(supply) - .setInitialSupply(0) - .setDecimals(4) // Allowing decimals -``` +Every project owner is considered a supplier and can create a new (EP)(https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md) on a per-project basis. -### Minting an NFT, using set amount +### The HTS to HCS link -The default functionality, seen below, will be backward compatible as previously expected that is NFTs will be generated in batches up to 10, based on the setMetadata array size. It will default to mint whole NFTs, if the decimals are set to zero. +The basic dNFT specification describes an approach to how to connect an HTS token to an HCS topic, this is described through a format (these formats would ultimately be a HIP unto themselves) -``` -const transaction = await new TokenMintTransaction() - .setTokenId(token_id) - .setMetadata(nftBatchBuffer) - .freezeWith(client) -``` +This is the proposed dNFT ~~name~~ memo format, within 100 bytes. -However, there would need to be a slight update for minting, this is set below with 4 tokens being minted with the granularity of 4 decimal places. +- The Topic Id of the HCS topic +- The Account ID of the minter +- The Symbol of the proposed +- Optional metadata to describe the dNFT -- If a NFT has decimals tokens cannot be batched, using an array inside of **setMetadata** must only have 1 entry. -- The amount is used to mint based on the **setAmount** value, as per how fungible HTS tokens work +This could have this generic form below: -``` -const transaction = await new TokenMintTransaction() - .setTokenId(token_id) - .setMetadata(nftSingleBuffer) - .setAmount(4 * 4 ** 1000) - .freezeWith(client) -``` +> 'ECO:{symbol}_{metadata}:{topic_id}:{account_id}' -### Transfer an NFT +In particular, for DOVU we would look at using **cDOV** as our internal reference of a full token representing a tonne of carbon. -Below is an example of transferring an NFT, for the *addNftTransfer* method amount has been optional for NFTs that have decimals. +> 'ECO:cDOV:{topic_id}:{account_id}' -``` -const transfer = await new TransferTransaction() - .addNftTransfer(new NftId(token_id, serial_number), Config.accountId, receiver_id, amount) - .execute(client) -``` - -## Backwards Compatibility +### The Genesis CCP token message (First HCS message) -There are a number of effects of fractional NFT tokens in the ecosystem, these *shouldn't* cause immediate concern, and the ability to process them is opt-in based on a given external teams priority needs. +The primary rationale behind using CCP specification is due to the unique fungible property. At first -All previous NFTs on network need to be considered "non-fractional" by default, this would imply that the "decimal" value of all historic NFTs would be zero. For any `addNftTransfer` inside of `TransferTransaction` calls we would require a forth field in the method signature to represent `value` +### State Changes to a given project using CCP token spec -In docs this could be the changes: +### Miscellaneous messages for ongoing evidence proofs. -Previous `addNftTransfer(, , )` - -New `addNftTransfer(, , , )` +## Backwards Compatibility -However, in particular SDK implementations, like JS, there are at present 4 fields within the signature of the `addNftTransfer` method which is on the cusp of being overloaded, there would need to be careful thought on whether it would be more appropriate to refractor some of these methods, or to include the optional `value` property inside of an `nftId` object. +No issues. -### Wallets and downstream clients +## Security Implications -All wallets or clients may behave in the same manner to view or manipulate NFTs, using the same code, however for fractional NFTs there would be a requirement to update codebases to handle updated decimal, in the same way fungible tokens are processed. +None, the HCS topic must ensure that the issuer or owner of tokens has the permission to send new messages to act as evidence linked to a token. This could potentially be expanded to include auditors. -## Security Implications +It's likely that the **owner** of a project will have the core permission to post evidence messages as it is their responsibility to prove intent and results in order for the incentivization structure to trigger. -None, other then NFTs working in the same fashion as using decimals on Fungible token types. +Care will have to be taken in the design of the token standard to allow for real-life issues where keys could be lost. ## How to Teach This -Update the documentation, updated blog post of the feature to cover the new feature, new code examples driven through the core developer advocates, perhaps with bounties. +~~For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work.~~ ## Reference Implementation -TBC (see specification for early approach/design) +Work in progress and looking to invite collaboration on the preferred design of this standard, this needs to be driven from all possible ecological projects in the Hedera eco-system. + +~~The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation~~. ## Rejected Ideas +None. ## Open Issues +The Trust Enterprises initial specification of dNFTs has a number of issues: -## References +1) The **name** of the token was used to link to an HCS topic, this will be changed in an official HIP to using the **memo**. +2) It's currently opinionated, has no community consensus, used as a product feature for DOVU and SportsIcon. +3) It's named with **non-fungible** but the token specification does not care if it is divisible, it purely is used as a marketing term to **indicate a token linked to evidence**. +4) In my opinion, there is an expectation that additional HIPs for dNFTs will be created to form a vast number of use-cases as they represent a new genre of token due to flexibility that wasn't possible pre HCS and HTS. +5) It assumes that the issuer of the token is the only entity that can create HCS messages for the given topic. +6) Due to the reduction of HCS message sizes to 1024 bytes there needs to be more reliance on HFS or IPFS services. +7) In particular, for IPFS is to include the [CID](https://docs.ipfs.io/concepts/content-addressing/) within the meta to eliminate the DNS ransom issue for linked content for NFTs. -1. [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) -2. [NFT porting Hashport](https://app.hashport.network/nft-port) +## References +1. https://github.com/trustenterprises/hedera-dnft-specification +2. https://hedera.com/users/dovu +3. https://hedera.com/blog/why-earth-day-2021-means-the-world-to-dovu +4. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ccp.md +5. https://github.com/InterWorkAlliance/Sustainability +6. https://docs.ipfs.io/concepts/content-addressing/ +7. https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp +8. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md +9. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/roles.md ## Copyright/license From d0a7330124709de421c7d7a29216a142c0cc762d Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Wed, 10 Aug 2022 16:52:19 +0100 Subject: [PATCH 3/8] Create hip-0000-fractional-nfts.md Signed-off-by: Matt Smithies --- HIP/hip-0000-fractional-nfts.md | 159 ++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 HIP/hip-0000-fractional-nfts.md diff --git a/HIP/hip-0000-fractional-nfts.md b/HIP/hip-0000-fractional-nfts.md new file mode 100644 index 000000000..003e42334 --- /dev/null +++ b/HIP/hip-0000-fractional-nfts.md @@ -0,0 +1,159 @@ +--- +hip: xxx +title: Fractional NFTs +author: Matthew Smithies , Justyn Spooner , Jesse Whiteside +working-group: Guardian & ESG +type: Standards Track +category: Core +needs-council-approval: No +status: Draft +created: 2022-08-08 +discussions-to: TBA +updated: N/A +--- + +## Abstract + +This HIP specifies the need for fractional NFTs within the Hedera eco-system, the purview for this capability is specifically viewed through the lens of ESG assets, such as tokenised carbon credits, to be fractional when primarily created through the Guardian. As ESG assets created are unique they philosophically act more like an NFT as compare to fungible counterparts as they are backed by a real-world asset that is not interchangeable. + +Additionally, this HIP suggests a specification update for adding this capability, simply put to enable decimals within NFT token types. It also includes a view to deal with backwards capability issues for NFT token transfers. + +Naturally, outside the scope of ESG, fractional NFTs would be highly welcome in many other use cases on the network as they are present on EVM ecosystems. + +## Motivation + +One of the current downsides of NFTs on Hedera are that they are incapable of having decimals, or in other words fractional. Particularly for ESG assets, like carbon credits, this is a particular problem as it becomes impossible to make micro payments due to the lack of fractional or divisable NFTs upon creation, is where one token equals one tonne of carbon. + +If we so wish to mint fractional tokens for emissions or credits at a sub-tonne granularity we require divisible NFTs on token creation. + +Here are some additional points: + +- Partial ownership/division of NFTs is already a thing in EVM land, the network should align with common patterns. +- It would be preferable to mirror specifications like CRUs (as NFTs) as Hashport has NFT bridge capability, thus all guardian derived ESG assets would be multi-chain by default. + - This would inevitably open up easier business development and integration between ecosystems, so DOVU’s generated credits could potentially be bundled into FlowCarbon’s GNT-type assets. + - Thus there would be a greater vector for pooling assets to back stable coins using a range of tokenised commodities (carbon, soya, wheat etc). +- We’re not going to get away from the need for micropayments, KG-level (or less) offsetting. +- In traditional markets, or centralised registries like Gold Standard, a carbon credit represents 1 tonne of removal or reduction. Without this and by potentially going against the grain by minting where 1 token equals 1 kg will result in non-compliant and non-standardised assets, as well as causing additional onboarding friction for external market actors due to the mismatch. +- All tokens are backed by a real asset (NFTs fit that definition moreso then fungible types) +- To be compliant to the IWA Framework for minting carbon removals with fractional granularity we currently need to use Core Carbon Principles (CCP) token instead of the NFT equivalent, Carbon Removal Credits (CRUs). + +Leveraging Hashport as a key piece of infrastructure in ensuring that any ESG asset minted on Hedera is multi-chain (EVM) by default would be a killer application network-wide for both marketplaces, exchanges, and project owners to get access to more capital present on other networks. + + +## Rationale + +In short, enable optional decimal usage on the creation of NFTs token types and add optional values for transfer functions. + +With regards to Hashport's NFT bridging capability, it at present can only process a single NFT at a time, this would be a challenge for larger volumes of ESG assets but if a precedent was set by minting tokens with this method it would provide a provable route for migration of NFT collections across networks, perhaps with a specific ESG bridging module. + +## User stories + +1. As a carbon project owner I want to ensure that by carbon credits can be traded on as many platforms as possible +2. As a marketplace I want to mint fractional NFTs with the guardian as to ensure client success by providing the largest vector for access to capital to benefit my clients. +3. As an organisation, such as an airline, that offers automatic offset as a benefit for product purchase I want sub-tonne granularity in offsetting my clients carbon footprint. +4. As a standard registry who is minting credits I want to use fractional NFTs to ensure that I can be compliant with the IWA CRU specifications +5. As a NFT project owner I want to use fractional NFTs so that they can be owned by various parties, this could make it affordable to acquire a fractional slice of an NFT. + +## Specification + +Below the specification will be focusing upon using with the JS SDK as a developer, however it can be applied to any SDK or core HAPI services. + +### Creating a NFT, with the adding of decimals to the Create Transactions + +The only difference here is *unlocking* decimals for NFTs, inside of any documentation we can refer to them as *fractional*, but we retain the same method names as per fungible token types. + + +``` +const transaction = new TokenCreateTransaction() + .setTokenName(collection_name) + .setTokenType(TokenType.NonFungibleUnique) + .setSupplyType(TokenSupplyType.Finite) + .setSupplyKey(operatorPrivateKey) + .setTokenSymbol(symbol) + .setTreasuryAccountId(account_id) + .setMaxSupply(supply) + .setInitialSupply(0) + .setDecimals(4) // Allowing decimals +``` + +### Minting an NFT, using set amount + +The default functionality, seen below, will be backward compatible as previously expected that is NFTs will be generated in batches up to 10, based on the setMetadata array size. It will default to mint whole NFTs, if the decimals are set to zero. + +``` +const transaction = await new TokenMintTransaction() + .setTokenId(token_id) + .setMetadata(nftBatchBuffer) + .freezeWith(client) +``` + +However, there would need to be a slight update for minting, this is set below with 4 tokens being minted with the granularity of 4 decimal places. + +- If a NFT has decimals tokens cannot be batched, using an array inside of setMetadata must only have 1 entry. +- The amount is used to mint based on the setAmount value, as per how fungible HTS tokens work + +``` +const transaction = await new TokenMintTransaction() + .setTokenId(token_id) + .setMetadata(nftSingleBuffer) + .setAmount(4 * 4 ** 1000) + .freezeWith(client) +``` + +### Transfer an NFT + +Below is an example of transferring an NFT, for the *addNftTransfer* method amount has been optional for NFTs that have decimals. + +``` +const transfer = await new TransferTransaction() + .addNftTransfer(new NftId(token_id, serial_number), Config.accountId, receiver_id, amount) + .execute(client) +``` + +## Backwards Compatibility + +There are a number of effects of fractional NFT tokens in the ecosystem, these *shouldn't* cause immediate concern, and the ability to process them is opt-in based on a given external teams priority needs. + +All previous NFTs on network need to be considered "non-fractional" by default, this would imply that the "decimal" value of all historic NFTs would be zero. For any `addNftTransfer` inside of `TransferTransaction` calls we would require a forth field in the method signature to represent `value` + +In docs this could be the changes: + +Previous `addNftTransfer(, , )` + +New `addNftTransfer(, , , )` + +However, in particular SDK implementations, like JS, there are at present 4 fields within the signature of the `addNftTransfer` method which is on the cusp of being overloaded, there would need to be careful thought on whether it would be more appropriate to refractor some of these methods, or to include the optional `value` property inside of an `nftId` object. + +### Wallets and downstream clients + +All wallets or clients may behave in the same manner to view or manipulate NFTs, using the same code, however for fractional NFTs there would be a requirement to update codebases to handle updated decimal, in the same way fungible tokens are processed. + +## Security Implications + +None, other than NFTs working in the same fashion as using decimals on Fungible token types. + +## How to Teach This + +Update the documentation, updated blog post of the feature to cover the new feature, new code examples driven through the core developer advocates, perhaps with bounties. + +## Reference Implementation + +TBC (see specification for early approach/design) + +## Rejected Ideas + +The approach that EVM-based solutions take is through using smart contracts, by ingesting ERC721 tokens then provide an extended capability for fractionalisation. For Hedera services it makes more sense to add this feature as part of core HTS. However, with this in mind fractional NFTs may likey be needed to bridge as a whole unique to form ERC721, for EVM ecosystem compatibility. + +## Open Issues + + +## References + +1. [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) +2. [NFT porting Hashport](https://app.hashport.network/nft-port) +3. [What are fractional NFTs?](https://learn.bybit.com/nft/what-are-fractional-nfts/) + + +## Copyright/license + +This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) From 3e5249237f9d5f0472abb8bffd1789cf44d11f74 Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Wed, 10 Aug 2022 17:11:54 +0100 Subject: [PATCH 4/8] Update hip-0000-template.md Signed-off-by: Matt Smithies --- hip-0000-template.md | 91 +++++++------------------------------------- 1 file changed, 14 insertions(+), 77 deletions(-) diff --git a/hip-0000-template.md b/hip-0000-template.md index 0c8e87af5..430136c9e 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -17,27 +17,17 @@ superseded-by: ## Abstract -Introduce a recommended path of the implementation of minting and maintenance of ecological tokens based on [IWA sustainability](https://github.com/InterWorkAlliance/Sustainability) specifications from the voluntary ecological markets taskforce. This combines and is the first use-case of [dNFT/dFT](https://github.com/trustenterprises/hedera-dnft-specification) on hedera to provide an ability for tokens to attach an unlimited amount of evidence. - -_note: dNFTs will form a separate HIP at a generic level, but were initially designed to meet the needs of carbon offsetting._ +Please provide a short (~200 word) description of the issue being addressed. ## Motivation -There are not enough verified carbon credits globally to meet demand. In turn, corporates are overpaying for carbon credits to meet [ESG](https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp) targets. In addition current carbon credit systems are not fit for purpose due to a number of issues including accountability, leakage, and additionally. +The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. ## Rationale -Soil is the greatest land store of carbon, and if correct agricultural processes aren't followed this can [trigger a negative effect of carbon stores](https://hedera.com/blog/why-earth-day-2021-means-the-world-to-dovu). At DOVU we believe that such projects should include incentivization structures by default including a layer of accountability so that the carbon capture abilities of soil are optimized. - -There are a number of elements that are required: - -- A project owner that has been created and is linked to a new [Ecological Project (EP)](https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md). -- A link between HTS and HCS, a common format. -- A genesis message that would reference the initial asset in terms of a [CCP token](https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ccp.md). -- State changes of the CCP representation, with versions and updates including additionally and leakage. -- Continued messages, with a common schema that can be used as a mechanism to upload evidence. +The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. -I expect that this work will continue to evolve and adjust over time. +The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. ## User stories @@ -45,90 +35,37 @@ Provide a list of "user stories" to express how this feature, functionality, imp ## Specification -### Roles - -Roles of the - -### A project owner and the creation of an EP - -Every project owner is considered a supplier and can create a new (EP)(https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md) on a per-project basis. - -### The HTS to HCS link - -The basic dNFT specification describes an approach to how to connect an HTS token to an HCS topic, this is described through a format (these formats would ultimately be a HIP unto themselves) - -This is the proposed dNFT ~~name~~ memo format, within 100 bytes. - -- The Topic Id of the HCS topic -- The Account ID of the minter -- The Symbol of the proposed -- Optional metadata to describe the dNFT - -This could have this generic form below: - -> 'ECO:{symbol}_{metadata}:{topic_id}:{account_id}' - -In particular, for DOVU we would look at using **cDOV** as our internal reference of a full token representing a tonne of carbon. - -> 'ECO:cDOV:{topic_id}:{account_id}' - -### The Genesis CCP token message (First HCS message) - -The primary rationale behind using CCP specification is due to the unique fungible property. At first - -### State Changes to a given project using CCP token spec - -### Miscellaneous messages for ongoing evidence proofs. +The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. ## Backwards Compatibility -No issues. +All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. ## Security Implications -None, the HCS topic must ensure that the issuer or owner of tokens has the permission to send new messages to act as evidence linked to a token. This could potentially be expanded to include auditors. - -It's likely that the **owner** of a project will have the core permission to post evidence messages as it is their responsibility to prove intent and results in order for the incentivization structure to trigger. - -Care will have to be taken in the design of the token standard to allow for real-life issues where keys could be lost. +If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. ## How to Teach This -~~For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work.~~ +For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. ## Reference Implementation -Work in progress and looking to invite collaboration on the preferred design of this standard, this needs to be driven from all possible ecological projects in the Hedera eco-system. - -~~The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation~~. +The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. ## Rejected Ideas -None. +Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. -## Open Issues +In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. -The Trust Enterprises initial specification of dNFTs has a number of issues: +## Open Issues -1) The **name** of the token was used to link to an HCS topic, this will be changed in an official HIP to using the **memo**. -2) It's currently opinionated, has no community consensus, used as a product feature for DOVU and SportsIcon. -3) It's named with **non-fungible** but the token specification does not care if it is divisible, it purely is used as a marketing term to **indicate a token linked to evidence**. -4) In my opinion, there is an expectation that additional HIPs for dNFTs will be created to form a vast number of use-cases as they represent a new genre of token due to flexibility that wasn't possible pre HCS and HTS. -5) It assumes that the issuer of the token is the only entity that can create HCS messages for the given topic. -6) Due to the reduction of HCS message sizes to 1024 bytes there needs to be more reliance on HFS or IPFS services. -7) In particular, for IPFS is to include the [CID](https://docs.ipfs.io/concepts/content-addressing/) within the meta to eliminate the DNS ransom issue for linked content for NFTs. +While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. ## References -1. https://github.com/trustenterprises/hedera-dnft-specification -2. https://hedera.com/users/dovu -3. https://hedera.com/blog/why-earth-day-2021-means-the-world-to-dovu -4. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ccp.md -5. https://github.com/InterWorkAlliance/Sustainability -6. https://docs.ipfs.io/concepts/content-addressing/ -7. https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp -8. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/supply/ep.md -9. https://github.com/InterWorkAlliance/Sustainability/blob/main/vem/roles.md +A collections of URLs used as references through the HIP. ## Copyright/license From 496eade7cd918bd603f5a3336565b1156698e269 Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Thu, 11 Aug 2022 15:55:49 +0100 Subject: [PATCH 5/8] Update hip-0000-fractional-nfts.md Signed-off-by: Matt Smithies --- HIP/hip-0000-fractional-nfts.md | 66 ++++++++++++++++++++++++--------- 1 file changed, 49 insertions(+), 17 deletions(-) diff --git a/HIP/hip-0000-fractional-nfts.md b/HIP/hip-0000-fractional-nfts.md index 003e42334..bec8c4456 100644 --- a/HIP/hip-0000-fractional-nfts.md +++ b/HIP/hip-0000-fractional-nfts.md @@ -16,35 +16,55 @@ updated: N/A This HIP specifies the need for fractional NFTs within the Hedera eco-system, the purview for this capability is specifically viewed through the lens of ESG assets, such as tokenised carbon credits, to be fractional when primarily created through the Guardian. As ESG assets created are unique they philosophically act more like an NFT as compare to fungible counterparts as they are backed by a real-world asset that is not interchangeable. -Additionally, this HIP suggests a specification update for adding this capability, simply put to enable decimals within NFT token types. It also includes a view to deal with backwards capability issues for NFT token transfers. +Additionally, this HIP suggests a specification update for adding this capability, simply put to enable decimals with a new token type of Fractional Non Fungible. It also includes a view to deal with backwards capability issues for NFT token transfers. -Naturally, outside the scope of ESG, fractional NFTs would be highly welcome in many other use cases on the network as they are present on EVM ecosystems. +Naturally, outside the scope of ESG, fractional NFTs would be highly welcome in many other use cases on the network as they are present on EVM ecosystems. However, there are challenges of colliding, triggering unknown side effects, with the current NFT ecosystem present on network so we need to tread carefully. ## Motivation +The digitial world is moving in a direction whereby all of the things will be tokenised, although we have the tools at our disposal for tokenisation that is a gap that needs addressing, the capibility to map real-life living breathing entities into a system that is capable to detecting changes over time. + +To understand our background, in early 2021, DOVU productised a concept known as dynamic NFTs (dNFTs) by combining tokenisation and consensus services into our carbon credits so that we could map an area of land to a token and continually prove the evolution of an entity over time through evidence and documentation, this became the basis for our marketplace. + +In the context of DOVU, we have focused on soil being the second largest source of carbon sequestion, but the most accessible. Although not perfect, this stance of tokenisation helped us go to market and to allow us to sell offsets until which time our Guardian tech was ready. + +The Guardian for us is an important step as our goal is to build the trust layer for carbon offset integrity, that is to have a transparent and pipeline or policy engine from project onboarding to retirement. Guardian tech provides an ability for us to connect decentralised identity to our pipeline, so that every actor will sign off with their specific authority. This also ties into following IWA specifications for tokenising carbon in a correct and compliant fashion, as ecological projects. + +The story for many other ESG projects on Hedera has many similarities. + +Back to the real-world, the view of a real-life evoving asset granularity is key, there could be any number of effects and interesting behaviour with carbon credits, for example: + +Land geography can change the density of which carbon can be sequestered. +Specific areas are at higher risk of “leakage” effects. +Crop rotation or a migration to a regenative agreculture approach will have different effects across an area of land. + +All in all, the more granular about a project the more varience in value there is, the credits that are produced at a sub/fractional area could be deemed to be lower risk and more effective, thus in markets be considered to be of a higher value. As a secondary measure, granular tracking provides + One of the current downsides of NFTs on Hedera are that they are incapable of having decimals, or in other words fractional. Particularly for ESG assets, like carbon credits, this is a particular problem as it becomes impossible to make micro payments due to the lack of fractional or divisable NFTs upon creation, is where one token equals one tonne of carbon. If we so wish to mint fractional tokens for emissions or credits at a sub-tonne granularity we require divisible NFTs on token creation. Here are some additional points: -- Partial ownership/division of NFTs is already a thing in EVM land, the network should align with common patterns. -- It would be preferable to mirror specifications like CRUs (as NFTs) as Hashport has NFT bridge capability, thus all guardian derived ESG assets would be multi-chain by default. - - This would inevitably open up easier business development and integration between ecosystems, so DOVU’s generated credits could potentially be bundled into FlowCarbon’s GNT-type assets. - - Thus there would be a greater vector for pooling assets to back stable coins using a range of tokenised commodities (carbon, soya, wheat etc). -- We’re not going to get away from the need for micropayments, KG-level (or less) offsetting. -- In traditional markets, or centralised registries like Gold Standard, a carbon credit represents 1 tonne of removal or reduction. Without this and by potentially going against the grain by minting where 1 token equals 1 kg will result in non-compliant and non-standardised assets, as well as causing additional onboarding friction for external market actors due to the mismatch. -- All tokens are backed by a real asset (NFTs fit that definition moreso then fungible types) -- To be compliant to the IWA Framework for minting carbon removals with fractional granularity we currently need to use Core Carbon Principles (CCP) token instead of the NFT equivalent, Carbon Removal Credits (CRUs). +Partial ownership/division of NFTs is already a thing in EVM land, the network should align with common patterns. +It would be preferable to mirror specifications like CRUs (as NFTs) as Hashport has NFT bridge capability, thus all guardian derived ESG assets would be multi-chain by default. +This would inevitably open up easier business development and integration between ecosystems, so DOVU’s generated credits could potentially be bundled into FlowCarbon’s GNT-type assets. +Thus there would be a greater vector for pooling assets to back stable coins using a range of tokenised commodities (carbon, soya, wheat etc). +We’re not going to get away from the need for micropayments, KG-level (or less) offsetting. +In traditional markets, or centralised registries like Gold Standard, a carbon credit represents 1 tonne of removal or reduction. Without this and by potentially going against the grain by minting where 1 token equals 1 kg will result in non-compliant and non-standardised assets, as well as causing additional onboarding friction for external market actors due to the mis-smatch. +All tokens are backed by a real asset (NFTs fit that definition moreso then fungible types) +To be compliant to the IWA Framework for minting carbon removals with fractional granularity we currently need to use Core Carbon Principles (CCP) token instead of the NFT equivalent, Carbon Removal Credits (CRUs). -Leveraging Hashport as a key piece of infrastructure in ensuring that any ESG asset minted on Hedera is multi-chain (EVM) by default would be a killer application network-wide for both marketplaces, exchanges, and project owners to get access to more capital present on other networks. +Leveraging Hashport as a key piece of infrastructure in ensuring that any ESG asset minted on Hedera through the Guardian is multi-chain (EVM) by default would be a killer application network-wide for both marketplaces, exchanges, and project owners to get access to more capital present on other networks. ## Rationale In short, enable optional decimal usage on the creation of NFTs token types and add optional values for transfer functions. -With regards to Hashport's NFT bridging capability, it at present can only process a single NFT at a time, this would be a challenge for larger volumes of ESG assets but if a precedent was set by minting tokens with this method it would provide a provable route for migration of NFT collections across networks, perhaps with a specific ESG bridging module. +To remove potential side effects with the core NFT community a new token type is recommended to describe fractional NFTs. + +With regards to Hashport's NFT bridging capability, it at present can only process a single NFT at a time, this would be a challenge for larger volumes of ESG assets but if a precedent was set by minting tokens with this method it would provide a provable route for migration of NFT collections across networks, perhaps with a specific ESG or Fractional bridging module. ## User stories @@ -60,14 +80,16 @@ Below the specification will be focusing upon using with the JS SDK as a develop ### Creating a NFT, with the adding of decimals to the Create Transactions -The only difference here is *unlocking* decimals for NFTs, inside of any documentation we can refer to them as *fractional*, but we retain the same method names as per fungible token types. +There are two differences here, first *unlocking* decimals for NFTs, inside any documentation we can refer to them as *fractional*, but we retain the same method names as per fungible token types. + +The second, is to provide a new entity TokenType of FractionalNonFungibleUnique, so that it won’t affect the current NFT infrastructure on Hedera. ``` const transaction = new TokenCreateTransaction() .setTokenName(collection_name) .setTokenType(TokenType.NonFungibleUnique) - .setSupplyType(TokenSupplyType.Finite) + .setSupplyType(TokenSupplyType.Infinite) .setSupplyKey(operatorPrivateKey) .setTokenSymbol(symbol) .setTreasuryAccountId(account_id) @@ -124,13 +146,23 @@ New `addNftTransfer(, , , Just like we have a different token type for fungible tokens, I think there should be a different token type for Fractionlized Non Fungible Tokens or FNFTs +> +> A lot of infrastructure that's being built or that is already in place for NFTs has an understanding that 1 serial # = 1 entity / 1 wallet. +> +> Injecting the possibility of there being 1 serial number on 1 token Id that can be in multiple wallets would cause a lot of systems to need to be refactored, headaches for possible scams and exploits +> +> Segmenting this update out into it's own type of token would allow clearer delineation, and remove the chance an ADMIN key could later segment out multiple fractions of an already minted NFT in circulation ## How to Teach This @@ -152,7 +184,7 @@ The approach that EVM-based solutions take is through using smart contracts, by 1. [IWA Framework](https://interwork.org/wp-content/uploads/2021/11/Digital-MRV-Framework-1.0.pdf) 2. [NFT porting Hashport](https://app.hashport.network/nft-port) 3. [What are fractional NFTs?](https://learn.bybit.com/nft/what-are-fractional-nfts/) - +4. [dNFT DOVU Specification - feb 2021](https://github.com/trustenterprises/hedera-dnft-specification) ## Copyright/license From 0b067d230476ec10f300b81f7e6f5e097c59defc Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Thu, 11 Aug 2022 16:41:47 +0100 Subject: [PATCH 6/8] Hopefully working group works Signed-off-by: Matt Smithies --- HIP/hip-0000-fractional-nfts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HIP/hip-0000-fractional-nfts.md b/HIP/hip-0000-fractional-nfts.md index bec8c4456..30d06a41d 100644 --- a/HIP/hip-0000-fractional-nfts.md +++ b/HIP/hip-0000-fractional-nfts.md @@ -2,7 +2,7 @@ hip: xxx title: Fractional NFTs author: Matthew Smithies , Justyn Spooner , Jesse Whiteside -working-group: Guardian & ESG +working-group: Matthew Smithies type: Standards Track category: Core needs-council-approval: No From 36969884fbd3e43752b16a55619a6b3742b4e60e Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Wed, 10 Aug 2022 16:52:19 +0100 Subject: [PATCH 7/8] Create hip-0000-fractional-nfts.md Signed-off-by: Matt Smithies --- HIP/hip-0000-fractional-nfts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/HIP/hip-0000-fractional-nfts.md b/HIP/hip-0000-fractional-nfts.md index 30d06a41d..a53576313 100644 --- a/HIP/hip-0000-fractional-nfts.md +++ b/HIP/hip-0000-fractional-nfts.md @@ -157,11 +157,11 @@ We have opted for a new token type as of the unknown side effects on the current From Patches perspective on the effect on the NFT Hedera community: > Just like we have a different token type for fungible tokens, I think there should be a different token type for Fractionlized Non Fungible Tokens or FNFTs -> +> > A lot of infrastructure that's being built or that is already in place for NFTs has an understanding that 1 serial # = 1 entity / 1 wallet. -> +> > Injecting the possibility of there being 1 serial number on 1 token Id that can be in multiple wallets would cause a lot of systems to need to be refactored, headaches for possible scams and exploits -> +> > Segmenting this update out into it's own type of token would allow clearer delineation, and remove the chance an ADMIN key could later segment out multiple fractions of an already minted NFT in circulation ## How to Teach This From 86eb0b70850b953760dbc22d214d5842f310f892 Mon Sep 17 00:00:00 2001 From: Matt Smithies Date: Thu, 11 Aug 2022 17:50:59 +0100 Subject: [PATCH 8/8] Update header Signed-off-by: Matt Smithies --- HIP/hip-0000-fractional-nfts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/HIP/hip-0000-fractional-nfts.md b/HIP/hip-0000-fractional-nfts.md index a53576313..36a0362c7 100644 --- a/HIP/hip-0000-fractional-nfts.md +++ b/HIP/hip-0000-fractional-nfts.md @@ -1,5 +1,5 @@ --- -hip: xxx +hip: 000 title: Fractional NFTs author: Matthew Smithies , Justyn Spooner , Jesse Whiteside working-group: Matthew Smithies @@ -8,8 +8,8 @@ category: Core needs-council-approval: No status: Draft created: 2022-08-08 -discussions-to: TBA -updated: N/A +discussions-to: https://docs.google.com/document/d/1HOrUBHX6CCcb5Ch0b5QLEp1qWA65fa9ztggoSM_xggU +updated: 2022-08-11 --- ## Abstract