Managed Guardian Service Beta v2 Release
New features in the Beta v2 Release include enhanced tenant and user administration, complete asset lifecycles, including asset retirement, and much more.
We are pleased to announce the Managed Guardian Service Beta v2 most recent release. It’s now easier for companies and organizations to establish and track their carbon assets thanks to several new features and enhancements included in this release. Onboard now during the free beta period here: https://guardianservice.io/
Update to Guardian v2.8
The upgrade to Guardian v2.8 is one of the Beta v2 release’s biggest upgrades. This updated version features a retirement procedure, third-party content providers, and matching assets, (among many other upgrades). In the voluntary carbon market sector, where the development, monitoring, and administration of carbon assets are essential these features are particularly significant.
Retirement Process
The Guardian solution has now completed the whole lifecycle of an ESG asset, making the retirement process a significant milestone. Consider a toy box filled with a variety of toy vehicles and blocks. Each toy vehicle and building block is a representation of an ESG asset, such as Core Carbon Principals, Carbon Removal Units, or Carbon Emission Tokens. These assets also have a life cycle, just like in real life; they are created and eventually retire. Now, the toy box follows a set of guidelines known as the “creation process” to ensure that each new toy vehicle or toy block is manufactured correctly. However, a toy car or block must be retired when it is no longer used. The “retirement process” is a set of guidelines that instructs the toy box on how to properly retire the toy vehicle or toy block, just like the “creation process.”
This means that the toy box can store the toy vehicle or toy block in a specific location called “retirement” so that it is no longer needed and that will no longer be used. Making sure that the toy box can appropriately retire the toy cars and toy blocks while adhering to the same set of guidelines as the “creation process” is the goal of this problem.
We must thus make certain adjustments to correct the issue by correctly retiring the toy cars and toy blocks. To properly retire the toy cars and toy blocks from the toy box, we must first add new rules to the existing “policy.” These new rules referred to as a “retirement process,” will be just as significant as the rules governing the “creation process.” We will also add some more assistance to the toy box, referred to as “smart contract functionality,” that verifies and ensures that the toy cars and toy blocks are retiring correctly in order to ensure that the toy box complies with these new rules.
To resolve the issue, we will add clauses defining rules for retirement to the “policy” description language and implement smart contract functionality to enforce these clauses, ensuring that the toy box correctly retires the toy cars and toy blocks.
Matched Assets
If users so choose, they can quickly and simply link carbon assets to their respective assets using the Matched Assets function, which makes it simpler to maintain track of one’s assets. If you have a toy box full of various toy vehicles, you can easily visualize linked assets. Each toy vehicle is a token. The same toy car manufacturer produced some toys that share a similar appearance but may have distinct colors or shapes. Some toy cars were produced by various toy car manufacturers, and they may have completely distinct appearances. Now, some of these toy vehicles can cooperate because their characteristics are the same, such as two red toy cars with similar shapes. The two toy cars can be used interchangeably, which is what we mean when we talk about “equivalence.”
However, there are occasionally toy automobiles that have the exact opposite appearance, such as a red and a blue play car. These cars are known as “matching assets,” and they are polar opposites of one another. If you have two red toy cars and two blue toy cars, they will both vanish since they can cancel each other out. There is a “policy” in the toy box that specifies how these toy automobiles must cooperate. The “Root Authority” is the ruler of the toy box, and ensures that all the toy cars follow the rules. This issue is about ensuring that toy vehicles that are created by the same toy car manufacturer can cancel each other out effectively by following the “policy’s” rules and ensuring that the “Root Authority” is upholding them. In the carbon market case, we are talking about the matching pair being emission tokens and carbon removal tokens, for example.
If we want to identify matching pairings, we need to make certain adjustments to address the issue with the toy box and toy vehicles. To use toy cars that have the opposite appearance from one another, such as the red and blue toy cars, we must first establish new rules in the “policy” that instruct the toy box how to use them.
We must also make sure that the toy box is aware of and comprehends these new rules. In order to explain the specifics of how the toy cars should interact with one another, we will add additional “UI and API functionality” buttons and screens to the toy box. We will also add some special assistants to the toy box, referred to as “smart contract functionality,” that verify and ensure that the toy cars are cooperating properly in order to ensure that the toy box abides by these new rules.
In order to solve the issue, new rules can be added to the “policy” that instruct the toy box how to use the toy cars that are the opposite of one another, new APIs and UI buttons are added to the toy box called “UI and API functionality,” and additional special helpers are added to the toy box called “smart contract functionality,” which will check and ensure that the toy cars are cooperating properly.
3rd Party Content Providers
3rd Party Content Providers are a new feature in the Beta v2 release. Users may now access and use content from other content suppliers, which makes it even simpler for them to locate and utilize the tools they need to measure and manage their carbon assets. Imagine that you have a sizable Lego set and you want to construct a castle. This will make it simple to see how useful 3rd Party Content Providers are. There are many rooms in the castle, and you want to make sure they are all constructed properly. The building guidelines for the castle act as a “policy” that outlines what must be done and how to do it. When constructing the castle, you occasionally require additional details to make sure the rooms are constructed properly. You might need to know, for instance, how many windows a room needs or what color the walls should be. The instructions require this additional information, which is like “MRVs” and “form data,” in order to make the best judgments.
Now, the additional details may come from various sources, such as a note from a friend or a photograph you took. It could occur either before or after you begin construction on the castle. Sometimes you may need to get a second opinion before using the additional information. In order to create the castle rooms appropriately, the instructions, the policy, and the MRVs and form data must be used correctly. Additionally, the information must be accessible and simple to examine at any point once construction is complete. In our case, we aren’t building a castle, but rather, we are building methodologies that need specific MRV data points to fulfill requirements. These requirements may come from various locations and organizations.
We must thus make some adjustments to resolve the issue by using the instructions to build the castle. Prior to using the additional information, such as how many windows should be there or what color the walls should be, the instructions, or “policy engine,” must first be able to comprehend it. For the instructions to know where to find the additional information, we also need to add a few new elements to the instructions, such as a specific section. Additionally, we must ensure that the instructions may get additional information from various sources, such as notes from friends or photographs you took.
To do this, we will modify the instructions to include additional “Guardian Policy Engine” workflow blocks, which will allow the functionality to consume and receive external data. Additionally, we expanded the “Guardian API” to add push and pull third-party data feed facilities. In other words, the instructions will have the ability to accept and retain the extra data until they are required, and they will also proactively seek the data when required.
The constructing process will also be able to pause while the instructions wait for such information to become available, and it will be able to resume once it does. To accommodate the existence of external entities that can evaluate or process raw data prior to its arrival at Guardian, we can also establish new roles and trust chains referred to as “Guardian roles/actors.” Finally, the instructions support data in the following formats: binary blob, text, pictures, and JSON data.
Additional features
The Beta v2 release offers several new capabilities in addition to the upgrade to Guardian v2.8, which are especially helpful for companies and organizations operating in the voluntary carbon market sector.
Guardian Community Add-Ins
Agrecalc and Cool Farm, two brand-new DOVU CRU techniques, have been included in the preloaded policies. To manage the lifecycle of carbon tokens, DOVU has implemented the IWA VEM specification by developing an auditable procedure for calculating, reporting, and confirming emissions. Following the W3C Decentralized Identifier, Verifiable Credential, and Verifiable Presentation standards, participants in the process sign transactions using special keys and are connected to a native token via the Guardian.
And to top it all off, customers can quickly examine and analyze data connected to their digital environmental assets thanks to the LedgerWorks Eco Explore Implementation, which is especially helpful for companies and organizations operating in the voluntary carbon market sector.
Tenant Administration
Users and tenants can now be deleted by tenant admins. Admins may more efficiently control and maintain the environment of their tenants thanks to this new capability. The security and integrity of the tenant environment may now be guaranteed by removing any unwanted tenants or users who don’t need access to the system. Additionally, the Admins now have more control over the tenant environment, which makes it simpler for them to administer and monitor user access. Overall, this new capability enhances the tenant environment’s security and user experience.
Operations
Internal notifications have also been upgraded, enabling our internal staff to quickly and easily stay updated on any concerns that might develop. To improve the overall user experience and avoid downtime due to demand, the autoscaling tool has been improved for performance loading.
The Managed Guardian Service Beta v2 release’s new features and enhancements, as well as what they will mean for the voluntary carbon market sector, have us ecstatic. In order for us to keep improving the Managed Guardian Service for everyone, we ask users to test out the new features and share feedback on their usage.
Onboard Now: https://guardianservice.io/
About The Managed Guardian Service
The Guardian is an open-source tool that leverages the Hedera public distributed ledger network to mint emissions and carbon offset tokens. It provides auditable, traceable, and reproducible records that document the emission process and lifecycle of carbon credits, which reduces fraud in the ESG market.
The Managed Guardian Service (MGS) enables applications a way to mint emissions & carbon offset tokens without worrying about the complexities of managing the technology infrastructure. The MGS manages all of the technology infrastructure components so that companies that create applications for policies, emissions reporting, and the creation of offsets & credits can focus on what they do best.
