Thanks for addressing those points, sounds like supply will be pretty constrained in the short term.
Side note: this does remind me of the whole "kilograms vs tonnes" discussion - I undestand CCO2 is denominated in kilograms instead of tonnes, honestly in a world of fungible tokens I'm not super fussed about that, though the industry standard is one tonne so in my opinion fighting against that isn't really worth the effort 🤷♂️
Just to make sure everyone is clear on the scope of this proposal, let's say hypothetically that this RFC advances, passes governance in a few weeks and then a month or two later the Carbonmark integration is successfully implemented:
1. How many tonnes would Coorest expect to list on Carbonmark initially?
2. Are there other significant holders of CCO2 besides Coorest itself (on behalf of your project developers) who you expect to list?
Overall I concur with 0xy_Moron that this initial proposal to include CCO2s in Carbonmark is a reasonable starting point, as there is little financial risk to the DAO. Data generated from CCO2 listings on Carbonmark would provide hard evidence of whether there is underlying demand for the credits at the listed prices.
This demand signal will also gauge the extent to which the Coorest Carbon Standard has established credibility with its innovative dMRV methodology and use of blockchain-native credit issuance.
In terms of reputational risk should issues arise with Coorest's standard or methodology, I'm not overly concerned as long as we clearly indicate in Carbonmark that CCO2 is a distinct asset from the traditional one-way bridged carbon credits originally issued under Verra's VCS standard.
This public governance process to vet the Coorest Carbon Standard and identify potential issues demonstrates KlimaDAO's commitment to credible neutrality. Even assuming all the concerns raised here are addressed, KlimaDAO will only gradually integrate this new credit issuance system into its existing infrastructure, with subsequent governance proposals required at each point of further integration (e.g. to create a liquidity pool or enable bonding).
Another open question, more for the KlimaDAO community rather than Coorest, is whether this initial proposal should include integration of CCO2 into the retirement aggregator?
Considering retirement is a key function of the Carbonmark product, I'd argue yes it should, but that will also mean that the treasury would start accumulating CCO2 fees from the retirement aggregator.
Technically KIP-17 specifically delegated decisions about inclusion in the retirement aggregator to DAO contributors rather than the KIP governance process. As articulated in KIP-17, this establishes an "integration funnel" for new carbon assets with an increasing level of governance required for increasing levels of integration:
- Partnerships and Policy teams vet the new asset for sufficient liquidity, as well as the quality of the underlying offset tonnage and security of the bridging technology.
- If due diligence does not reveal any significant concerns, the asset can be added to the retirement aggregator and enabled as a reserve asset so fees count toward KLIMA backing.
- If the asset continues to perform well and gain adoption, a KIP can be put forward by the Policy team to open bonding for the asset.
Given that this is the first new carbon standard we've had initiate the governance process for inclusion, it would be worth discussing whether any retireable credit which is approved for integration with Carbonmark should also include integration in the retirement aggregator, and therefore accumulation of fees denominated in that type of credit.
In my opinion, additional fees are a pure win for the protocol in terms of treasury market value and diversity of carbon credits. Furthermore, I there should be some ability for KlimaDAO to benefit from inclusion of CCO2 in Carbonmark. A 1% convenience fee on retiring CCO2 via Carbonmark's retirement aggregator integration seems like a reasonable way to do so without imposing extractive fees on Coorest itself or the project developers in exchange for inclusion.