The Hyperledger Climate Action & Accounting SIG has been establishing different working groups to lay out open source development opportunities in the climate and energy space. From several sessions in the Carbon Accounting and Certification WG, the idea of a multi-channel data architecture was presented. This was then extended as a paradigm for interoperability of applications that must interact in a common business process flow, which may apply to supply chains, or specific business process flows like a solar financing and deployment process.
High level Idea design
This section describes the generic framework proposed, whilst the next page dives into a concrete business use case .
High-level representation of a common trust layer allowing for interoperability of application.
Business process flows: These are the commons steps in a business process, or supply chain process. In the solar project finance example page, these are Identify a project, Originate a project, Raise the Funds, Build the project, and Run the project. The application environment is specifically aligned with the processes since they provide services across
Governance Framework: This pertains to the Governance Frameworks in common Trust Over Ipstacks.
DIDs and Agent Credentials: Common ID layer and verifiable credential layer that determined who is who in the common network, and what data can be shared between each agent. Tools for this are provided from Hyperledger Indy (DID) and Hyperledger Aries (Agent Credentials).
Common DLT Data Layer: This can be a permissioned ledger that stores data from the network that applications can use for their specific services across the business process flow, granted that they have access from the other applications and the underlying agentes (eg. the user). Such a layer can use Hyperledger Fabric.
Business Protocols and Taxonomies: The common language use by the business process flows can be understood as a shared taxonomy, which defines common schemas and methods. This is business specific.
Client Layer: This layer is a common entry point for every application in the network, it makes it easy for applications to interact with the network and even integrate their own set of network solutions, since application may be leveraging tools from other DLT environments.
Application Environment: These are the actual applications and platform of applications using the network and providing different concrete services to the end-user for their processes. Applications in this model can be proprietary or open source, but require using the open source network to establish the trusted interactions across them.
Hyperledger Supply Chain SIG: May be interested in the high-level trust and data network layer architecture proposed here so as to leverage for concrete supply chain applications such as Applications involved in emissions accounting across commodity supply chains. Can provide knowledge of other app interoperability approaches explored previously
Hyperledger Capital Markets SIG: Since the concrete application of the first instance of this common business application network is one of securitized solar financing (see next page), involving public offerings of equity or debt on solar project finance, this may be of direct interest to the CMSIG. For example, Raise Green is a Finra-approved regulation crowd-investment portal, while the OpenSolar project is an open source platform for contractual automation in securitized solar.
TOIP Foundation: Communities and working groups at TOIP, representing Indy, Aries and other toolsets can help provide technical guidance on the 'Open Business Application Network' proposed above, and contribute concrete code, tools and efforts in performing a proof-of-concept for the solar financing App Interoperability use-case.
Web3 Labs: As a core member of the CA2SIG working groups, Web3 has been working on the client layer of the proposed network stack given their strength in ledger interoperability and web3 protocols.
OpenTaps SEAS project of Open Source Strategies: As the chair of the CA2SIG carbon certification working group, Open Source Strategies also has created a concrete application to manage electricity data through Utility API and using green button taxonomy, and has integrated with HL Fabric to establish common data channels
OpenSolar project: Incubated at Yale and MIT, the open solar platform uses DLTs to automate payment contracts for financing solar, and can be used as one of the interoperable applications to try in a solar financing use-case.
Raise Green'sOriginator Engine: Raise Green is a finra portal in the regulated solar finance space, and the Originator Engine allows common citizens to kickoff project, so the engine would be one key application to use for an interoperability use-case. RG is also part of the Orange Button taxonomy working group so they are very familiar with the standard and could connect many other applications in the space
Add your group and organization here, and how you can contribute >
Collective Contribution Opportunity
If you are part of the organizations above, review this documentation and identify how you can best contribute your skills. Reach out to Martin Wainstein or Si Chen for any questions.
Provide feedback on the high level architecture, and the viability of the use case prompt (next page) in order to have common goal and directions. Provide documentation of where your contributions can best support the project.
See the tasks for the Collabathon in the document below:
Emission & Solar Network Use-Case and MVP
In order to work on a concrete use-case for the trust and interoperability layer, we propose extending the initial work on a Net emissions data channel, and using a securitized solar financing process flow since this already has a common data standard and taxonomy called Orange Button. See breakdown of steps in next page