Multi-Policy Coverage

[blockchain-biopharma]

Problem description

Currently in Guardian there is a 1-to-many relationship between Policy and projects. If a project wants to conform to two or more policies such as Verra and Gold Standard REDD+ from separate "Methodologies" to increate the attractiveness (e.g. 'higher quality') of the minted token. There is no way to avoid double counting.

Requirements

Introduce the ability to define projects compatible with multiple 'active' policies in the same or different guardian instances such that when tokens are minted both of their 'trust chains' are verifiable.

• If the onboarding process requires manual interaction it is acceptable that users perform it for/in each policy.
• MRV data and the corresponding VCs etc must be processed as per each of the Policy, with all corresponding artefacts created as a result
• Only a single instance of the token[s] must be minted as a result, issued by a multi-signature of all Standard Registries involved in the attestation of the project.

The following design is acceptable:

• There is a single SR which is a 'lead' SR for the project. This 'SR' (or its designated body) physically mints tokens.
• The workflow for all other SRs ends right before the 'mint' step. Their resulting artefact is a VC containing the MRV and/or derived data which provide the grounds for minting the token.
• The 'lead' SR then assembles a VP containing its own VC and all other SRs' 'final' VCs and mints a token to which the VP is linked. This forms a tree of trust chains, verifiable within the scope of all corresponding SRs.

Definition of done

• Multi-policy project capability exists in Guardian
• The workflow of creating multi-policy projects is documented

Acceptance criteria

Minted tokens can contain references to multiple 'trust chains' owned/managed by multiple SRs hosted by the same of different instances of Guardian.

[Mpinnola]

There are two approaches to this that initially come to mind. One is a labeling system. For example, Verra has a labelling system where VCUs may be labeled with additional standards and certifications on the Verra registry where both the VCS Program and another standard are applied. One interesting label they are currently working on is to show conformance with the requirements of Article 6 of the Paris Agreement, finalized at COP26. In that case, Project Proponents would submit additional documentation showing conformance with Article 6’s requirements, generally prior to VCU issuance.

So perhaps our solution could have a similar functionality, where offset tokens can have additional labels. The labels would having their own requirements and schema (like a sub-policy), with redundancies removed. These labels could be sort of modules of the main policy/methodology. Users could sort of construct customized policy variations, with variations such as VCS-REDD-APD-Article 6, with VCS being the main standard, REDD being the specific methodology, APD being the project activity, and Article 6 being the label.

Another approach could be separate merged policies. For example, there could be the option to select a Verra policy, a Gold Standard policy, or a Verra-Gold merged policy that covers both. If the project proponent wishes to show compliance with both, they would select the Verra-Gold merged policy.

One potential issue I see with combining Verra and Gold standard is that if a project is processed and issued VCUs through Verra as the root authority, the project VVBs and Verra may not have the authority to also verify the project against Gold Standard, unless perhaps the VVB has both Verra and Gold standard credentials.

[anvabr]

Under constraint of using 'multi-sig' for the implementation of this functionality only the following design seem to be feasible: in the current guardian model multi-policy compliant tokens are only possible when there is one 'main' Standard Registry (SR) and (multiple) other 'secondary' SRs such that:

• The 'main' SR would need to know in advance that its policy is designated to be 'main' in a multi-policy situation (and thus designed accordingly) and instead of minting logic would create a multi-sig contract for minting the token
• The 'secondary' SRs' policies are dependent on the 'main' SR's policy that they 'contribute' signatures to the minting of a token (but don't mint their own) and they are MRV 'data input' compatible with the main policy. In practice this means that 'secondary' policies must use the same MRV schema as the 'main' policy, and use exactly the same aggregation block (or have aggregation is prohibited completely in both main and secondary policies.

The implications of the above on business case are that:

• This would facilitate the creation of 'ecosystems' of SRs grouped around 'main' SRs, rather than bringing the main SRs closer together. This is because there is this 'main'-'secondary' dichotomy, the SRs in this model cannot be independent and of equal standing.
• This also means that 'secondary' SRs/policies will only have the discretion to approve a subset of tokens that have been minted, or submitted for minting, by the 'main' SRs. I.e. they don't have the facility to approve 'more' because they don't mint any tokens of their own.
• Thirdly, if the multi-sig synchronisation is done in real time before the mint of the token these 'secondary' SRs would effectively have veto powers over minting of tokens by 'main' SRs. I feel this is unacceptable, which means they should only be able to 'join in' after the fact - i.e. sign already minted tokens to register their (token) compliance with their (SRs') additional requirements.