CosmWasm is a popular smart contract framework currently in use by over 30 chains including Juno Network, Osmosis, Stargaze, and Neutron.
CosmWasm smart contracts would allow the functionality of the Regen chain to be more easily extended with new functionality, as well as allowing for Regen to leverage a large library of existing applications and contracts. CosmWasm can be permissionless (anyone can upload contracts) and permissioned, where smart contract code uploaded to the chain has to be approved by governance (for an example see Prop 203 on Stargaze).
We propose the Regen Ledger should be upgraded to support permissioned CosmWasm.
Using CosmWasm, any developer could build climate imapct applications that leverage the core ledger database, ecocredit module functionality, and marketplace features – which will allow for dapps to be developed that utilize Regen development ecocredits and work towards incentivizing end users to purchase and retire these credits for climate impact. These developers could add these applications to the chain without having to coordinate a chain upgrade.
Moreover, some applications that could come to Regen as a result of adding support for CosmWasm:
DAO DAO: powerful governance tools to allow regenerative communities to self organize and govern shared resources and core use cases within Regen Network. With Interchain Accounts, Regen DAOs will be able to more effectively manage Cosmos Zero programs on other chains. New fundraising tools from DAO DAO will allow regenerative communities to raise funds to forward their missions. DAO DAO was [partially
I am excited about the conversation.
I love the idea of broadening the developer pool, decoupling some of the application specific logic one layer from consensus logic and making development lower risk and easier to deploy.
I also really like the idea of mesh security features, closer integration with Stargaze and osmosis, two chains and communities that Regen has strong ties and interoperability with.
Specifically I am excited about NFT functionality and marketplace interop with Stargaze to expand tool access for land stewards by easily originating on Regen then using ICS 721 to move NFTS to the thriving market on Stargaze
DAODAO functionality and potential token factory implementation for more agile bioregional DAO deployment for land stewards
Mesh Security opportunities.
Questions I have:
Is there a world in which the EVM also lives on regen ledger side by side with CosmWasm? Or, shall we lean on Evmos and/or other IBC enabled EVM chains for that? What are the pros and cons between using ICS and leveraging Juno, Nuetron, Osmosis, Huahua or other CosmWasm chains vs having this functionality on our chain?
I am also concerned about implementation overhead, security concerns and who will run the upgrade. Pending green lights on the ability for regen ledger to upgrade to 0.47 and the willingness of a group of independent developers to run the upgrade process with only minor support from RND I am a strong YES to bring CosmWasm home to Regen for a permissioned implementation
I would build apps on Regen Ledger using CosmWasm, and would love to explore the use of DAO_DAO for governance tooling for network-wide DAOs that are likely in the tokenomics upgrade, like a marketing DAO.
I am most excited about the opportunity to incubate an app developer community on Regen that leverages the core functionality of ecocredit module, credit issuance, marketplace, etc. We can finally make marketplace-adjacent climate-impact applications! I know of at least a few people who would become builders in the ecosystem if we had CosmWasm
I’d love to see a Stargaze outpost on Regen Ledger, so that folks can use the NFT functionality and integrate with the Stargaze marketplace. Mesh security would be amazing.
Looking forward to the discussion & really excited about this proposal.
This is exciting.
From my perspective the opportunity to built smart-contract enabled apps that engage with ecocredits is essential in the medium term on Regen. My only concern, which I am in a poor position to assess, is about the implementation and maintenance work it will take to keep regen ledger current over time. In the past, most of this type of work was done by RND developers, but that organization is stepping back from the primary maintainer role. Who will ensure that the necessary maintenance is done?
With everything added to a chain, there is some cost.
In this case, the cost would primarily be the maintenance of the integration: small upgrades around security (probably more coordination than technical cost) and SDK version upgrades. Having CosmWasm is another component that needs to be upgraded and tested with every upgrade. That said: I think the cost is fairly low. In my experience, it is not much work compared to most other modules you add to the chain. But there is a cost, and it will take time to maintain and test.
Another _potential _cost is around node performance. I know that there used to be some evidence that running CosmWasm was associated with higher hardware requirements for a chain. I am not sure if this is still the case. I would reach out to some prominent validators who run on multiple chains and could potentially give some data on this.
I would argue that it should be permissioned. You could easily whitelist a few addresses to make deployment simpler, however. For instance, you could set up a deployment group (DAO) that can quickly make deployments and updates. Or a developer could, like on Osmosis, ask governance to have their own multi-sig or group added to the whitelist so they can develop and deploy in peace. Many ways to do this one, and permissionless does carry some risk for both performance and security that I don’t really see the need for on Regen. For permissionless dapp development I would suggest adding more ICA and ICQ modules and let smart contract platforms deal with the cost and setup of permissionless smart contract deployment
In the end, the question is just if it gives enough value: If there are even just a few use cases that would be fairly certain to happen because of this, I would argue it should be hell yes.
Background: EmpowerChain CTO, I have integrated and upgraded CosmWasm there.
Use the v0.46.x spin that Notional made. It is unsupported by Confio, was only financially supported by Juno, and no longer is, and v0.46.x will be EOL’d at the release of SDK v0.50.x
Do
Adopt SDK v0.50.x or v0.47.x depending on desired timeline
Use a “fresh” version of wasmd, eg don’t use v0.40.x or v0.41.x – use v0.42.x or v0.50.x
Yesterday @Sarah Bax _ RND at Regen Network asked if Notional would be interested in working with the regen community on a governance funded option, and the answer is a definite yes.
I suppose that I can see this working in three distinct stages:
Upgrade to sdk v0.47.x or sdk v0.50.x
This should be done separately because either of these options is legitimately complex and so it is better to separate the needed changes to cosmos-sdk upstreams from the implementation of x/wasm
Add x/wasm
This would need to come after the SDK upgrade
Create bindings to regen’s modules
This should come after the addition of x/wasm
Notes
I’ve always felt that the most interesting parts of regen focus on land management and quantifying the environment. It’s my hope that making the tools available in regen available to more developers by adding CosmWasm will enhance these offerings. Due to some past experiences working on carbon credits, I remain rather lacking in faith on that concept, but it’s always been my understanding that Regen is about much more than carbon credits, and I’m very supportive of this. A good example of that would be the gentleman I was on a twitter spaces with who was working on “integrated” mangrove buffer zones that considered how these zones can be used to produce gainful employment, food, and clean water, while growing the world’s mangroves.
Thank you for bringing this back to discussion and highlighting the benefits of CosmWasm on Regen.
Background (Cosmos SDK v0.46)
For additional context, CosmWasm was previously implemented within Regen Ledger as an experimental feature (i.e. we made it available when using EXPERIMENTAL=true at the time of building the application). We spun up an experimental test network (i.e. Hambach Testnet) with CosmWasm enabled. The experimental test network went unused for about six months before RND decided to shut down the one validator node securing the experimental test network.
One reason worth highlighting here is the following:
We removed the experimental build option following Regen Ledger v4.0 because CosmWasm is not compatible with Cosmos SDK v0.46 and it is not technically possible to support both without maintaining a fork of CosmWasm. We chose Cosmos SDK v0.46 over CosmWasm and now have to wait for a new CosmWasm version that is compatible with the latest version of Cosmos SDK. The CosmWasm team has chosen not to provide a version compatible with Cosmos SDK v0.46 and are halting all work that would support Cosmos SDK v0.47 until they receive more funding.
There is now a community maintained fork of CosmWasm that supports Cosmos SDK v0.46 (thank you Notional) but it may still be relevant to consider the cost of adding a dependency to Regen Ledger that could prevent or delay Regen Ledger from using the latest version of Cosmos SDK in the future. I personally was a bit turned off by Confio’s refusal to support Cosmos SDK v0.46 and therefore I still hold concerns about the future of CosmWasm and adding it as a dependency.
Cosmos SDK v0.47 or v0.50
With Cosmos SDK v0.46 reaching EOL following the release of v0.50, I think updating Regen Ledger to either v0.47 or v0.50 would be a good first step to adding CosmWasm. [The rough outline
With geodata-anchor (Junø/CosmWasm contract) and geodata-rest (HTTP REST Server) we address the feasibility of providing performant and scalable access to geospatial data in geojson format, leveraging MongoDB’s geospatial data and queries. When a data item is ingested into the database, a hash of the relevant data is generated and stored on a CosmWasm contract which implements a cw-storage-plus indexed datastore. Validation results are stored on both the database and the contract. Validators would each run a MongoDB Atlas replica instance, with an independent compute instance performing the same hashing algorithm.
Current PoC implementation:
After discussion of this matter at the Regen Summit with Jake Hartnell of Juno/DAODAO, I’m in support of adding CosmWasm to Regen. In the spirit of “progressive decentralization” charter in the Whitepaper, there are there new DAOs launching in the Regen ecosystem (Economics, Engineering, Marketing). Jake demoed DAODAO, and the functionality here for DAOs is practically limitless. From my perspective, this tooling could be invaluable to these three new DAOs, and could justify the additional overhead and complexity.
I continue to want to hear more from engineers and validators on this topic, and will continue to keep an open mind!
At the same time, I would suggest we continue to hone in here and aim to get a proposal on chain over the next few weeks (sounds like we need to sort out SDK version along the way).
Hi, a little late but I’d like to voice my support for CosmWasm. In order to fully decentralize our cross-chain solution (ecoToken, currently on Solana) we would need smart contract functionality.
In my opinion, I don’t see how Regen can scale to become what I’m sure a lot of us believe it can be without it. I am sure there are a ton of use cases that have yet to be dreamed up that would be possible with smart contract functionality.
I understand that it would come with technical challenges but if there is any way to implement it that would be very much appreciated!
A few summary updates about this proposal for the community:
**Voting Timeline: **This proposal will be submitted to a vote once the voting for “open crediting” is completed.
Implementation Context:
In order to support Permissioned CosmWasm, it has been evaluated by the community (Notional validator and Ryan Christofferson, former RND-based Regen Ledger core maintainer), that the best course of action is to upgrade Regen Network’s version of the Cosmos SDK to v0.50. The current version of CosmosSDK (v0.46) is insufficient to support the version of CosmWasm that is most well maintained.
The implementation of CosmWasm will follow these steps:
Upgrade Regen Network from Cosmos SDK v0.46 to Cosmos SDK v0.50 (via a stepped upgrade of v0.47).
Public Process to Choose Implementing Engineering Team:
The RegenBuildersDAO will launch an RFP for the engineering scope on Commonwealth, with a two week window for proposal submission
The RegenBuildersDAO will evaluate and approve one or more engineering teams for the implementation scope and award the implementation contract
**Funding for the Technical Implementation: **Funding has been secured and will be provided by Regen Foundation, Regen Network Development, and if necessary, a Community Funding Pool request not to exceed 10% value of the Community Pool itself.
**Bonus Prize: **Once CosmWasm has been fully implemented on Regen Ledger, Jake Hartnell, and the DAODAO team, will deploy DAODAO on Regen Network, as a gift of reciprocity for early Regen Network funding and due to the deep alignment of our user base.
