Key Points

References

EBC Project Overview 

Industry, Project Name, Organization Name, Description and scope.

Energy Blockchain Consortium

Industry: energy management

Project: EBC - energy management

Peer to Peer energy trading app MVP

• clients can bid, offer and trade energy from residential solar systems over Grid network
• modern trade desk shows bid, offers dynamically to track current market trends visually, manage bids, offers, accept trades
• on ReactJS, NodeJS microservices, Hyperledger Fabric Blockchain and MongoDB

Retail Carbon Management app MVP

• Certified carbon offset provider projects can register on the platform to sell carbon offsets
• Buyers can be retail consumers or businesses trying to offset their carbon footprint
• Carbon calculator and profile show accounts what their net carbon profile is 
• Online e-commerce app allows purchasing carbon offsets and other products using payment provider services ( Stripe etc )
• Site designed for multi-currency, testimonials, FAQS, customer blogs
• Integrates Wordpress and plugins as a "headless CMS"
• on ReactJS, NodeJS microservices, Hyperledger Fabric Blockchain, MongoDB and Swift for iPhone

Dev Trading app

https://ebc-dev.sysopsnetwork.com/trade

Fabric Environment v2.2 

https://hyperledger-fabric.readthedocs.io/en/release-2.2/

Fabric Node SDK docs

https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.html

Environments 

EBC github

Git vs Github Desktop

EBC DEV environment sites

EBC QA environment sites

EBC One_app demo now

Check Mongo in DEV 

accounts

{"userName": {$in: ["jeff","jody","tim","jim"]}}

jobQ 

{ "createdAt": {$gte: ISODate('04-12-2021')}}

Check API server in dev

https://ebc-api-dev.sysopsnetwork.com

Check Fabric in dev 

couchdb
http://3.21.101.182:5984/_utils/
admin / adminpw

explorer
http://3.21.101.182:8080/#/

exploreradmin
exploreradminpw

Load, run One_app front-end code locally from one_app branch

old EBC MVP running in dev, qa 

To run current one_app:

download latest one_app from github in ebc-frontend folder 

npm install 

npm start 

in Chrome: 
http://localhost:3000/device

old dev frontend

https://ebc-dev.sysopsnetwork.com/trade

Key Concepts

this url works now - direct call to the active AWS zone
http://ebc-frontend-dev.s3-website.us-east-2.amazonaws.com/

Run apps on Local system

NODE_ENV=devLocal port=3030 npm #dev

Feathers queries on GET requests 

https://ebc-api-dev.sysopsnetwork.com/bids?accountId[$ne]=6008f9791404d97cb59bd982&$limit=10&$skip=0

add a starting date query for bids

{{base_url}}/bids/?accountId[$ne]=6008f9791404d97cb59bd982&status=open&createdAt[$gte]=2021-02-22

Key Env Tasks

remote

aws

mongo / mongoose

github

feathers

hlf v2.2 - GO

React / Redux

local or my aws

ubuntu

mysql or mongo / mongoose

git

feathers

hlf v2.2

hlf v2.2 asset xfer samples tests

Key Engineering Tasks 

--------------------------------------------
a>> create a production design doc in gdocs
--------------------------------------------

non-functional production requirements

1. The 12 SWT solution themes
2. 12 Factor app model for services solutions
3. OWASP 10 factor security considerations - data in-flight, at-rest, in-process
4. identity methods supported - userId-pwd, digital identities for people?
5. device ids, credentials with expirations
6. digital id, crypto recovery models for accounts, devices
7. KMS - key management system - KeyChain software eos ?
8. handling key rotations for transactions and queries over time
9. additional design, test and user documentation
10. support for multiple microservices in feathers or other frameworks
11. support for functional authorization by role
12. support for data authorization by role
13. consider automated testing options for API, database, Fabric, UI
14. feathers support for microservices, authorization models, external service integration, extended models based on views with edit rules
15. configuration support by environment
16. real-time screen updates for selected elements using web sockets
17. consider UI options for Web, Mobile interfaces
18. persistent messaging services as an option to replace the database transaction tables based on performance tests ( Mongo tables or Kafka ?? )
19. rethink what is stored on the ledger
20. consider a logical global transaction id linking database and ledger updates ( like the last TXID ) now
21. consider IoT integration services ( Nodered or Kafka or MQTT or ?? ) for solar smart controllers
22. review IoT device integration standards for solar controllers and test with Elcrow PI
23. define analytics module for the home owner, for the grid operator showing consumption and production trends, purchases etc
24. consider the automated trader feature based on policies
25. consider the trade planner feature
26. user accounts need policies
27. integrate device data to the user account system
28. evaluate a rules framework for feathers or ?
29. consider Grails for master table maintenance
30. decide on Mongo vs MySQL for JSON data
31. review CICD pipeline and related tests
32. consider better automated management of crypto artifacts in Fabric and usage by the application for signed transactions etc
33. consider better event pub sub services model for streaming events

