CarbonTracker token and contract

[brioux]

This is a public discussion for the new CarbonTracker token type (id=4) and CarbonTracker contract added to the NET network see PR 379 and issue 372.

Original discussion between @sichen1234 and @brioux

@sichen1234:
Could you explain to me how the industry member and dealer roles work? I'm looking at this in the hardhat.config.js

    await contract.connect(admin).registerDealer(industry1,4);
    console.log("Account " + industry1 + " is now an industry")
    // self registered industry dealer
    await contract.connect(await ethers.getSigner(industry1)).registerIndustry(industry2);
    console.log("Account " + industry2 + " is now an industry")

Does this mean the dealers and members are of different industries?

@brioux:
I guess you are asking about REGISTERED_INDUSTRY vs. REGISTERED_INDUSTRY_DEALER?
Anyone can assign their own address as REGISTERED_INDUSTRY.
registerDealer() is restricted to admin and assigns the role REGISTERED_INDUSTRY_DEALER. At this point it only identifies that a REGISTERED_INDUSTRY that deals the new carbon token (type 4) is recognized by admin (as opposed self registered. It has all the same functionality of REGISTERED_INDUSTRY.

_@sichen1234: What are the functions of these roles -- what could an account do if they had these roles and not others?
I saw that you're registering a couple of accounts with these roles in hardhat.config.js, but when I use the react app to look up their roles, I don't see them. Do you know why?

@brioux:
I need to investigate the hardhat.config.js issue. I'll let you known what I find.
Here are some initial responses the function of these roles until I finalize documentation and examples for the new CarbonTracker token type/contract.

An Industry dealer can issue/carbon tokens, trade them with other industries or burn them. It provides a way to publicly report its scope 1/2/3 inventories. These tokens provide inputs for issuing audited emission tokens (in conjunction with the Fabric emission channel calculator/auditing). They also help track carbon removal operations across a fuel supply chain. E.g. industry carbon tokens are transferred to carbon capture/storage provider addresses connected to registered offset providers: receive carbon inputs and output offsets. Physical entities in charge of the address can be monitored to verify/re-evaluate the offsets. The industry that first issued the token can access a digital trail of the downstream scope 3 emission captured/stored by its customers.

I am reorganizing the new CarbonTracker contract to formalize connections between the different token types. Also how different tokens are combined to create NFTs describing embedded carbon emission/intensity data for products.services. Tying this into the supply chain discussion we had today: a Carbon Tracker NFT offers a seed to issue audited emission certificates for airline passengers, international shipping companies, etc... Organizations could exchange ownership of the carbon tracker NFT for the right to issue certificates...

[sichen1234]

So could only an account with one of these roles issue or receive the Carbon Tracker token? That was how it was set up before: only the emission auditor can issue audited emissions tokens, and only the offset dealer can issue offsets tokens.

[brioux]

Yes exactly.

However, the role can be registered voluntarily (by own address) or by any other registered dealer _onlyDealer().

• Carbon tracker is voluntary, so anyone should be able to issue it.
• It does not hold explicit value on its own, however audited emission reports (i.e. CarbonTracker contract NFTs) that reference these (and other tokens) may carry value as they help identify an industries carbon impact across a supply chain.

Note CarbonTracker tokens can only be transferred with both send/receiver approval. This is achieved with the following functions:

• getTransferHash(): receiver calculates hash of requested transfer, signs it offline, and sends the signature to sender for processing.
• verifySignature(): when sender submits transfer contract verifies that the supplied signature of the receiver is valid.

[brioux]

See PR 387 introducing updates and additional documentation.