KlimaDAO Forum

100% support this too. I had a similar opinion to @cascade when providing liquidity for the UBO/Klima and NBO/Klima gauges when C3 went live: accepting the highly probable loss of value via missed rebases from providing Klima for liquidity (which almost certainly wouldn't be recovered by fees) in order to get the protocol up and running.

I would argue this proposal isn't even good just from a personal incentive point of view: for those who wish to provide liquidity into C3 (or create other LPs in the future) using their Klima they have to accept a pretty hefty cost via inflation, meaning it is unlikely there will be significant growth in Liquidity Pools beyond what Klima (as the source of the Protocol Owned Liquidity) directs, without it. Further the experience of those individuals who do provide liquidity and are not experts in POL (and who realise the impact of rebases on unstaked Klima at a later date) might not share a positive story about their experience.

While tokenisation of VCM credits is paused and the Klima AKR relatively low at present the impact of not having minting, for now, is limited. However, next year if tokenisation restarts, it is highly likely (at least from my point of view) that the AKR will start to increase as bridging restarts, which will increase the impact of not having implemented minting.

This all sounds great! Nice to see a range of top quality partners coming together for something that provides a social good, shows the utility of the Refi space, can be pointed to when people ask for "real-world" benefits of Refi, and seeding the growth of a pipeline of DAO-sponsored projects.

From zero to here in a year!

Given the PR angle to these credits it makes absolute sense to burn them as suggested, regardless of any potential mitigating reasons for treating some as “good”. Hopefully this action will be accompanied by some reporting in Carbon Pulse, etc.

Even if not it is the right thing to do and as a leader in the refi space the example being set is great too.

While the HFC problem won’t happen again, some learnings can be taken from it so that, with the analytics capabilities Klima is now providing to dive into the detail of the origins of credits, any future potential issues like this can be identified, the bridging partner notified, and dealt with quickly and efficiently.

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.

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.

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?

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.