Key Design Tasks

WP headless CMS

Object Context

Use Case Scenarios

RDD Features

Data Models

Payments with Stripe

Object Context

Use Case Scenarios

RDD Features

Data Models

Account Management

Object Context

Use Case Scenarios

RDD Features

Data Models

Product Management

Object Context

Use Case Scenarios

RDD Features

Data Models

Order Processing

Object Context

Use Case Scenarios

RDD Features

Data Models

Sales Analysis by Account, Product

Object Context

Use Case Scenarios

RDD Features

Data Models

CDD for Non-Functional Features

eg environment items: security, performance, RAS, RTO, RPO, onboarding, authn, authz

Blockchain Concepts

Object Context

Use Case Scenarios

RDD Features

Data Models

Key Dev Tasks

test nsf-api - feathers.js
https://github.com/Paramount-Software-Solutions/nsf-api

data model ok
generate domain classes from jdbc metadata - fields, fk refs
default relation = hasMany
change as needed to belongsTo hasOne

grails ....
create app
create domain classes - gen edit
create controllers
create views

hlf v2.2 nodejs example

Key Test Tasks

Test info

Base URL  

https://nsf-api.sysopsnetwork.com/

Documenter

https://documenter.getpostman.com/view/5352743/SzS1SoR6?version=latest

Postman NSF API setup

Export an existing NSF collection library

Import the library and select run in Postman button

Duplicate the collection and edit the duplicate

setup environment variables to use in URLS and body clauses


In Postman, 

http://{{rhost}}:3030/accounts

use url without port to allow server proxy redirection
http://nsf-api.sysopsnetwork.com/accounts

postman quick reference guide

pm.environment.get("rhost") in a script

Postman Testing NSF REST api

----------------------------------------
NSF API - create new user in dev in postman
----------------------------------------

sequence ...

*** ensure correct url == https:// and host 

		nsf-api.sysopsnetwork.com

---------------
1> create a new user 

auth = no auth

https://{{rhost}}/accounts

{
  "firstName": "Jim",
  "lastName": "Mason",
  "email": "jmason900@yahoo.com",
  "password": "Skyler@00"
}

<< sends a verification email with a custom verification token



---------------
2> verify user token 

auth = no auth

https://{{rhost}}/authManagement

{
	"action": "verifySignupLong",
	"value":"1b6cb27b711d01a0396baaccc8108b"
}

>> substitute correct token from the verification email



---------------
3> authenticate user ( login )

auth = no auth

https://{{rhost}}/authentication

<< returns a Bearer token for the session

use test script to set the token for the environment

pm.environment.set("jwt", response.accessToken)


---------------
4> after login, run all methods with the Bearer token variable from the environment 

auth = Bearer token




----------------------------------------
verification url fails 
----------------------------------------

https://nsf.sysopsnetwork.com/verify?token=1b6cb27b711d01a0396baaccc8108b

Problems with UN SDG s and SDG18

https://sdgs.un.org/goals

The goals are clearly intentionally poorly defined which logically reduces the opportunity for both consensus and action

Each group believes its interpretation of the goals is the correct one leading to division not consensus

SDG18 is implied - Population growth is a high goal

In a world the other 17 goals are all negatively impacted by population growth and there is no goal to limit the population growth, then SDG18 can be assumed as implicit support for population growth. All the actions on the other 17 also encourage population growth. The behavior of governments and NGOs and many corporations is that population growth must be valuable and good even though none of them directly express that goal.

Potential Value Opportunities

pilot = 2 yrs
prod at national grid after = 2 yrs

3 big goals
- virtualize smeter p2p trading service for nat grid
- create hw package w meters, etc and software for nat grid low income
- other utilities

a> email w docs

a> pilot features, estimates ???
what does a production pilot cost ???

a> how can a smart meter be virtualized here ???
how can we partner w existing energy services companies ???

