• Proposals
  • KIP-44: Aligning KLIMA Supply Expansion with DCM Supply Growth

I just have a little question ? xd

what does mean: Current DCM Supply -0.23% ?

that carbon is disappearing from the chain (due to carbon burning?)

    I'm strongly in favor of this proposal. It is clearly based on sound principles and a cool-headed assessment of where KlimaDAO and the DCM are at, as well as what the entire ecosystem needs in order to scale.

    The proposal mentions that automation of the AKR adjustment process is a future objective and that, if passed, the Policy Team will be manually adjusting the AKR based on the guidelines outlined here. Can you expand on what this looks like under the hood a little, and also on what the future automated state will look like? Roughly how long would you expect the process to be done manually?

      This represents the next stage of Klima protocol mechanics and will result in a healthier DCM ecosystem. I'm excited to see how this develops over time, especially as we start to intake more robust data around expected carbon tokenization from new standards and carbon registries.

      One of the key innovations in the DCM is the ability to draw real-time data from what's happening on-chain. Adjusting AKR and, in the future, bonding parameters for different asset classes, will make the Klima liquidity engine more intelligent and effective in response to DCM dynamics.

      How do you measure growth of DCM? Do you count only tokens that can be bonded to KLIMA? How about If some other body hoards the tokens? The growth of the market can be high but not for Klima. Is that a scenario to be considered?

        KTOR Yeah, happy to expand.

        Realistically the calculation for modifying AKR and calibrations that get pushed to the Policy contract aren’t too difficult to automate via a python script.

        The primary concern is automation of on-chain activity, particularly the fact that interacting with the policy contracts can only be done via approved wallets (so the script needs access to keys).

        So the calculation itself isn’t really a blocker, it will be good to test in the wild over time - the main blocker is having a process that minimize and risks and potential errors when automating on-chain interactions from approved wallets.

        I hope to have this automated with little friction, but want to proceed with caution before having a fully-automated process live on-chain.

        Alanos86

        interoperability is the future and the treasury will eventually have complete ability to absorb any carbon asset it desires

        if some other entity hoards tokens (on-chain) -> then the DCM supply stat still records the fact that the tons made their way onto the blockchain.

        if the supply growth of DCM supply increases, the supply growth of KLIMA increases. If others are buying the new carbon (and there is more external demand than KlimaDAO’s protocol) -> we’d expect that demand to also reflect in the carbon assets KlimaDAO already has in its treasury

        so the underlying concept remains that $KLIMA is a de-facto index of the DCM, and when activity increases in the DCM it will increase in $KLIMA

        It is important to note that OlympusDAO (on which the KlimaDAO code is based) had also gradually reduced its APY. I think it currently stands at 0.5% (or less), even though it is a DeFi based protocol with continously growing supply of treasury assets / stablecoins in the DeFi ecosystem.

        It makes absolute sense to bring the AKR to 0% when carbon supply is -ve due to zero tokenization and increasing retirements. This is a double whammy on $KLIMA.

        Where can we see the current "For" percentage?

        Strongly in favor of this proposal. The staking rate should be determined by the overall DCM environment and supply of carbon on Polygon.

        13 days later
        Cujo locked the discussion.
        Write a Reply...