UNDP Carbon Registry is based on service oriented architecture (SOA) with the right players behind it > It's not enough but nevertheless it's a very good steps in case of thie open source bricks.
ABOUT
Governance and Support
The United Nations Development Program (UNDP) is responsible for managing the application.
- To ensure alignment with international demand, Digital For Climate (D4C) will act as an advisory body to the Digital Public Good Carbon Registry codebase.
- D4C is a collaboration between
- European Bank for Reconstruction and Development (EBRD),
- United Nations Development Program (UNDP),
- United Nations Framework Convention on Climate Change (UNFCCC),
- International Emissions Trading Association (IETA),
- European Space Agency (ESA), and
- World Bank Group
- that aims to coordinate respective workflows and create a modular and interoperable end-to-end digital ecosystem for the carbon market.
* The overarching goal is to support a transparent, high integrity global carbon market that can channel capital for impactful climate action and low-carbon development.
This code is managed by United Nations Development Programme as custodian,
. For technical questions, please visit the community of practice ‘Keeping Track of the Paris Agreement’ or submit through the open forum. For any other questions, contact us at digital4planet@undp.org.
Following diagram visualize the basic components in the system.
The blockchain ( ledger part ) above> implicated the right players
Proposed actions due to the context
Gabriel to analyse and propose UX on a FIGMA cinematic
- Why such a sprint ? because
- I meet the African BAOD Bank the 24
- and the 5 of june Ingrid and thomas move to Bakou '( COP29 with top management of the cocming 11 nov Events )
- and could present to selected personn your green card simulator and …. the subject étant la finance du climat et donc des credit carbon
Initial proposed steps
Big consistent works done by United nation and publish on a open soure way with a GIthub ( source : https://github.com/undp/carbon-registry?tab=readme-ov-file )
here a proposed action for being able to PUBLISH on the GREENCARD SmartPhone and Desktop UX the PROPOSED CO2 Saving due to DATA published by NATURE BASED projector other ( renewable ) PROJECTS OWNERS
1- Project Design Document (PDD) Template
- Purpose: Describe the carbon project, methodologies, scope, boundaries, and anticipated emission reductions.
- Key Sections:
- Project Title, Developer, and Location
- Baseline and Monitoring Methodologies
- Emission Reductions Estimates
- Stakeholder Consultations
- Environmental Impact Assessment
2- Validation Report Template
- Purpose: Confirm that the project's design aligns with approved methodologies and eligibility criteria.
- Key Sections:
- Project Summary and Validation Scope
- Eligibility and Methodology Validation
- Stakeholder Input and Project Compliance
- Recommendations for Validation
3- Monitoring Report Template
- Purpose: Outline the monitoring process and document emission reduction achievements.
- Key Sections:
- Project Monitoring Period
- Data Collection and Monitoring Methods
- Calculated Emission Reductions
- Quality Assurance and Control Measures
- Issues and Recommendations
4- Emission Reduction Certificate Issuance Form
- Purpose: Certify the issuance of verified carbon credits after a successful verification audit.
- Key Sections:
- Project Identification and Developer
- Verification Body and Period
- Quantity of Issued Credits
- Unique Serial Number(s)
5- Carbon Credit Transfer Agreement Template
- Purpose: Facilitate the transfer or sale of carbon credits between parties.
- Key Sections:
- Parties Involved and Responsibilities
- Quantity and Type of Carbon Credits Transferred
- Payment Terms and Conditions
- Warranty of Ownership and Legal Compliance
- Dispute Resolution Mechanism
6- Project Verification Agreement Template
- Purpose: Detail the relationship between the project developer and the third-party verifier.
- Key Sections:
- Scope of Work and Verification Period
- Responsibilities of Developer and Verifier
- Terms of Engagement and Fees
- Verification Standards and Criteria
- Confidentiality and Data Handling
- Key Sections:
These templates should have placeholders for signatures and be customizable for each project's specifics while remaining standardized for transparent record-keeping. They can be signed digitally or physically based on the regulatory guidelines of the National Carbon Credit Registry.
Some technical modules describes within this Github
Habitat Model
Authenticate, Validate and Accept user (Government, Project Developer/Certifier) API requests related to the following functionalities,
- User and company CRUD operations.
- User authentication.
- Project life cycle management.
- Credit life cycle management.
Service is horizontally scalable and state maintained in the following locations,
- File storage.
- Operational Database.
- Ledger Database.
Uses the Carbon Credit Calculator and Serial Number Generator node modules to estimate the project carbon credit amount and issue a serial number. Uses Ledger interface to persist project and credit life cycles.
Analytics Service
Serve all the system analytics. Generate all the statistics using the operational database. Horizontally scalable.
Replicator Service
Learn how to use organic gardening methods to grow the freshest food in your fruit and vegetable garden.
ABOUT US
Deployment
System services can deploy in 2 ways.
- As a Container - Each service boundary containerized in to a docker container and can deploy on any container orchestration service. Please refer Docker Compose file
- As a Function - Each service boundary packaged as a function (Serverless) and host on any Function As A Service (FaaS) stack. Please refer Serverless configuration file
External Service Providers
External Service Providers
All the external services access through a generic interface. It will decouple the system implementation from the external services and enable extendability to multiple services.
Geo Location Service
Currently implemented for 2 options.
- File based approach. User has to manually add the regions with the geo coordinates. Sample File. To apply new file changes, replicator service needs to restart.
- Mapbox. Dynamically query geo coordinates from the Mapbox API.
Can add more options by implementing location interface
Change by environment variable LOCATION_SERVICE. Supported types MAPBOX, FILE(Default)
File Service
Habitats with a minimum footprint on the planet and a maximum positive impact on the local community.
.
.
Database Architecture
Primary/secondary database architecture used to store carbon project and account balances. Ledger database is the primary database. Add/update projects and update account balances in a single transaction. Currently implemented only for AWS QLDB
Operational Database is the secondary database. Eventually replicated to this from primary database via data stream. Implemented based on PostgresSQL
Why Two Database Approach?
- Cost and Query capabilities - Ledger database (blockchain) read capabilities can be limited and costly. To support rich statistics and minimize the cost, data is replicated in to a cheap query database.
- Disaster recovery
- Scalability - Primary/secondary database architecture is scalable since additional secondary databases can be added as needed to handle more read operations.
Why Ledger Database?
- Immutable and Transparent - Track and maintain a sequenced history of every carbon project and credit change.
- Data Integrity (Cryptographic verification by third party).
- Reconcile carbon credits and company account balance.
Ledger Database Interface
This enables the capability to add any blockchain or ledger database support to the carbon registry without functionality module changes. Currently implemented for PostgresSQL and AWS QLDB.
PostgresSQL Ledger Implementation storage all the carbon project and credit events in a separate event database with the sequence number. Support all the ledger functionalities except immutability.
Single database approach used for user and company management.
Ledger Layout
Carbon Registry contains 3 ledger tables.
- Project ledger - Contains all the project and credit transactions.
- Company Account Ledger (Credit) - Contains company accounts credit transactions.
- Country Account Ledger (Credit) - Contains country credit transactions.
The below diagram demonstrates the the ledger behavior of project create, authorise, issue and transfer processes. Blue color document icon denotes a single data block in a ledger.
Authentication
- JWT Authentication - All endpoints based on role permissions.
- API Key Authentication - MRV System connectivity.
Lifecycle
Actors
key point for gabriel / Vilhelm to match the green card project data model and those datamodel > For API connexion or inspiration
Under Field for
* companies
+
+
Projects > key point for gabriel / Vilhelm to match the green card project data model and those datamodel > For API connexion or inspiration
+
source : https://github.com/undp/carbon-registry?tab=readme-ov-file