a> how to package smart meter service to other utilities ???
David King has other energy marketing leads .. Frank

a> see enerblock web site slides

a> new slides on ...
1> dual inverter architecture
2> virtual smart meter

nsf.report>

gsearch - bc poc report
see JIRA, HLR, BOA, bcp folder
diagrams for
use cases
bpm data flows

EBC MVP report model
https://www.hyperledger.org/wp-content/uploads/2019/11/HL_SolutionsBrief_ReduceCost_V8.pdf

overview

poc goals, value add
poc reqmts map to HLR use cases register user account, create assets, load transactions,
poc environment
poc development
poc testings & findings
poc summary
production architecture
production features
next steps

Candidate Production Requirements

production requirements are driven by functional and non-functional requirements supplied by EBC.

Candidate requirements include:

1. The 12 SWT solution themes
2. 12 Factor app model for services solutions
3. OWASP 10 factor security considerations - data in-flight, at-rest, in-process
4. identity methods supported - userId-pwd, digital identities for people?
5. device ids, credentials with expirations
6. digital id, crypto recovery models for accounts, devices
7. KMS - key management system
8. handling key rotations for transactions and queries over time
9. additional design, test and user documentation
10. support for multiple microservices in feathers or other frameworks
11. support for functional authorization by role
12. support for data authorization by role
13. consider automated testing options for API, database, Fabric, UI
14. feathers support for microservices, authorization models, external service integration, extended models based on views with edit rules
15. configuration support by environment 
16. real-time screen updates for selected elements using web sockets 
17. consider UI options for Web, Mobile interfaces
18. persistent messaging services as an option to replace the database transaction tables based on performance tests ( Mongo tables or Kafka ?? )
19. rethink what is stored on the ledger
20. consider a logical global transaction id linking database and ledger updates ( like the last TXID ) now
21. consider IoT integration services ( Nodered or Kafka or MQTT or ?? ) for solar smart controllers 
22. review IoT device integration standards for solar controllers and test with Elcrow PI
23. define analytics module for the home owner, for the grid operator showing consumption and production trends, purchases etc
24. consider the automated trader feature based on policies
25. consider the trade planner feature 
26. user accounts need policies 
27. integrate device data to the user account system 
28. evaluate a rules framework for feathers or ? 
29. consider Grails for master table maintenance 
30. decide on Mongo vs MySQL for JSON data 
31. review CICD pipeline and related tests
32. consider better automated management of crypto artifacts in Fabric and usage by the application for signed transactions etc
33. consider better event pub sub services model for streaming events 
34. transaction replay support

References for Production Architecture

Design Node.js Backend architectures

https://afteracademy.com/blog/design-node-js-backend-architecture-like-a-pro

Production Design Concepts - Tony

Development Plan of Release 1.0 is coming But we’ll start with a simple framework

Let’s start with a simple framework with some mock functionality. This is work for only 1-2 weeks and does not need to be very sophisticated. Just functional.

Time Frame: One or two weeks.

Functional Overview: Create a simple framework of an application - Use the existing Version of the product we have developed, and add the following. We can use a template to reduce any design work. Focus should not be on design but just to get the functionality working. Go with the assumption that we will do a UI UX design.

More details will be provided next week (June 11)

1. Add couple of fields to registration process;
2. Create a simple data structure (in off blockchain) as “carbon inventory”. It needs only a few sample fields.
3. Add a few tabs to a user’s dashboard with a simple search function to search the carbon inventory. Show results. Create a mock report that shows where the carbon came from.
4. Let user purchase a product. Pay for it via Steller or other. Reduce inventory. Create audit trail of the transaction on Blockchain. The mock carbon report should now say that offset was bought.
5. Simple Calculator to calculate carbon offset.
6. Do 1-2 day research on an open source NFT (Cardona with PoS, Binance or other) options.

Solution Design

Step 1: Individual or Business User Registration (Do Item 15 above)

Modify the current registration process as follows:

1. Add a new field to distinguish a user or a business. Do what people are doing to register uses and businesses. IF there I sno better way then, just add a new field  called “ I am “ with possible values of “Individual” or “Business”.
2. Add a new value in the “Affiliation” field. It’s called “No Affiliation”
3. When a new user registers with  Affiliation = “No Affiliation” then we do not need to verify a user by approvers because this user has no affiliation s they are just a simple buyer. If this user needs to add his DER assets then we will deal with that use case later.
4. The registration process should send an email to person’s email for verification (This is standard internet practice and should have been implemented in first POC release but it was not). When the user clicks that email, then he/she is considered registered.
5. Give the individual user the ability to put personal information and the business user to put business information in addition to personal info.

