[Software Upgrade Proposal]: Regen Ledger v3.0

Hey all!

Got some very exciting news for my first post here on the Commonwealth forum :slight_smile:

The RND team has been hard at work the past few weeks on an accelerated timeline for an MVP version of what we’re calling “Baskets” on Regen Ledger.

This new functionality is what will enable ecocredits (Regen Network’s native representation of ecosystem service credits, i.e. carbon credits) to be transfered to other IBC compatible chains.

With the cosmos carbonZERO earth program, and other Cosmos ecosystem demand for carbon credits on the rise, the RND Inc team feels it is important for ecocredits to have the ability to be exported to the interchain world.

The current demand for carbon offsets from Regen Ledger is estimated to be above 80,000 tons per year simply to offset the “Scope 1” emissions (validator infrastructure emissions) of the cosmos ecosystem at this moment, and this does not consider the potential for carbon credits to find other markets and uses beyond simply offsetting the blockchain infrastructure securing the internet of blockchains. We believe this will anchor Regen Network’s utility and relationship with the larger internet of blockchains and is a significant next step for our community.

If you’re wanting more details about the Baskets functionality and the reasoning behind this upgrade (including how this relates to our ongoing work with the recently devised NCT Standard), please dive into the github PR which contains the full proposal text here: https://github.com/regen-network/governance/pull/8

Our engineering team tagged a beta of Regen Ledger v3.0 last night, and we’re all-hands on deck today and tomorrow running internal testnets and audits of the code.

Our timeline may be delayed slightly depending on how quickly we c

I don’t have anything constructive to add but just wanted to say I love the baskets concept and am extremely excited to use it. It will make ecocredits accessible and easy to use, especially with the future possibility of retiring a basket token (and the ecocredits contained) directly. The potential of ecocredits over IBC is mind blowing..

Linking the basket specification here as it provides great context: https://github.com/regen-network/regen-ledger/blob/master/rfcs/002-baskets-specification.md

This sounds like an interesting proposal. Admittedly, I’m not as familiar with the “baskets” concept as I’d like to be. On the surface, it seems like making the eco-credits IBC-transferrable sounds beneficial.

While I read through the use cases of the baskets spec, I’d be curious to understand which additional use cases making them transferrable enables.

I am super excited to bring Eco-credits into the interchain economy, and think there will be a vibrant market for our community of credit issuers.

I also think this is a huge step forward to continue building relationships and a user base in the larger cosmos ecosystem.

This is really great - it expands the use cases for ecocredits and Regen Ledger assets, building the ReFi ecosystem to be much bigger with IBC.

This proposal is very exciting. IBC compatibility allows Regen to inoculate the Cosmos SDK with regenerative assets. Protocols can integrate earth restoring obligations to their base transactions and offer tokens, loans, NFTS, compute, privacy, even game p2es that are tied to eco-credits. This is an important next step. Carbon credits are a great initial offering, what would launch on osmosis look like for liquidity and sourcing?

This is something I feel is needed, RND is building something huge and that takes a long time. It’s nice to the engineering team working hard to bring the community more functionality. This is a great opportunity for the cosmos community to start acquiring carbon on chain!

Nothing to add beyond something that was really needed and expected. I would love to see a nice communications plan so that it can be shared across the community in the Cosmos space.
Bloclick Validator

LOA Labs validator is a strong yes here. As as long time community member and partner of Regen Network, this is a smart move to bring a liquid carbon product into the interchain. It is important for both Regen’s roadmap, to the ZERO program (validator/protocol offsetting) and to continuing to build on a new narrative of crypto being a critical tool to reverse climate change.

This is very exciting and critical to the vision and mission that Regen Network has held all along. Our hope at Regen Network is that these upgrades and modules are so useful and well designed that they become the obvious place for ecological assets across IBC and beyond. With the introduction of the Gravity Bridge and the launch of EVMOS, my sense is that this upgrade means more than just intra-IBC eco-credits, but it has the potential to become one of the standards for eco-credits across the Web3 space.

Appears lots of important aspects have been considered. Looking forward to experimenting. Ekonavi Validator on board.

I fully support this vision and proposal — excited to see what people will build! Some of my reflections below and happy to hear additional thoughts or course corrections from RND members closer to the action.

Reflections on Pipeline of Projects

Scaling the quantity, quality, and pipeline of projects on chain is the other side of this. I’m also excited by the flexibility that Regen Ledger, as a layer 1 / domain specific blockchain, will do to unify the space further first with Cosmos and then beyond. Given the deep connections of Regen to land stewards I hope this will happen quickly.

Reflections on Project Context

The points that Will and Gijs point out are important to recognize and I can imagine a catalog or registry or marketplace for project discovery, context, and narrative regarding ecocredits and baskets. Lots of space for decentralized participation and innovation, perhaps we’ll see a future grant round that focuses upon a theme or topic area.

Will, regarding the number, yes the next proposal is #9, the 8 above just refers to the GitHub pull request

Reflections on Issuance

From my study of this spec, it’s clear that this proposal simply addresses the underlying technical infrastructure and it’s the responsibility of the credit class designer / basket author to ensure viable ecocredits. Since Regen is the first issuer, future issuers will have clear precedence prior to a future governance proposal that adds new designers.

Questions Regarding API Language

One minor question, in the spec it lists language there to deposit and redeem, pick and take.

Is this language chosen from a specific domain?

I found it a little confusing — hardest problem in software is naming things =)

Has the team considered the verbs deposit/withdraw and add/remove as atomic operations?

It might be also be worthwhile to consider possible error uses cases and amendments at the design level. For example to avoid a situation in which an entire basket becom

This generally feels like a beneficial upgrade for the Regen and larger IBC community. While on the surface, making the baskets sounds beneficial and necessary, I’m curious what specific use cases it enables.

For example would -

1 - Any Cosmos network wallet now be able to send/receive these baskets to any other Cosmos network address, e.g. could I send one from a Regen address to a Cosmos address?

2 - These baskets be able to be denominated in tokens other than REGEN?

Also, on a broader notes, I’d like to see upgrades like this tested by the existing validator set on a testnet, prior to deploying. I believe this is good practice.

If I recall correctly, I suggested this on one of the first network upgrades, with the caveat that this practice gets harder to implement as time progresses. At the time the idea was politely declined because the upgrade was “only a parameter change”.

This upgrade seems like more than that. So now would really be a good time to start the practice of deploying to a testnet run by the existing validator set, in addition to whatever testing is done on internal testnets.

And to your last comment about testnets - We have our redwood testnet which we generally mirror the existing mainnet functionality. We’ve discussed having a governance proposal go up as soon as next week for Redwood testnet (which has a 2-3 day governance window), and would love to invite participation from any existing mainnet validators in that!

Prop 9 is live!! – https://commonwealth.im/regen/proposal/9-regen-ledger-v30-upgrade

@corlock I’m assuming this is the commit hash we’re voting on?

As a matter of practice, I’d suggest including the commit hash in the proposal itself moving forward. It took some digging to find it here -

https://docs.regen.network/migrations/v3.0-upgrade.html#upgrade-details

Which was linked to from here -

:slight_smile:

cc: @Qwoyn