Sirob P.S. it's an honor to provide the dissenting opinion. It what's makes democracy and our DAO more resilient and innovative. As Einstein reportedly said, "what's right isn't always popular, and what's popular isn't always right"
KIP-17: Delegate Retirement Aggregator Inclusions
Finally, in case it's not obvious, I will support and rally behind what the DAO decides for KIP-17, like in any robust organization, whether decentralized or not. I hope no one takes the wrong way my candor, since we're all here striving for the best for all Klimates, KlimaDAO, ReFi, and the climate at large <3
- Edited
GolanTrevize I should have clarified that I meant people who already own Klima. We have to convince them to do so in the first place, which is a different set of arguments anyway. But even if someone chooses to directly offset via USDC, at least it will be better to do it via our aggregator, since otherwise we are not getting a dime out of this transaction. By allowing this, we would hopefully be the user's interface, even if the majority of the "backend work" happens outside Klima's ecosystem. Keeping the customer relationship is very important at this stage I believe.
Sirob Nice work, bro. Always appreciate your insights.
There's been some good discussion here, and I'd like to unpack some of my own thoughts on this tool.
This specific function of providing an interface to retire and offset on-chain carbon has been in the works for a long time. I recall being on a call with multiple contributors from both Klima and Toucan back in November of 2021 as we discussed ways forward and the importance of driving outside demand for BCT. As such, it has gone through a few iterations already internally. Ultimately the carbon we bring on chain is meant to be purchased and retired(spent) to claim them against emissions.
TLDR: If there's a bridge that has proven that its tech brings carbon on chain in a verifiable manner, I don't see why any of their pool tokens wouldn't be an option to select. We just have to verify that there is liquidity and where that liquidity is so our tool can swap accordingly.
The way I have approached this project has always been from the perspective that providing an easy to use, universal experience for users to offset their footprint in the proper way outlined by a bridge. We are all here building a brand new space without standards, and the opportunity to both innovate and show both what we can do and the potential ease at which these transactions can occur is honestly astounding to me. The literal cutting edge of an industry.
This started as a simple retirement helper tool for Toucan based carbon. Moss and MCO2 came in and that shifted the perspective to making this a one stop shop for on chain carbon retirements. Then came Goddess and C3. Each of these bridges has either different retirement flows (Toucan is fully on Polygon while MCO2 requires bridging back to L1 for example) or method calls. Building out some helper contracts that are bridge specific and linking them all up into one master aggregator just makes sense for a unified experience.
On top of this, by working towards this model we can make it super easy for other protocols to plug in to our tool, allowing them to be climate neutral or positive natively since this master aggregator will retire the prescribed way depending on the carbon token you supply. That's honestly one of the larger parts that I'm excited about.
For me this tool has always been about increasing ease and accessibility for the entire on-chain carbon market. I truly believe that Klima is both a force to provide demand for carbon and facilitate the simplest market possible.
Simple you say? How is retiring complicated?
Let's take a BCT retirement for example. Say you have some sKLIMA you want to utilize since you've been staked.
- Unstake your Klima at the Klima dapp
- Swap your Klima into BCT on SushiSwap
- Redeem your BCT on Toucan
- Retire the specific TCO2 on Toucan
That's a lot of moving and navigating around for one transaction. With our aggregator it becomes
- Approve the aggregator for sKLIMA (if this is your first time)
- Fill in the total amount to retire and any desired detail info for the retirement
- Hit Retire
Of course Klima is an integral component of that market, and as such native support for retiring with KLIMA, sKLIMA, or wsKLIMA is there (as in you don't have to unwrap or unstake, it does that for you). I personally always saw any fee associated with this tool as an actual convenience fee. A user can have a quicker and simpler UX for a small fee by utilizing either our frontend dapp or integrating directly with the contract.
This is a base piece of infrastructure for the on-chain carbon market to leverage. I'd personally like to keep it friendly and simple for everyone to use.
I think two different discussions are being mixed here to be honest. One regards the possibility, in theory, that our retirement aggregator includes tokens that are not in our treasury (which I agree). But this does not lead to the automatically conclusion that every carbon token out there should be included in the aggregator without a specific KIP. Maybe some particularities (liquidity, methodologies, incentives) lead to a conclusion for one token but not for another one. The post say policy team will vet each asset, so I see no reason to not make a specific KIP for each one after the conclusion of the due diligence. There are only 3 out there rn that are not in our treasury, and each KIP only takes a few days. Not that I don't trust the team, you guys are the best, but if there is no urgency I don't see why a KIP and a voting system should be suppressed. So I changed my mind and will vote no.
The community at large should have a vetting mechanism to choose which carbon assets they want to accept, not just the select bunch of the policy team.
Posing the problem as being a problem with the KIP process is a mere way to circumvent the idea that a simpler, more expedite process could be used that would still allow the community some regards on the assets that will be picked for retirement.
And for that I vote no, I don't have much KLIMA for this vote, but still I'd like the thought of "this is trying to move control away from the democratic process of the DAO (for convenience as some have pointed)" to be represented.