Guardian token rectification architecture

[anvabr]

Problem description

When a need arises to revoke/invalidate previously generated VCs/VPs as per #611 Guardian will invalidate the corresponding Policy execution path which follows the invalid step. This can ultimately result in invalidating tokens, and potentially require replacing them with newly minted (correct) tokens, following the policy section re-run with corrected data/VCs/VPs.

This ticket captures the requirements for the latter 'token recall' stage of this process.

Requirements

Summary of the flow

When a particular step Guardian would issue a revocation message for the MRV VC doc in the corresponding topic as the first step, which would invalidate the corresponding section of the trustchain, including the issued tokens.

The tokens are then put into the ‘invalid’ pool in the smart contract that manages them (based on the serial numbers), which limits the scope of the operations that can be performed on them - e.g. ownership transfer is prohibited. The corrected MRV will then be re-submitted (manually if needed) and the corresponding artefacts defined in the Policy workflow re-executed, and the tokens re-issued.

The tokens are NFTs, and can be owned by different entities who might have bought it on the open market so any operations on them needs these entities approval. Therefore the original issuer would produce a ‘recall’ message for invalid tokens, and create a swap contract. The owners of the invalid tokens would then convert them into valid ones using this 'swap' facility.

Details

The flow of events for the recall is as follows:

• ‘recall’ message issued, ‘recalled’ tokens are listed in the ‘error’ pool (the list of serial numbers - they are NFTs so uniquely identifiable)
• new corrected tokens get issued
• ‘swap’ contract is established by the original issuer of the tokens
• owners of ‘recalled’ tokens use the contract to swap theirs for the correct one
• ‘error’ NFTs are burned (or kept in the error pool indefinitely) by the original issuer

The original issuer finances all operations required for the recall (since it was their mistake in the first place). When the current owners of the tokens need to execute a swap action the original issuer finances the operation (through a mechanism similar to the ‘gas station’ concept from Eth)

Definition of done

Full token lifecycle management mechanism exists and is driven by Guardian policies.

Acceptance criteria

Policy authors can define in the policy the required recall flow, which is actualised by the Guardian

[Mpinnola]

Please see attached a summary of how some prevalent standards manage errors and credits issued in error. I have also included some of my initial thoughts for how errors may be managed by the Guardian.

One of the major considerations is that once a credit is sold or retired, it cannot be revoked. Instead, after correction, the deficit or surplus is rectified between the issuer and the initial recipient. I generally think this makes logical sense. If a credit is retired, it should be impossible to be revoked. If someone paid for an offset, they should not be penalized for an error that they were not responsible for, as this may also hamper climate commitments and devalue offsets as an asset (due to risk of revocation).

In addition, I have attached some proposed processes. The CRU/Offset process mimics the approach taken by Verra, which I generally agree with. The CET/Emission process proposes the concept of an "Error Token," which I think is worth considering.

Looking forward to your thoughts.

Notes_Issue #838 Invalid Data Management.docx
Issue 838_Data Error Management_5-30-22.pptx

[anvabr]

Perhaps for every policy that results in a minting of a token there should always be defined a 'token pair' - a CRU/offset token which is the main product, and the matching 'negative CRU/offset' token that is a 1-to-1 match for it but has the opposite meaning (like +1 and -1).

[Mpinnola]

Thats an interesting concept, thanks!

Perhaps the negative token can be programed to basically activate and burn a CRU from the original recipient's account if an error is detected? If they don't have sufficient balance of CRUs, perhaps an active negative token can remain in the account and automatically burn from the next batch of issued tokens? They would effectively have a negative balance.

Could we have it so when sold, the CRU is transferred and the original recipient keeps the negative CRU, it could remain inactive unless an error is identified.

In any case, a retired token should remain unaffected, right?

[voycey]

Just to add to this from the conversation on the call today, our plan is that we record various tokens and handle errors as gracefully as possible.

We plan on maintaining a buffer pool of tokens that have a specific "Maturity" (e.g. 7 days), after 7 days it is a FIFO type of thing where the "buffer" tokens mature into CRU's and can then be transferred etc.
Errors that are found are tracked as Error tokens and the Buffer tokens are used to offset these

If there are no buffer tokens and error tokens are there to take us into negative balance the next buffer tokens generated are used to offset these.

The case of a bankruptcy situation then there will need to be some kind of remediation (reputationally or financially) that discourages this.

[Mpinnola]

@voycey Hi Dan, if I understand this correctly, let's say a Project Proponent receives 10 CRUs in error. They will be issued 10 error tokens, which will be offset by matured buffer tokens? In the absence of buffer tokens, there will be a balance of error tokens, which will effectively act as a negative balance?

How is the buffer pool populated, by withholding a % of CRUs upon issuance, just like the Verra buffer pool for reversal risk? Would each account have a buffer pool? Or a communal pool for all the projects? If there are no buffer tokens, would the account holders be able to buy CRUs to clear a balance of error tokens? Could normal CRUs be used to offset error tokens if they have a sufficient balance?

[voycey]

@Mpinnola yeah something like that, Auditors would just want to see that it is accounted for, I think it would be a buffer pool per project / policy.

As discussed last week - if there is no balance of CRU's to cover the balance of Errors tokens (aka Bankruptcy) there needs to be a community discussion around how this is handled, buying CRU's to cover for example might be what an auditor suggests, this kind of rectification in an audit is common, if this doesn't happen then maybe some kind of reputational black mark?

[Mpinnola]

@voycey I think one benefit of the buffer pool per project is that it avoids individual projects benefiting (at the expense of the community) from errors. For example if a project is issued 10,000 CRUs in error and they sell them, that project should rectify the discrepancy, rather than being bailed out by a community buffer pool. By "community," a mean group of projects under a standard or policy. However, one benefit of a communal buffer pool is that it lowers the risk of not having a sufficient balance to cover any large errors that could result in bankruptcy. Perhaps we can even have mix of both where each project has a buffer account and additionally they could contribute into a communal account as a sort of bankruptcy insurance program (as a last resort)? Just a thought. What do you think?

Regarding bankruptcy, perhaps there should be some sort of temporal threshold after which the account/project proponent is either frozen, suspended, or deactivated if they do not rectify a negative balance? I'm thinking if a project is in good standing, they will either have a balance of CRUs, or an upcoming issuance that they can use to rectify. If they have neither, and they refuse to purchase CRUs to rectify, perhaps a reputational black mark may not be enough?