Use CarbonTracker to calculate emissions from natural gas use

[sichen1234]

Currently we are calculating natural gas use emissions from standard emissions factors.

In this task, we'll use the CarbonTracker to calculate emissions from a natural gas utility. For example, Sempra Energy's 2021 Sustainability Report shows:

1. Scope 1 emissions = 4.8 + 2 + .05 = 5.05 MMT CO2e (page 50)
2. Scope 2 emissions = 0.376 MMT CO2e (page 52)
3. Scope 3 emissions = 66.2 MMT CO2e (page 52)

According to Sempra Energy's 2021 Statistical Report, they have several divisions:

1. SDGE - Total electricity 17,214 million KWH. Total natural gas 84 billion cubic feet
2. SoCalGas - Total natural gas 882 billion cubic feet
3. Sempra Texas - Total electricity 135,057 million KWH
4. Sempra Infrastructure - Total electricity 3,382 million KWH. Total natural gas 3 billion cubic feet.

So the total is 155,653 million KWH of electricity and 969 billion cubic feet of natural gas.

Could we use these statistics to create a CarbonTracker to transfer their emissions to a customer account based on usage.

[brioux]

@sichen1234 Yes. The only question I have is how emissions would be distributed among Sempra's products, electricity and natural gas.

A CarbonTracker is issued unitless product tokens that determine the weighting of tracked emission tokens.

E.g., total 1000 product tokens = 300 natural gas + 700 electricity => 30% of reported emissions attributed to gas sales, 70% electricity.

Note: physical product units are stored off-chain (e.g., postgres product table). A hash can be stored on-chain for independent verification by an auditor.

[sichen1234]

I think, for a utility, burning fuel to generate electricity would be Scope 1 emission, whereas supplying natural gas to customers would be Scope 3 emissions. So the numbers for electricity and natural gas should be separated into Scope 1 and Scope 3.

Could you help me check my math here?

I updated their numbers above based on totals for all their divisions.

For electricity, the total is 155,653 million KWH, which is 155.653 million MWH. The EPA eGrid USA average emissions is 0.4113 ton CO2e/MWH electricity, so that would be 155.653 million * 0.4113 = 64 million tCO2e. This however is too large for their reported Scope 1 of 5.05 MMT CO2e.

For natural gas, 969 billion cubic feet = 27.4 billion cubic meters, or 27,400 million cubic meters. According to the UK conversion factor, natural gas has 2.02 kgCO2e/cubic meter, and 2.02 kg = 0.00202 ton. So the natural gas emissions would be 27,400 * 0.00202 = 55.35 million tCO2e. This does come close to their Scope 3 emissions.

[brioux]

@sichen1234 the order of magnitude difference between reported and calculated scope 1 may be because of differences in generation tech, assuming they use a lot of low carbon infrastructure... Have to look at their power generation stats.

[sichen1234]

OK, I think this is the answer: According to Sempra's 10k, Sempra Texas is "comprised of our equity method investments in Oncor Holdings and Sharyland Holdings"

Also, "Because Oncor Holdings and Oncor are managed independently (i.e., ring-fenced), we account for our 100% ownership interest in Oncor Holdings as an equity method investment." Though in the Sustainability Report, it does say "We indirectly own 80.25% of Oncor Electric Delivery Company LLC (Oncor), and where possible we include 100% of its ESG data."

Oncor is only a distribution company. It does not generate electricity. It should not report Scope 1 emissions for the electricity delivered to customers. It's not clear if its suppliers' emissions should be Scope 2 or 3, but most likely it's not included at all.

With Sempra Texas numbers removed, the total electricity generated from SDGE and Sempra Infrastructure would be 17,214 million + 3,382 million KWH = 20,596 million KWH = 20.596 million MWH. Scope 1 emissions of 5.05 MMT CO2e would be 5.05/20.596 = 0.245 t CO2e/MWH which is in the range of California's grid emissions, where SDGE is located.

[sichen1234]

Based on today's call:

• Issue scope 1 2 and 3 emissions tokens to an account for Sempra
• Create CarbonTracker token for the amount of electricity and natural gas
• sign it with audit
• transferProduct to transfer it to the user's account
• getTotalEmissions to get the total emissions of the tracker. Calculate your emissions as (Your product amount)/(Total product amount)*getTotalEmissions()
• Create new tracker for the next product (ie building square feet)
• transferProductToTracker to transfer it to the building, so the building has embedded emissions from natural gas

