On August 3rd, 2022, Verra opened its public consultation on its proposed approach to third-party crypto instruments and tokens. The 60-day consultation will run until Sunday, 2 October 2022, 11:59 pm ET.

See this document for full information about the context, timeline, and topics of consultation.

Additional context for this discussion: KlimaDAO is partnering with IdentDeFi to develop a proof of concept which provides a KYC solution for tokenized carbon credits. You can read more here.

This discussion thread was requested during the latest office hours by a community member seeking to provide their feedback to KlimaDAO's response to Verra public consultation. Please use this space to discuss the matter and share constructive feedback which you feel should be included in KlimaDAO's response.

There are a few insights I’d like to provide, but let me start with a few thoughts on the high level strategic direction: I think the best way to win hearts and minds at Verra is to highlight to them how a partnership between them and a DAO, and specifically Klima DAO, can provide (non-monetary) benefits to Verra and is something in both organisation's interests.

To my mind there are two large benefits Verra gets: a new source of customers for its' credits and an improvement in their own services and abilities. I would sum this up as: Customers and Capabilities.

Regarding customers, Klima has already demonstrated the ease with which we can entice web3 actors to offset their emissions, and can provide plenty of examples from Polygon to Sushi Swap. This is a community Verra has little exposure to and is unlikely to be able to capitalise on without an on-chain partner. Being able to satisfy offsetting needs for smaller "mom and pop" organisations, musicians, etc which can't access credits easily at the moment, is also an additional source.

However the other main source of customers is climate conscious individuals. "John Doe" is not going to offset his emissions directly with Verra and while other on-chain actors are targeting the personal market (e.g. FlowCarbon) they have no proven track record like Klima. Even when others wishing to sell to individuals go live, the fact we are a DAO leads to greater engagement with individuals than other on-chain actors can hope to achieve too (we should be easily able to plug in several justifications for this).

On capabilities, Verra is in dire need of a technology upgrade if it wishes to enter the on-chain market, which I suspect it does not really know how to achieve. We all know the possibilities available for reporting on high level trends all the way down to specific low level wallet transactions, but Verra will not. Highlighting what Klima has already provided (e.g. the drillable reporting via Playgrounds) will show possibilities.