Step 2: Carbon Offset Inventory (mock) - Create a very simple data structure in offline database to contain carbon offsets inventory.

1. Perhaps we can have5-6 simple fields: Certificate Number <Alpha numeric>, Project Name, Project Type, Date Started, End Date, Status= Active, Retired, Withdrawn and then the Units (say we start with 8), Price per Unit = $15 (say), Description.
2. Put mock data with 7-8 records with different project types.
3. Decrement the counter if the use clicks buy button in next step.

Step 3: User Dashboard (Simple Version): When the new user logs in, who is not affiliated with anyone, then he/she should see a page that has the following tabs:

1. Buy Carbon Offsets ß This is default and will provide a search options whose parameters will be provided by Tony. For now just go with a screen that provides 3 fields: Project Type,
2. Carbon Packages ß Give three packages or products $10 per month for one year, $20 per month for one year and $50 per year per month.  Don’t worry about the exact wording or amount number. Just get basic infrastructure including database access. In the first go, we can wait for tat
3. My Carbon Footprint: This is user’s calculated footprint baseline It should stay “Blank” currently.
4. Carbon Calculator: We will make this nice but more after one week.
5. <Maybe few others TBD later>
6. User goes to “Buy Carbon Offset” page, searches per some criteria that is mocked, and it spits out relevant offsets inventory. In front of each line item is a button that says traceability or chain of custody or a some more simpler word. When clicked it displays a very nice report with info relate to the asset: Like who is the project developer, when it started, etc etc. This is dynamically generated. When asset is bought it will say bought etc.

Step 4: Purchase and Pay: User clicks on one product - No matter what they buy , just go to carbon registry and decrement the item purchased and then go to payment processing:

1. Let’s add payment gateway to process this payment in US$ or local currency. Thomas was discussing the Steller network. Let’s see if we can use that. I want to make sure that we can use micro payments capability as well. 
2. Once the payment is processed, let’s keep the transaction info in the history log. Remember for Audit and Traceability purposes we will access this. 
3. Product is bought
4. It goes to user’s transaction history (my orders).
5. Reduce inventory once the transaction is successful.
6. Offsets should show a link to the transaction we just did.

Step 5: Simple Calculator to calculate carbon offset.

1. Assume that an average person has 20 MtCO2e (20 metric tonnes) as their carbon footprint in United States.
2. Add a couple of sliding widgets – like num of cars they have (0 to 5), and how often they use public transportation (0% to 100%) and use these numbers to just create some simple new calculated footprint. It does not need to be sophisticated. 

Step 6: Do research on open source White Label NFTs and how can we use that to build EBC’s NFT Marketplace.  Also do research on “Gas” fees on Ethereum network and the cost. If the cost of NFT minting is say $40 of gas fee etc, and our NFT is $10 then it makes no sense for the NFT owner to pay $40 and g $10.  Provide top 2-3 options.

Best

Tony

Potential Challenges

Improving authentication for EBC MVP applications

To meet an unrealistic MVP deadline from the client, we created 2 separate services: one for users trading, one for approvers

The plan was to only provide a Web UI for user trading, not for approver services.

Approvals of accounts and devices could be done through the database, not a Web UI.

As the client changed the requirements to add a Web UI for approvals, we made the decision to create a second Web app with a matching Web service to cut time and costs.

IF we had more time, funds, a long-term design would use a different model to support different user types and functional authorization

A plan to consolidate the existing MVP solution into a single app and integrated user database

• Consolidate the trade and approver applications into one application
• Change the trade and approver services to use a single authentication token
• Change the account and approver tables to have the SAME identity for any user that is in both tables

Production architecture is out of scope on budget, time now

• Create a new registration solution that incorporates the existing approver table functions
• Create a new authentication service that supports the added approver functions
• Extend the authorization model to support specific RBAC - role based access control - beyond the base roles of user, approver
• Extend the authorization model to support data contexts beyond the limited model in the MVP

MVP2 Challenges 

1. Client planning gaps for MVP2
   1. client disappears for 10 weeks to create a "capabilities" specification
   2. client says it will only take 2 weeks to implement because they are experts on the web technologies used
   3. client spec is not a design and has many logical, process and data gaps to be filled ( BUT "design not needed" )
   4. client thinks coding and design can start day 1 not understanding an Agile process has design before coding