[sichen1234]

Thinking about this, I think we should make these modifications:

1. The CarbonTracker should have some additional fields:

• an amountUsed in addition to amount, to track the amount that has been used in emissions audits
• product type to record what the tracker is for, ie "natural gas"
• tracker to record the address of the seller of the product (vs trackee being the recipient)
• fromDate and thruDate to track the time period when the product was made

2. When an emissions audit is requested, we have the parameters:

• product type (ie "natural gas")
• the address of the user requesting the emissions audit
• a from address, which is the seller of the product with the CarbonTracker
• date to track the time period of the emissions audit

4. The emissions audit will then look for a CarbonTracker from the seller (tracker) to the buyer (trackee) with the same product type (ie "natural gas") and date range
5. Emissions will use the CarbonTracker to calculate the emissions for the user (buyer/trackee), and then it will

• record the trackerId as part of the metadata of the emissions audit token
• update the CarbonTracker's amountUsed to record how much has been used
• If the amount of product used for the emissions audit is greater than the amount available on CarbonTracker (which would be amount - amountUsed) then the amount of the CarbonTracker used will be min(emissions audit amount, CarbonTracker.amount - amountUsed)

[brioux]

@sichen1234 thanks for the suggestions

I am taking these into consideration as I finalize the integration of the tracker with of the methane react-app.

[brioux]

@sichen1234 With regards to the above, several of these are already covered by the contract

1. The CarbonTracker should have some additional fields:

• an amountUsed in addition to amount, to track the amount that has been used in emissions audits

This is achieved through the ProductDetails available
attribute. amountUsed = amount issued - available

• product type to record what the tracker is for, ie "natural gas"

Can be set using ProductDetails name attribute

• tracker to record the address of the seller of the product (vs trackee being the recipient)

Each tracker is owned by the address that can sell its. ownerOf(uint256 tokenId) in ERC721 reveals this address.
The question is who should the owner if an audited token be? Whoever is paying the auditors? The owner could be an investor or the producer...
Note: trackee refers to the industry being audited. The buyer can become a new trackee to continue tracking addition processing of the products purchased.

• fromDate and thruDate to track the time period when the product was made

See from/thru date in TrackerDetails. This provides the aggregate period covering all the emissions and products covered by the tracker. This should account for the intersection of from thru-dates of all emissions associated with a tracker (min fromdate / max thrudate). A require statement could be added to tracker before it is marked released as audited.

I will consider extending from/thru dates to each product detail, similar to NET. This can be done when revising the CarbonTracker contract from ERC721 to ERC1155 to better handle product tokens...

With regards to the remaining comments. I am working through the following forms and services to initialize a carbon tracker, request emission audits and product tokens.

1. The owner (seller) creates a blank tracker token for a trackee (the organization being audited). Pays an initial fee to the network initiate the emission performance certificate request (tracker token).
2. The owner (or tracker affiliates, e.g., data providers, the trackee, ...) submit emission audit requests referencing the trackerId.
3. Auditors approve/reject. The issuing the request will both create the token and add it to the tracker contract address and link it to the tracker Id. We can include the trackerId in the metadata, but this is redundant as the tracker reference each NET token by design.
4. The owner submits request to audit product data linked to TrackerID (using the Product table)
5. An auditor issues product tokens (with weights on the distribution of emissions if there are multiple products).

With regards to amountUsed, the owner transfers products to buyer until available UINT is zero.
The tracker token id tells the buyer the embodied (indirect) NETs associated with the product purchased (still held by the tracker contract address).

These can be passed explicitly to the buyer, or kept within the tracker contract if the products are used as inputs into another tracker (a new industrial process).

The existing audit-request for natural gas activity can be used to issue new NET (direct emissions from combustion) either to the buyer's address or buyer's new tracker Id.

[sichen1234]

Hi @brioux:

1. Yes, we can use the ProductDetail.amount - available to track the amount used. It seems you're thinking of amount as the original producer's (natural gas producer) total amount of output (MMCF or Boe). I'm thinking of it as a user (building owner) using the token to calculate their emissions.
2. I think ProductDetails.name can be used as a product type, but it could become ambiguous. People may want to use name for something more specific about their product.
3. The owner should always be the recipient of the emissions audit, to keep things consistent. So the owner would go from gas producer to gas utility to building owner as different CarbonTrackers are issued along the supply chain.

