Hi everyone, I am new here, so please forgive some initial silly questions
As we’re expecting the CSDAO’s to fill in the competence/legitimacy gap in governance, is it possible to hold off coding anything permanent into the Ecocredit governance process while we figure out how to run those DAO’s?
I see @patogit point about considering carefully whose voice counts when deciding on aspects that have future implications, but I sense there’s a momentum in the air and @ryanchristo wants to develop features. I guess my question is : what is the scope (time?) for testing these DAO’s before we assume they can do stuff ? And related: what aspects can be rolled back in case we realise that they can’t do the stuff we were hoping they would? TNX!
Thanks @patogit! We really appreciate your thoughtful questions and feedback!
Once credits are retired, the credits can no longer be transferred. The ecocredit module tracks two balances for each account and for each credit batch: retired credits and tradable credits. So yes, if you retire credits upon transfer to me, my account balance for that given credit batch will include the retired credits and those retired credits are forever associated with my account.
The intention is to have retired credits count towards offsets. Whether this can be counted as an official offset and what that process looks like is a bigger question that someone else on our team might be able to shed light on. Maybe we need to be more careful with how we are describing retired credits. Thanks for pointing this out.
As Will points out in his reply, this is something that Regen Network aims to solve with the CSDAO model. Here’s a great summary of the problem and proposed solution:
It seems that one of the most important issues that has been brought up is the alignment between ESCredit Class stakeholders (designers, peoples, land stewards) and the on-chain governance of classes, allowlists, etc, as stated by @patogit
Community (people, stakeholders, land stewards, NGOs, the natural resources, plants and animals, etc)
And it seems that various people in Regen wear various hats, perform various roles, many are involved deeply in all of these areas.
I like the idea of cREGEN, or having types of governance roles or governance channels, because in each area of Regen, there may be different objectives, and different levels of access and understanding.
I imagine that SCDAO will address this.
Potential for ESCredit Speculation
It sounds like part of the potential of speculation on ESCredits can be mitigated by ESCredit Class Owners retiring issued credits upon transfer, so that the receiving account holder can not transfer their ESCredits thereafter.
Yes, I think leaving it up to the ESCredit Class Owner, who should represent the interests of the producers of the ESCredits, the ability to decide, hopefully through a governance process, whether or not transferrable (non-retired) ESCredits should be sold/issued/transferred to accounts at large, is good.
I think it was a great idea to give ESCredit Class Owners this option.
There may be models where a price increase for an ESCredit could circulate back into the community of producers.
Minor notes on terminologies
“Retire” credits is good.
Some additional ideas on terminology: perhaps Spent or Consumed or Used could be interesting, because those suggests the action that took place.
Retired could be understood to mean Deprecated. A retired credit could sound like the credit was deprecated and not that it was utilized/spent/consumed … or even expired, if that comes into play too …
Which brings to mind: What are start-date and end-date for?
Are credits only valid for Spending/Consuming during a set timeframe? Do they automatically expire/become retired or something at the end date?
A can of worms here … but going there … fishing pole anyone?
Will ESCredits be transferrable over IBC to accounts on other chains? Or is the intention for them to always only exist on Regen Ledger?
Thanks @I-A for the thoughtful questions and comments!
There is some confusion here and I realize there was a typo in my response. There are only two roles in a credit class: credit class admin and credit issuer. There is no “credit class owner”.
In my response, I meant to say “credit owner” (referring to a credit holder, someone who has recieved credits). When a credit batch is issued, credits are issued to a recipient. The recepient is the owner/holder of those credits. The owner/holder of the credits can choose to transfer those credits in a retired state to another account (the credits are marked as retired and associated with the recipient account) or they can retire the credits (the credits are marked as retired and remain associated with their own account).
That being said, credit issuers have the ability to issue credits in a retired state and this could be a policy credit issuers would be trusted to uphold. Currently there is no functionality that enforces a credit issuer to only issue credits in a retired state but it might be worth considering as a feature for a later version of the ecocredit module.
I hope that clarifies things! Sorry for the confusion.
This would be a really interesting idea to explore!
Credits are issued in batches. The start-date is the beginning of the period during which this credit batch was quantified and verified and the end-date is the end of the period during which this credit batch was quantified and verified.
These dates are separate from the transferability or retirement of credits. These dates represent the time in which the ecosystem service was quantified and verified. There are no time constraints on the transferability or retirement of credits.
Great question! The intention is to make credits transferable over IBC but this functionality will not be available in the first version of the ecocredit module.
Thanks for joining the discussion @Gijs_Spoor! We appreciate the thoughtful questions.
The Regen Network community can delay the upgrade by voting against the signalling proposal. I realize this is part of the issue given that the CSDAO’s are not yet up-and-running but this forum thread provides an opportunity for anyone to share their concerns and to gather support. I think this is an important question and there is a lot to consider.
We are in the audit and testing phase so we are not developing new features in relation to the planned upgrade but we are gathering feedback for features that community members would like to see in future versions of the ecocredit module.
On a personal note, reading about the CSDAO model played a big part in me joining this project and I think many of us working on it care deeply about all stakeholders having a voice.
I think Will might be able to shed more light on the first question.
For the second question, I’m not entirely clear what the question is but on-chain parameters can be updated through a voting process. Credit class creators can be added, updated, and removed. Credit types can be added, updated, and removed. If for some reason we needed to roll back or fix something in the upgrade itself, we could submit a follow-up proposal to do so.
I wonder where smart contracts might come into this, both regarding this governance process, and regarding what @I-A mentioned:
Selling a credit is a two-step process:
sending the credit from account A to account B (and optionally retiring it)
sending payment from account B to account A (or maybe payment will come from an account C, or multiple accounts)
The payment might happen on Regen Ledger, or might happen on a different chain, or off-chain. Maybe a smart contract would be involved?
Considering that payment is not necessarily on Regen Ledger, I think the tracking the sales price along with the transfer of the credit would require an extra system.
Given that smart contracts can mint tokens (if I remember correctly from the testnet)… I’m guessing the ecocredit module could be partly replicated in a smart contract, or a series of smart contracts, but it’s more elegant and better functioning to do it as a module. @corlock ?
I thought credit types, and everything else on-chain, couldn’t be removed, they could only be deprecated through a new transaction? Or maybe parameters are different than on-chain data, and they can actually be removed?
The cREGEN idea is interesting. (Seems kind of like the liquid staking idea, where a second token is used to represent the first token.) At the root of this, I see the question: Can we run a meaningful governance process on-chain that includes the relevant people? If so, how?
Yes! I think the CSDAO model is very important and sets Regen Network apart from other projects in this domain. I’m participating closely in figuring out how to implement a CSDAO in practice. The technical details of multi-sig wallets seem to be the least complicated part . Some of the questions to clarify for potential CSDAO members are “What is the system that we are participating in? What is it for, what can we do with it, who does it serve, how does it work, why does it work that way, what does it have to do with my family and my territory, what consequences does it have for us and other people?”
Answering those questions is part of understanding the system, and only then can people make informed decisions and proposals.
Since the Ledger, the Registry, and the Foundation are all still emerging, many of those questions have vague answers at the moment. Plus there’s the question, What else can we achieve with the Ledger and the organization of humans known as Regen Network? (I made a thread for that question). Sometimes I get the sense that we’re trying to model complex human society, with so many people with different perspectives and roles and relationships to the process. Sometimes I wonder if we’re re-inventing the bureaucracy of a country, with voters and money and taxes and auditors and regulations and more.
A friend who works in the movie industry told me there’s a saying, something like “a movie is made three times, and it’s a different movie each time: during script writing; then during filming; then during editing and production.” I sense something similar in Regen Network: initial visions motivated Gregory and Christian and others to put energy into gathering people and resources; that team worked during the past few years to understand the context and design something feasible; and now an even bigger and more decentralized team is working to put those designs into action… even as the global context continues changing! Each moment in that process, there were different visions and understandings of what Regen Network would do and how it would function.
Considering that the climate crisis affects everyone (and has roots in the colonialism crisis that made the climate crisis possible), getting all stakeholders involved is a big challenge, and so far impossible. The UN has sort of tried, and then kicked indigenous peoples out of COP25, so given that the largest attempt at global coordination is failing, well, we certainly have challenging work to do.
When considering stakeholders, I think it’s vital to keep remembering that some peoples have chosen voluntary isolation, and we (you, me, and everyone else reading this forum, and everyone you and I know) have no communication with them (or maybe teeny tiny communication, if you do vaccine delivery or go hunting deep in the woods). There’s a Wikipedia article that gives some ideas about these peoples, although given the inaccuracies and half-truths in the “Ecuador” section of that article, I cannot vouch for the rest of it. The article does not mention that the massacre mentioned among Waorani peoples was instigated and paid for by an oil company, and that the state runs oil wells and a pipeline (leaky, of course, being a pipeline) in the territory of the people in voluntary isolation (so much for isolation). At any rate, I remind myself that those people are my neighbors, they are part of this same forest, and they don’t want to talk to me or participate in any of my projects or use the internet, and there are more peoples like them.
This applies also to “who decides who to invite to form a CSDAO, and how do they decide who to invite?” This is something we’re thinking about. For now, we know that peoples in voluntary isolation won’t form a CSDAO, and it looks like the legal residency of Regen Foundation in the United States means that no one will be invited from countries the USA, the UN, or the EU don’t like – and remember, Nelson Mandela was on a US list of terrorists until 2008. I’m sure Bolsonaro (fascist president of Brazil determined to exterminate indigenous peoples) would try to get indigenous leaders in Brazil put on a UN terrorist watch list if he could, and then Regen Foundation would be prohibited from working with them – that hasn’t happened, but I offer it as an example.
So, these are some of the limitations we’re working with.
Awesome. Exactly. Yes, a smart contract, which receives its own account address upon instantiation, could be one of the approved Issuing Agents added to the allowlist by a class admin.
A smart contract could act as a service provider for those classes who wish to participate in it.
The functions/features of ESCredit issuance could be automated and extended via smart contracts.
From what I’ve gleaned, core functionality usually goes into the SDK runtime, which iterates with upgrades more slowly, and has a wide variety of issues to consider with each upgrade, including coordinating all the validators.
However, a smart contract is like a more modular module, which can be deployed on top any SDK chain, and interact with the x/ecocredit module, if available. It can extend the base ESCredit functionality already baked-in to the SDK.
In theory, the Smart Contract (or a series of them working together) could hold and release ESCredits, accept ESCredit deposits, automate and extend management processes, send out micro-payments based on performance metrics, manage bonding curves… lots of potential there!
The list of credit types is an on-chain parameter that can only be updated through a governance proposal. It is possible to remove a credit type from the list when updating the parameter. Credit classes can only be created using transactions.
When a credit class is created, the credit class defines a credit type and the credit type must be on the list of approved credit types at the time of creation. The credit type is stored within the credit class and removing the chosen credit type from the list of approved credit types would not affect the credit type stored within the credit class.
This is correct. A smart contract could be involved and the smart contract address could be listed as one of the approved credit issuers for a credit class. We are exploring different approaches for the listing/buying/selling of ecocredits in the following issue:
Picking up on this thread. We are planning to have a public dialogue where both non-techies, people outside of the US time zone and non-English speakers can participate.
In preparation for this I think it can be useful to
A- present the consequences of choice options on the table
B- present the context, translate the jargon
C- present the way we see decision making now and in the future
(not necessarily in that order)
A: what are the options actually? It’s not yet clear to me. I see a proposal but I don’t see different versions of this need being met. What I understand is that RND proposes to make a list of addresses that can in future propose Credit types. If not in this way, how else can the desire for a diverse range of credits be organised? And what would these options mean for stakeholders?
B: The jargon is not self-explanatory. It requires a glossary or an infographic to make sense of. Credit class and type and credits make up a world of categories, but when does a class become a type? Is there a meta logic? Ideally there would be a reference to the ecological world - eg: types are about elements (earth/water/air/life forms) and classes are subsets of these.
C: I assume we will evolve the way we decide once more actors are involved. Today’s collective is at an intermediate stage of evolution. How can we keep this in mind when future actors are not physically with us? Crazy thought alert: how about someone embodying this “next generation” and giving them a voice? Or is that the job of the Foundation?
RND Inc is proposing that, FOR NOW, we have a governance function for the community of token holders to vote on an allow list of Credit Class admins, which can then create any credit class they see fit. This isn’t the end state of where we want to be in relationship to management of the registry program on chain, but it is a first step. In a practical sense this specific proposal commits the community to upgrading to the regen ledger 2.0 software, without anyone on the allow list as a credit creator. That means there will be a subsequent governance process around the details of credit class admin allow list. RND is fully committed to stewarding a process of progressive decentralized in which Regen Registry (the list of approved credit classes, methodologies, issuers, credit types etc) is governed by the appropriate community stakeholders. If we are incapable of successfully managing that process AND OR there is independent desire to innovate totally outside Regen Registry program the community can add other addresses to the credit class admin allow list.
This is very true. I was just talking with @corlock and @S4mmyB about this and I think we will have some diagrams and more detailed glossary coming for the current terminology.
credit classes and types are two different concepts. a credit class is something like grasslands carbon plus. The concept of a credit class is to have a land use approach that produces a CREDIT TYPE like Carbon, or Biodiveristy. Carbon is the first credit type that will be on-chain as a definition, with others following soon we hope. My understanding of a credit class is that it is a way of creating a category of credits with an approved list of methodological approaches to achieve credit minting. It is a sort of meta-standard allowing, for instance, a Verra grasslands carbon methodology to be used, or a regen generated methodology, or a gold standard methodology to be used by a project developer - land steward partnership to monitor and quantify and verify carbon (or other credit types) outcomes. A credit class admin has the ability to link different methodologies for verifying the crediting outcomes of a credit class.
I do think that embodying the voices of future generations is the job of the foundation. However it is all of our jobs as well. But uniquely the foundations role is focused on good governance and stakeholder inclusion. RND inc’s role is to build and ship open source software and science solutions to enable the functionality that aligned economic incentives with ecological health. In the short term RND is very focused on getting credits to a growing market to create enough economic space for the Regen ecosystem and approach to grow and flourish, and support alternatives to carbon credits, different approach to ecological accounting and a more robust and participatory process to emerge. This is a tiny step to make it possible for regen network to serve market demand with curated, high quality carbon credits. The primary market forces at the moment have to do with getting credits onchain and to market. We all understand that the transformative vision and intention is to create a stakeholder owned and governed market and science infrastructure, and this is the first tiny step in that direction.
I would note that the larger permissionless and decentralized community of regen network beyond RND inc and Regen Foundation does not have the limitations that you speak of. I would also note that the theory is not universal participation in regen ledger governance, but participation of stakeholders who will use and govern the infrastructure being built. Not everyone will be able to for a variety of different reasons. Other reasons stakeholders wont be able to engage include digital literacy and ideological dissonance. To circle back to my point about the larger community: we are building an Open source and permissionless protocol. The institution of Regen Foundation or RND inc follow US governmental legal frameworks, but other network members are not beholden to our limitations. In addition to the freedom our public PoS based system provides for censorship resistance and participation, any group can fork regen ledger and still interoperate via IBC, making it easy for a group to engage meaningfully without censorship towards a shared goal of regeneration.
Yes, additional details and technical docs, including the binaries for the upgrade would be included in a second proposal that is purely technical in nature, then in another proposal for RND and other candidates to be on the credit admin list
Yes, this means that the actual upgrade will be forthcoming. Date pending success of the signalling proposal.
Great to see the progression of RND’s pioneering approach to build out the onchain ecological credits market. Looking forward to a successful outcome for the signalling proposal.
My thoughts on the credits in terms of being transferrable are that in these early days, it would be good to have maximum flexibility, and also maximize progammability for all the different credit buyers and their own respective Governance use cases that are potentially quite different to Regen Networks own Governance requirements.
For example a corporate buyer of credits may need the ability to buy / sell the credits according to their circumstances, for example if their emissions are less than expected due to better ecological / emissions performance that year, they may need to sell the extra credits that their Governance procedures require of them. Many corporate buyers need the flexibility year on year to buy and sell credits according to their emissions impact for that particular year. For biodiversity credits it is very much an emerging area. Meeting that market where it is right now with maximum flexibility within reason but also maximum programmability for different buyer use cases, seems an ideal balance. For example some credit buyers will require that the credits are retired immediately, and that could be enforced with programmability. Likewise someone who needs to be able to buy and sell, to match their emissions profile, can also be enabled through design approaches, and also programmability.
Great ideas @earth — welcome — it’d be awesome to organize a group of participants and workshop ideas like this. And also to weave in some of the scenarios and implications that @patogit has shared
I voted yes on this signaling proposal @Gregory_Regen. I’m excited to see the new wave of participation, activity, and interest as these building blocks come online. There is plenty of room for a diversity of solutions and models to be created upon these foundations — “diversity is an evolutionary strategy for success”, as one of my mentors likes to say
(Preface: this idea just occurred to me, and honestly doesn’t solve the matter of land theft, and might be reasonably rejected as insufficient by specific indigenous peoples. I share it here as an idea that would need way more reality-checking before we could even consider implementing it.)
How about inside the ecocredits modules, building a geographical database of unceded indigenous lands around the world (in other words, land stolen from indigenous peoples, either by breaking treaties or by skipping the whole treaty process), and putting a software-programmed limit on credit generation and offsetting in those areas? Something like:
credits generated from stolen land have 90% of their income withheld and transferred to the peoples the land was stolen from. In the case of areas where the indigenous inhabitants cannot be contacted or are not clearly organized, those funds would go to an organization chosen by recognized indigenous movements.
credits purchased by an entity operating on stolen land are obligated to put an equal or greater amount of money towards a fund controlled by the people the land was stolen from.
However, these ideas remain in the realm of money, and really, the issue isn’t (just) about money. Governance is way more important than money. The systems of government and governance imposed on stolen lands must go – decolonization isn’t necessarily about kicking out all the settlers (depends on the context), but tends to be more about stopping the colonial government, and creating a new government led by indigenous peoples, and taking into account the settlers who are now part of the reality in that land.
So, maybe in addition to money, there could be a governance requirement, such as “in order to generate or acquire credits, one must hand over meaningful decision making to the people the land was stolen from.”
Again, this needs to go through the filter of the larger question of whether the peoples, nations, and organizations even want to participate in the financialization and tokenization of ecosystems, or if they prefer other means of coordinating land use, local economies, cultural regeneration, and self-governance.
Let’s consider how much land worldwide was stolen (and continues to be stolen) from indigenous peoples. I know Regen Network mentioned (and maybe created) a protocol for land title verification before emitting credits, but that doesn’t take into account stolen land, broken treaties, or the fact that while indigenous peoples and local communities live in and manage apx 50% of land worldwide, they only have formal legal rights to apx 10% (source: The Tenure Facility) (and that’s just the situation right now, not taking into account historical theft). So, a simple review of land titles at a government office isn’t actually a sufficient protocol for verifying who has rights to a particular plot of land. Where can we find the land rights verification protocol that will be used for ecocredits on Regen Ledger?
Regen Ledger v2.0 supports the on-chain creation of permanent locked accounts through the MsgCreatePermanetLockedAccount Msg and via CLI. These special types of accounts are intended to be used by Regen Foundation for seeding Community Staking DAOs, wherein the initial REGEN funds distributed to these accounts must be permanently locked and only usable for governance and staking.
Given that the Community Staking DAOs are still being designed, I wonder what will happen if, for example, an error occurs in the key management of a DAO, or if a DAO forms and then needs to change somehow (maybe dissolve, maybe merge with another CSDAO). Given this implementation of permanently locked accounts, would the modification of a permanently locked account require an on-chain governance process? For example, a public vote saying “The CSDAO number 5 has become defunct, and Regen Foundation wishes to reclaim and reallocate those tokens, so here are the technical steps to modify that.” Or, what’s the plan? @Gijs_Spoor@corlock ?