However, the big issue will be Verra’s off-chain focused mindset: an offer to work with Verra to provide them not only with on-chain analytics but merging that with off-chain data sets (e.g. as a source of information into a data warehouse or repository, possibly even offering to develop a repository for them with on-chain loading functionality which they can then put their own data into that is managed by Klima or is handed over to them once completed for their own purposes). This might be a bit too ambitious but offering to work with then to develop a relational data model and ETL implementation to take on-chain data and normalise it into a classical off-chain data repository, might turn heads. Verra seems to have an interest in this (the consultation mentions data access, and the previously mentioned preferred relationship with "banks" to develop a blockchain solution) but a Klima offering, while possibly unlikely to be taken up, could nonetheless be a better proposition for Verra as 1) a proprietary third party system won't add in on-chain data (at least not for free), 2) won't adapt to events (e.g. fees would be charged for adding in the data for each new on-chain actor that starts up), and 3) would probably not be an equal partnership with possibly divergent goals (as in banks may be focusing on the bottom line where a Verra/Klima solution would be focusing on growing each party's long-term goals). Again, the offer might at least get Verra thinking.

With both a Customers and Capability message there is a danger that Verra considers it a good idea but investigates it with other on-chain actors rather than thinking of Klima as their favoured partner. While this may not be terrible (given Klima’s main purpose is to provide liquidity and tooling, not bridging) it would be preferable to be seen as Verra's main on-chain partner, and there are many things that can be pointed to (not least actually already have delivered a host of capability and transactions) that should carry weight.

There is also an opportunity here to develop a different type of relationship with Verra that other on-chain actors can’t really emulate: FlowCarbon and Toucan want to bridge credits and (in the case of FlowCarbon) offer retirement tooling, but Klima wants to sit in the middle between "real world" organisations and web3 in the carbon markets: it is an essential part of the business model to know the detail of the on-chain carbon market so that we know which tokens to allow in our Treasury and which to avoid (e.g. NCT) but it is a key part to market the services Klima offers to organisations big and small. Verra doesn’t have the time, people, and probably the will to hire resources to do the work needed in this space. Another on-chain actor could provide insights into web3 but none of them have business models that require them to both have that knowledge and also engage with organisations (and this is even without mentioning the governmental and regulatory Klima is engaging in). It is also the nature of a DAO that the eyes and ears of a community of tens of thousands will find out more than a dozen people at Verra’s office or 40 people working for a company providing on-chain carbon services which, combined with the experience of the Core team to filter the commentary provided by the membership to only the relevant content, can provide a service to Verra as the trusted on-chain partner to help it navigate the on-chain carbon markets in a way no other organisation can quite match.

    CCG

    Thanks for the in-detail work on the possible pain points Verra would face when turning to on-chain.

    I´d add the marketing point of view. In fact, it would drill down to a comparison between on-chain/off-chain. As in every "B2B"-engagement, a clear value statement of the service KLIMA and the DAO will provide is needed.
    This is why, we´d need to understand:

    • what goal is Verra striving for? Why are they doing it? How are they doing it? With What are they doing it?
    • what are Verra´s pain points?
    • Which jobs (technical, social, emotional, envrionmental etc.) are they running for?
    • Creating a buying persona - how can they be approached?

    Once that´s defined, we can clearly adress their pain points/needs by especially pointing out the benefits of Klima addressing their "Why". Not that easy, but if we hit it very powerful in the final decision of Verra to go on-chain.
    Talking about the jobs done - on the technical side - I deem it highly crucial to make the process of the Klima environment and how it´s set up as transparent and understandabe as possible. I assume that the respsonsible decision makers are more on the "older generation" side and will have the stereotype thinking of blockchain (more negative perception driven by the media). We need to shift their current beliefs towards our desired belief in Klima and the enormous on-chain possibilities.

    More or less, it´s a business development as we´d need to drive the possible implementation by approaching Verra´s needs/beliefs/values in a highly "customer-centric" manner.

    I know this is a very generic statement, but it would definetely help to generate a fighting guide for Klima to enable the on-chain adoption of Verra.

    • CCG replied to this.
    • CCG likes this.

      I wanted to raise a couple of thoughts regarding the Verra-side implementation of the tokenisation process. In particular addressing; "Is there a market need to provide for the reactivation of immobilized VCUs, as long as any related crypto instruments or tokens were not used for any other purpose and are destroyed as part of this reactivation?", and "what accounts constitute immobilization accounts and what transactions may be performed in them (e.g., retirements, reactivations if the environmental benefit of associated crypto instruments or tokens has not been used and such instruments or tokens are destroyed).", and "What infrastructure and processes do entities participating in the immobilization approach need from Verra".

      Verra will need to consider what data they wish to have access to regarding tokenised credits when a 2-way bridge is possible (a one-way bridge is a much simpler proposition, but Verra makes it clear in the consultation document they are not really thinking along these lines, so I'm assuming 2-way is the default in the below). While all transactions are immutable and transparent on the blockchain the representation of the tokenisation process in Verra's database (assumingly some sort of SQL Server/Oracle/DB2 type normalised data model implementation) is probably where most of the potential work is to prevent the risk of "double-counting". While this isn't really Klima's concern, any issues Verra has with reporting on tokenised credits increases the risk of another halt or slowdown of further credit tokenisation, hence it is Klima's interest to help solve potential problems Verra might encounter at the intersection of the relational and blockchain worlds (not to mention the benefit of showing itself as a honest and eager partner). I think the issues Verra might have are primarily related to data structures and processes. Currently the carbon credit lifecycle probably looks something like this:

      creation -> ([cancellation] or [vcm transfer] or [retirement]){0,1}

      Where after a credit is created and "live" all that can really be done with it is to cancel it (e.g. if an event like the forest the credit relates to burns down), transfer it to another database (e.g. from Verra's repository to Gold Standard) or to retire it (with an end-user realising the underlying benefit). This can only happen once, if at all (hence the {0,1} notation).

      The issue Verra has with marking tokenised credits as retired has been stated clearly in the consultation document, but really the problem isn't with tokenisation par se, but with an unclear representation of the lifecycle of a credit (and an inability to change this dynamically - as would be useful with the creation of the on-chain market). To my mind the work Klima and Toucan did had such an impact that the issue already present started being more visible to them (e.g. like in the graphics shared by, I think, 0xy, recently which show wallet addresses as two of the biggest buyers of VCM credits along with Shell, Delta Airlines, etc).

      There are two problems here I think Verra would like resolved here: knowing when a change in the lifecycle of carbon credits occurs and always knowing who the ultimate end-buyer is (who is realising the benefit of the credit).

      The lifecycle for a carbon credit in the future will probably look close to something like the below:

      creation -> [tokenisation]{0,*} -> ([cancellation] or [vcm transfer] or [retirement]){0,1}

      Effectively this means between creation and an end state there is now a new process that can be initiated, to optionally tokenise one or many times. That sub process looks like:

      tokenisation -> [detokenisation]

      i.e. once tokenised a credit can be optionally detokenised, and then that sub process can be repeated.

      A diagram would show this a lot better (as some of the states can only be moved into under certain conditions), but from this comes three key considerations:

      1). A 2-way bridge allows the same credit to be bridged multiple times (e.g. tokenised on the 7 August, detokenised on the 19 September, tokenised again on 11 October, etc)
      2). The same credit could be bridged by different actors at different times (e.g. Toucan the first time, C3 the second, FlowCarbon the third, etc)
      3). The same credit could be reported on by two on-chain actors' if that data is collected and provided to Verra at two different points in time (and on could state it as tokenised into their domain on the 11 October retired on say 15 October while the other reported it as "live" in their last data dump repository on 9th October)

      The concern isn't that a credit could exist in two different landscapes at the same time, as basic logic on Verra's side (do not allow bridging of a tokenised credit) combined with the basic tenets of blockchain technology prevent this, but that the quality of reporting on the on-chain actors' data dumps (which Verra has stated it will require in some form - which makes sense as they are unlikely to want to understand the different architectures of each on-chain actor to bring that all together themselves, and hence will likely state a standard format for the on-chain market to provide data in); the concern is that different actors providing different snapshots of data at different times will lead to potential inconsistencies.

      Again, this isn't Kilma's problem to solve but maybe raising it, and suggesting the solution, might win buy-in from Verra and increase the likelihood of a strong partnership (even though we know there is not chance of double counting, providing a way for Verra to verify this without understanding the details of blockchains can only improve confidence for them to move more quickly too). There are multiple answers to this but the one I prefer is:

      1). Each on-chain actor is responsible for providing data dumps to Verra using their specified format (likely included as part of the partnership agreement anyway).
      2). The data dumps include not one row per credit, but one row for each change in lifecycle state to the credit since the last extract (e.g. if a credit is tokenised, detokenised, tokenised again, and then retired, then the extract would include 4 rows for that credit).
      3). Verra loads these data sets using an ETL process they develop into a common data store. The data shared could be as simple as the Verra credit id, the tokenisation id, the on-chain organisation (Toucan, C3, etc), and the state the credit entered into, but would likely include some KYC requirements (like the name of the company utilising the offsetting benefit).

      On Verra's side it requires a fairly simple design change, so that the table in one of their data stores representing Credits has a relationship to a new Credit Event table, which will store one row for each change in lifecycle (populated from Verra's system or from data dumps from the on-chain market participants), linked to the Credit Id in the Credit table (and also a new reference table to hold the valid set of Credit Lifecycle States). This brings all off-chain and on-chain data together, for Verra to review in a relational format that they are comfortable with, and including the ability to easily piece together the full lifecycle of a credit from creation through to retirement/transfer/cancellation regardless of which organisations and systems it has travelled through.

      It also provides flexibility for the future, as new on-chain carbon participants emerge they will plug into the same process (requiring no change from Verra's side and a small amount of development from the on-chain side), and any new developments in how credits are viewed could be added easily by Verra as it saw fit via creating a new row in the Credit Lifecycle State table, a change to the existing data load interface, and a definition of how that state is entered into (e.g. maybe in the future Verra requires an "on-chain" transfer state to signify say the movement of a credit from one wallet to another - e.g. into a Liquidity Pool - or a state to signify retirements by corporates and retirements by individuals separately).

      Hopefully this description makes sense - appreciate it is difficult to describe abstract concepts in text without some pictures. I'd be happy to knock up a couple of diagrams (say a process flow and data model) and a couple of examples to highlight these concepts better if people were interested?

        Petrazn I think these are valid points, but I suppose this comes after the repsonse to the Verra consultancy document? My view is that Verra positions the consultancy statement as a) opinions on what we intend to do and b) does anyone have any ideas to mitigate the concerns we have raised and once they are into the "signing agreements stage" these would be most useful?

        Your response does make me think that my first post related to a lot of "Klima has unique partnership points others don't have" as intended but that I maybe didn't make it clear that these should be woven into a narrative when replying to the questions Verra has asked as a way to advertise Klima's benefits while also trying to steer Verra's thinking.

        The "Customers and Capabilities" narrative I proposed could be referred back to when answering each question - for example on the KYC piece, considering the announcement recently of the partnership with IdentDefi a response to Verra's question of "should everyone be KYC-d" could be "KYC-ing is a great idea, here is a (assumingly by October) proven implementation that allows each transaction to be linked to a KYC-d buyer and seller", developing the "Klima can provide you with capabilities" narrative. It can then be extended to "however we feel the KYC-ing of individuals choosing to offset their emissions would not add benefit due to the friction it creates into the process for large numbers of small transactions that are likely to be facilitated through the on-chain carbon market - e.g. via Klima X registered Klimates (individuals from across the globe) have retired Y thousands of tonnes of carbon in Z months" which reinforces the Customers narrative too.

        I think all the points you raise are definitely good things for the team to consider as we get past the Verra consultation stage and we are building that relationship piece - I particularly think the persona, possibly via building a relationship with two or three people on their side that develops that relatable persona to make it easier to pass opinion and ideas easier, would be key.

        CCG Thank you for sharing your perspective on these critical issues around tokenization. You bring up extremely important points around the consistency of tokenization across different pieces of infrastructure and harmonizing that data on Verra's registry. As you pointed out, the current state of play in the DeFi space with multiple bridges utilizing not wholly standardized methods for tokenization presents some potential challenges - undoubtedly we will need some form of standardization to provide a clear data structure for Verra. This is particularly true, as you pointed out, on the 2-way bridging front.

        [The following are my thoughts and not necessarily a reflection of Klima's core consensus around these issues]
        One-way bridging provides an elegant and potentially more robust solution to two-way bridging because reliance on Verra or another registries centralized ledger is no longer required, beyond the initial state change to 'tokenized' (i.e. immobilized), once credits are bridged. We can take an example on how inter-registry transfers are completed today to illustrate this:
        CDM Registry - Cancellation of CERs for transfer to Verra's registry
        CDM Registry - Cancellation of CERs for transfer to Verra's registry

        This was essentially the model taken by Toucan and later C3 for tokenization. Credits are retired/cancelled on one registry and then recreated on another registry. For all intents and purposes, the journey of these units on the CDM registry ends once they are cancelled, and their new life begins on the Verra registry. At no point in their Verra lifecycle beyond issuance is further information relayed back to the CDM registry. One could imagine that if these credits were retired on the Verra registry, information could flow back to the CDM registry to change their state to something like 'retired on Verra's registry'.

        Ultimately, we want the registries to feel comfortable adopting blockchain technology. I think we may have more success, initially, by pushing for an analogous system to what is employed today for inter-registry transfers (i.e. what is essentially one-way bridging).

        On this issue and others highlighted in the Verra consultation draft, our team is currently developing responses and working closely with other allies in the space. We will undoubtedly share more on that publicly as the consultation progresses, both on this forum and through other outlets, and appreciate continued input from our community during this time.

        • CCG likes this.

        I definitely think we should be strongly suggesting one-way bridging is preferred. If you think of the process applied to a carbon credit (basically creation -> [tokenisation] -> retirement) and then sit and think for a few minutes about what 2-way bridging allows (basically any amount of tokenisation and detokenisation): as I highlighted above the complexity goes up pretty quickly.

        I also think it is quite conceivable that with 2-way bridging credits could be tokenised and then detokenised repeatedly, especially due to market forces when the opportunity for arbitraging was available. It reminds me of traders (I think from Enron) who would trade vastly more capacity through smaller interconnectors in the Californian energy market to be able to profit from the engineered demand.

        Verra seem to be thinking about 2-way bridging as their default position (the consultation document states "provision could be made to allow the reactivation of the underlying VCUs to support instances where the owner wishes to exercise rights over the underlying VCUs") so personally I would be advocating 1-way bridges in the response but also tackling the challenges of 2-way bridging head on (the potential complexity of understanding what has happened to a credit, Verra infrastructure constraints in the event of a strong arbitrage situation leading to hundreds of thousands of credits suddenly moving on/off-chain as markets change, etc), but then be softening this (so it doesn't look like Klima is being obstinate) with a message of "these are the challenges we see with 2-way bridging, but these are also solvable if you wish to go down this route, for example via A, B, and C". What I mentioned above is one potential ABC solution, but there are lots of (probably better!) others.

        2 months later

        Thanks @CCG and @Petrazn for kicking off the conversation here!

        I'm pleased to share a draft of KlimaDAO's official response to the Verra public consultation for feedback from our community here: https://docs.google.com/document/d/1dp6LnVD0A5857WIcCiNRqCSz7cWzsUXX_vNqnB6IPfg/edit

        Right now we're recommending a phased approach, where support for one-way bridging (a.k.a. Direct Tokenization in IETA's recently discussed framework for tokenization), which is technically simpler to implement and less likely to break, is prioritized while proper systems to fully support two-way (a.k.a. Secured Tokenization) are developed and rolled out.

        Note that this consultation is due on October 2nd, so please provide feedback promptly so we can integrate it by the end of this week.

        Write a Reply...