[sichen1234]

Hello @brioux about this one:
The issuing the request will both create the token and add it to the tracker contract address and link it to the tracker Id. We can include the trackerId in the metadata, but this is redundant as the tracker reference each NET token by design.

I think there are 2 different use cases:

1. A carbon tracker is issued from an audited emissions certificate. This is when a carbon tracker is issued to a producer (oil & gas producer, commercial building), so the carbon tracker should have a note of the audited emissions certificate.
2. A carbon tracker is used to issue an audited emissions certificate for a consumer (natural gas utility, building tenant). In this case, the audited emissions certificate issued to the consumer should have a link back to the carbon tracker.

[brioux]

@sichen, first response to your questions from last week. -

Regarding the User vs. Producer product amounts.
Their are two different entities for tracking products:

• ProductDetails amount stored within the tracker. static a record of the product linked to a group of emissions. Available records how much is left to send to consumers.
• productBalance[][] mapping product id and user address to amount of token owned. This still needs to be updated using the ERC1155 multi token standard.

• The available balance attribute also be dropped by just allocating the total amount of product assigned to the tacker to productBalance[][] owned by the contract address. Only the owner of the audited carbon tracker token can use this balance.

Can add a product type attribute to productDetails for clear specification. makes sense to add metadata and manifest fields, similar to how emission tokens are issued for additional public facing specs. from and thru dates may also be beneficial, currently only specified by the CarbonTrackerDetails struct.

Ok, for consistency CarbonTracker will always be released to trackee (the recipient) if it is requested by a Third Party.

[brioux]

@sichen1234
Regarding the second use case, emissions issued from a carbon tracker :
consumers receive products issued to an audited carbon tracker. They tell the consumer exactly how many embodied emissions went into making the product. The embodied emissions could be released to the buyer, however

1. it is not necessary, the product is itself an expression of embodied emissions
2. there is (a minor) issue in handling fractional embodied emissions

If the product leads to additional emissions (e.g. a fuel) it makes sense for the corresponding carbon tracker to be linked to the new emissions tokens.

[brioux]

There are two ways to do this.

1. In the transaction where emissions are derived from an existing product, both are used as inputs to a new carbon tracker, linking them to the source tracker ...
2. The emissions are issued standalone to a consumer. In this case the CarbonTracker contract address and the product Id need to be referenced in the the NET metadata.

[brioux]

In the second case custom instructions are needed to track emissions to the previous contract. I.e., standardize protocol for reading the carbon tracker address and product Ids from the NET metadata

[sichen1234]

Thinking about this, I think we should make these modifications:

1. The CarbonTracker should have some additional fields:

• an amountUsed in addition to amount, to track the amount that has been used in emissions audits -> CarbonTracker is just an NFT tracking the amount of product, so no need to track amounts in it.
• product type to record what the tracker is for, ie "natural gas" --> use Product.name for now. A CarbonTracker could cover multiple products, ie natural gas, electricity, something else, so name/type should not be on CarbonTracker.
• tracker to record the address of the seller of the product (vs trackee being the recipient) --> trackee is already Sempra, there is no separate recipient (ie building here)
• fromDate and thruDate to track the time period when the product was made -> emissions audits have fromDate and thruDate but it's not needed.

2. When an emissions audit is requested, we have the parameters:

• product type (ie "natural gas")
• the address of the user requesting the emissions audit
• a from address, which is the seller of the product with the CarbonTracker
• date to track the time period of the emissions audit

4. The emissions audit will then look for a Product using the productBalance, which maps productIds transferred to each address, for example how much electricity and natural gas to the building or how much leasable square footage to the tenant.
5. Emissions will use the CarbonTracker to calculate the emissions for the user (buyer/trackee), and then it will

• record the productId as part of the metadata of the emissions audit token
• If the amount of product used for the emissions audit is greater than the amount available from Product, then use the Product's emission factor to calculate the emissions for the Product.amount and then use a standard emissions factor for the (amount - Product.amount)

6. After using the Product, then Product.available is reduced by the amount of the Product used.

See today's peer programming call

[sichen1234]

We did it! See this Monday's peer programming call.