2. Our team on EBC MVP2
   1. had 2 people from the prior EBC effort. One was an excellent developer.
   2. 6 new people added, only 1 from Paramount
   3. QA person can only manually test UIs, no APIs, no data analysis
   4. Documentation person didn't have significant role since design had run concurrent to development on the SAME stories
   5. 2 senior UI developers really are junior level only
   6. The new UX designer is first class
   7. HR function is weak
   8. high pressure, short-term projects are not the place to "train" new teams
3. Factory approach to software solutions missing
   1. Need open standards based platform, technology stacks
   2. Improve solution value, flexibility, portability avoiding custom cloud services in cloud environments
   3. Architect solutions as assemblies of common component services ( data services, content services, security services, visualization services, management services, IAM services, JEPL event process services, etc  )
   4. factory pays increasing dividends over time as the services stack value grows to build applications faster, flexibility with better quality over time
   5. replace large developer teams with fewer, better paid senior developers that can build factory services and deliver solutions on the factory
   6. compare Feathers, Grails, JHipster on full stack automation 
4. Carbon Offset Solution Values
   1. carbon offsets are a payment ( by carbon ton ) from a carbon emitter to a carbon reducer who reduces CO2 output elsewhere ( eg a Tree farm, Solar farm, Wind farm etc)
   2. https://en.wikipedia.org/wiki/Carbon_offset
   3. https://www.offsetguide.org/understanding-carbon-offsets/what-is-a-carbon-offset/
   4. https://www.treehugger.com/best-carbon-offset-programs-5076458
   5. terrapass sells carbon offsets retail at about $10 per ton. Retailers offer monthly subscriptions based on your carbon footprint.
5. mm
6. more

Carbon accounting concepts and solutions

carbon accounting references 

Towards Ontology and Blockchain Based Measurement, Reporting, and Verification For Climate Action - SSRN-id3717389.pdf

https://wiki.hyperledger.org/display/CASIG/Voluntary+Carbon+Offsets+Directory+Research+Project

References

• Securing Climate Benefit: A Guide to Using Carbon Offsets
• Voluntary Ecological Markets Overview by IWA - this document is really about carbon offsets despite its title.
• EDF Trends in Voluntary Carbon Offsets Market
• These Countries have Prices on Carbon.  Are they working? (NY Times)
• Taskforce for Scaling Voluntary Carbon Markets Final Report
• Microsoft Carbon Removal - Lessons from an Early Corporate Purchase
• Microsoft Criteria for high-quality carbon dioxide removal

Ratings and Criticisms of Carbon Offsets

• A buyer’s guide to soil carbon offsets - Carbon Plan

• BeZero Carbon Ratings Methodology
• The World Needs Better Climate Pledges
• Comments on the Initial Recommendations of the Taskforce on Scaling Voluntary Carbon Markets (TSVCM) from Berkeley Carbon Trading Project and affiliated groups
• Startup That Rates Carbon Offsets Finds Almost Half Fall Short
• Top Airlines’ Promises to Offset Flights Rely on Phantom Credits
• NPR Reporting on Forest Carbon Credits Gets It Wrong in 5 Ways
• Carbon Direct Commentary on Release of the Voluntary Offsets Database
• How Additional is the Clean Development Mechanism

https://wiki.hyperledger.org/display/CASIG/Governance+Research+for+Climate+Action

In a typical climate ecosystem, such as the carbon credits market or climate investing, there are these stakeholders:

• sellers or issuers
• buyers
• intermediaries - transaction services
• gatekeepers - standards organizations, ratings agencies
• other service providers - data services, consultants

https://www.climateledger.org/resources/Blockchain-for-Climate-Action-and-the-Governance-Challenge.pdf

Sample carbon accounting app model

https://github.com/opentaps/blockchain-carbon-accounting/blob/main/open-offsets-directory/README.md

The Carbon Offset Marketplace - reference model

https://www.offsetguide.org/understanding-carbon-offsets/carbon-offset-projects/offset-project-entities/

Designing, implementing and operating carbon offset projects requires the involvement of a number of parties, stakeholders and authorities. Although the parties involved differ from project to project, some general categories and types of market players can be defined as follows.

Project Owners

