[WIP] Ecological Carbon Taxonomy using dynamic NFTs

[mattsmithies]

HIP	Title	author/s	type	category	status
TBD	Ecological Carbon Tokens	Matthew Smithies (matt.s@dovu.io)	Informational	Application	Draft

Abstract

Introduce a recommended path of the implementation of minting and maintenance of ecological tokens based on IWA sustainability specifications from the voluntary ecological markets taskforce. This combines and is the first use-case of dNFT/dFT 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.

Motivation

There are not enough verified carbon credits globally to meet demand. In turn, corporates are overpaying for carbon credits to meet ESG targets. In addition current carbon credit systems are not fit for purpose due to a number of issues including accountability, leakage, and additionally.

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. 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).
• A link between HTS and HCS, a common format.
• A genesis message that would reference the initial asset in terms of a CCP token.
• 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.

I expect that this work will continue to evolve and adjust over time.

Specification

Roles

TODO: Describe IWA Roles and how they relate to this

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. A buyer of a EP may purchase a minium of 1 KG of offset, a CCP unit would be representative of 1 Tonne.

State Changes to a given project using CCP token spec

Conceptually DOVU's offering is adding accountability and measurements overtime into carbon projects. This is incentivised through locking up of DOV tokens inside of an EP over a set period of time, to ensure that a farmer (project owner) cannot get access to the full amount of value in the project's marketplace exchange pool (Unibar.

For CCP we expect to extend the token but providing a version number from within the given message.

When there has been a state change to a carbon project, where a measurement has occurred there may be an opportunity to update the project's state in terms of carbon available for purchase.

These situations have been highlighted whereby there would trigger a change of state of the CCP for a given EP.

1. Additionality: An audited/verified measurement that indicates an increase in carbon stores.
2. Leakage: An audited/verified measurement to indicate the reduction of carbon storage.
3. Cancellation state.

A supplier, they are incentivized to continually update documents to unlock value from their Pool. This could also be tied to desired outcomes but this is to be reached but the effort of submission should be rewarded over targets.

If a supplier fails based on conditions the original "staked" funds are returned to the original buyers.

Further research and clarification is required to understand whether a CCP would fit this model.

Miscellaneous messages for ongoing evidence proofs.

For all additional messages within a given topic there can be updates for the verification portion of a supplier's responsibility.

Furthermore, as a buyer of credits in a marketplace there needs to be evidence that can be easily viewed to ensure the integrity of a project before investing. This could be viewed, but not limited to:

• Location of farm
• Photos
• Lab reports
• Measurements
• Signed documents from an auditor

Backwards Compatibility

No issues.

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.

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.

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.

Rejected Ideas

None.

Open Issues

The Trust Enterprises initial specification of dNFTs has a number of 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 within the meta to eliminate the DNS ransom issue for linked content for NFTs.

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

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[kenthejr]

For the memo format, why not use a DID format?

[dubgeis]

We've been in discussions with quite a few projects who've been looking at CCP's and other types of credits, we've seen 5+ projects looking pretty hard at DID/Verifiable Credential (VC) based approach with a trust anchor issuing the VC.

[mattsmithies]

Yes, I agree using a DID in the memo would be more appropriate. Thank you

[BooneTB]

This is awesome work!!!

[Ashe-Oro]

Hi @mattsmithies - just learning about this HIP discussion for the first time today. I've recently worked with the community on HIP412, which is currently in last call.

PR: #412
Discussion: #413

I'm interested to chat with ya regarding some pros/cons of using HCS to contain some of the metadata, even in addition to linking out to an external json file.