The operator and owner of the physical project installation where the emission reduction project takes place. An owner can be any private person, company or other organization.

Project Developers

A person or organization with the intention to develop an emission reduction project. This could be the project owner, a consultant or specialized services provider.

Project Funders

Banks, private equity firms, private investors, non-profit organizations and other organizations may lend or invest equity to fund a project. Some offset program standards have rules as to what kind of funding, aside from offset revenue, is acceptable for an offset project.

Stakeholders

Individuals and organizations that are directly or indirectly affected by the emission reduction project. Stakeholders include the parties interested in developing a specific project (e.g., owner, developer, funder), parties affected by the project (e.g., local population, host community, environmental and human rights advocates) and national and international authorities.

Third Party Auditors – Validators and Verifiers

Almost all offset programs require a third-party auditor to validate and verify a project’s baseline and its projected and achieved emission reductions. Under CDM, the auditors are called Designated Operational Entities (DOEs). To minimize conflicts of interest, the CDM does not allow the validating DOE to also conduct project verification. Most offset programs also have processes for accrediting their third party auditors before they are approved to conduct validation and verification activities.

Standards Organizations

In the absence of national or international legislation, standard organizations define a set of rules and criteria for voluntary emission reduction credits.

Brokers and Exchanges

In the offset credit wholesale market, emission offset buyers and sellers can have transactions facilitated by brokers or exchanges. Exchanges are usually preferred for frequent trades or large volumes of products with standardized contracts or products, while brokers typically arrange transactions for non-standardized products, occasional trades, and small volumes.

Traders

Professional emission reduction traders purchase and sell emission reductions by taking advantage of market price distortions and arbitrage possibilities.

Offset Providers

Offset providers act as aggregators and retailers between project developers and buyers. They provide a convenient way for consumers and businesses to access offset credits from a portfolio of projects.

Final Buyers or End-Users

Individuals and organizations purchase carbon offsets to counter-balance GHG emissions. Therefore, the final buyer has no interest in reselling the offset but will prompt the retirement of the carbon offset credit

Carbon Value of a Tree Farm

https://www.gotreequotes.com/how-much-co2-do-trees-absorb/#:~:text=The%20average%20Pine%20tree%20absorbs,or%2010%20tons%20per%20year.

How much Co2 do trees absorb?

Project Management Challenges

7/13/21  Next Steps

We have wrapped Sprint 1 new features.

We are doing minor support, fixes.

Tony wants a "next sprint" that includes:

Note to Pramod

Sprints for Carbon Mgt App

Sprint 5 Retro

retro.jim>
bad > need better coverage between stories in epics and the actual work getting done
bad > need better job on matching stories to epics every time
bad > need better job of finding the matching story list for an epic when we do customer reviews ( as Amir has been doing )
bad > need better indication of blocked items ( eg a dependency on Word press server environment etc )
bad > need better backlog grooming prior to Sprints ( Jim, Shilpa )
bad > took too long to resolve the blockchain usage model for this app ( vs trading app ) ( Tony, Jim )
good > responsive to customer in our weekly status review meetings
good > work getting done in specific instances by developers

QA environment not setup for Chain API

Frontend and api apps are setup in QA correctly

No AWS environment has been setup for the Chain API in QA

Strategy - minimum work to demo Fabric contracts 

Option 1 -  test locally to DEV environment on Chain API

create local version of ebc-v2-api that points to Mongo ebc_dev_v2 database

write account and jobQ records there

existing Chain api in DEV will process 

view results in Mongo DEV and couchDB DEV

Option 2 - create Fabric environment in QA

Option 3 - reconfigure Fabric DEV environment to be Fabric QA environment

Candidate Solutions

Carbon Offset Production Using Seaweed feed for Cows

https://www.cbsnews.com/news/seaweed-methane-emissions-cows-gas-climate-change/

Managing carbon effectively for ESG

https://www.globalcarbonesg.com/

Learn how we combine carbon sensors, IoT, and Blockchain to help you baseline and manage your carbon footprint.

IBM puts carbon certifications on blockchain

https://www.ibm.com/blogs/blockchain/2021/08/revolutionizing-renewable-energy-certificate-markets-with-tokenization/

Revolutionizing renewable energy certificate markets with tokenization.pdf

enterprises purchase Renewable Energy Certificates (REC) which represent 1MWh of zero-carbon electricity generated by another entity. The seller of REC could be outside the region or country the enterprise is from. The enterprises then use the RECs to offset their carbon footprint and be compliant with regulations on carbon emissions and green standards.

Companies are looking to newer solutions to capture, analyze and report Environmental Sustainability Goals (ESG) information and reduce their environmental impact. A decentralized and immutable blockchain network, which leverages enhanced characteristics of distributed ledger technology (DLT) can greatly increase the adoption of energy certificates and ensure consumption closely matches the generation.

cumbersome carbon accounting process becomes simplified with significant cost savings, as smart metering and automations are introduced.

 exchange of different amounts of energy and granularity of energy certificates. For example, energy certificates can be traded in smaller program time units (PTUs), such as the case of hourly certificates, becoming more in cadence with clearing and settlement

commercial-scale blue hydrogen, derived from natural gas and carbon capture and storage (CCS) and green hydrogen, produced from renewables-based electrolysis processes. This has led to surge in hydrogen project announcements working in conjunction with both the gas and renewable sectors. The energy generation using hydrogen and other mixed sources have some CO₂ emission associated and needs to be captured in the certificates.

wide variety of implementations for tokenizing energy certificates, coupled with the fact that they are often at an infancy stage, call out for defining industry standards towards interoperability between networks in different geographical regions across the globe.

self-funding ecosystems are leveraging Ethereum-based (ERC-20) solutions by introducing a dual layer of tokenization. The purpose for public platforms of supporting two layers of tokenization is to provide end-users access to use their platform and contribute to corporate revenues and create exchangeable tokens encapsulating energy certificates.

P2P energy trading

A similar system is being developed by Power Ledger. With its own unique trade matching algorithms, prosumers and consumers can transact available power equitably, without favoring any of the participants. Other characteristics of this platform include pegging of native tokens to a local unit of currency and aggregation of individual meters in a single transaction. The trading group can be configured by either their application host or Power Ledger. WePower also offers an alternative solution on exchanging energy certificates via its native WPR token and auctions. WePower launched a financial derivative product, called Contract for Difference, to mitigate risk in corporate power purchasing agreements (PPAs).

ESG reporting on carbon

As organizations are by now committed to contribute to the Sustainable Development Goals (SDG), there is a need for an elegant solution which enables them to calculate carbon footprint and assist in creating their ESG reporting.

Tokenize energy certificates and reporting

solution (enerT) to tokenize energy certificates using Hyperledger Fabric and Tokens-SDK. Tokenization of energy certificates in a DLT platform can offer an intelligent solution with regards to full disclosure certification of energy. In addition to the amount of energy generated by mixed sources, tokens created in the network could also store other useful characteristic such as CO₂ emissions in the energy supply chain.

A tokenized energy marketplace would offer a wide range of trusted certificates in terms of energy types and origin. Such a network would allow suppliers and consumers to trade energy certificates efficiently and inexpensively. A tokenized certification unit would be like what the container did for the shipping industry.

Google Maps GPS API

https://help.parsehub.com/hc/en-us/articles/226061627-Scrape-latitude-and-longitude-data-from-a-Google-Maps-link

https://www.businessinsider.com/how-to-find-coordinates-on-google-maps

Currency Codes and Conversion Rates

currencyCodes

currencyConversionRates

https://www.federalreserve.gov/datadownload/Choose.aspx?rel=H10

https://www.bis.org/statistics/xrusd.htm

http://www.portfolioslicer.com/data/file-currency-conversion.html

Meetings

EBC DER trading POC schedule 

Jan 5 accounts app works
demo accounts to database again
demo account, device from script to ledger
a> need to move front-end logic to feathers client

Jan 7 approver app works
issue> write account from api to ledger
a> new cd pipeline for approver app

Jan 11 devices in app works
device approvals work

Jan 14 write accounts, devices from api to ledger
a> api wrapper service for ledger accounts, devices
a> demo transactionID on mongo and from Explorer on ledger
i> individual keys for accounts, devices not included now

end Sprint 1

Jan 14 Sprint 2 begins
energy load demo ( Jim )
a> add menu option, api call to load function
Sprint 2 demo

Jan 18 Sprint 3 - offers
review offers UI, api
- create, edit, cancel offer
i> do we need the 19th for this review ??

Jan 25 Sprint 4 - bids
review bids UI, api
- create, edit, cancel bid
i> do we need the 26th for this review ??

Jan 26 Sprint 5 - trades begins
membership certs for accounts

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles