Proposal #4 Signalling Proposal - Permissioned Credit Class Designers and Regen Ledger v2.0 Upgrade

Hello Regenerates,

The Regen Network Development (RND) team is gearing up for the release of Regen Ledger v2.0, which will include the first version of the ecocredit module on Regen Mainnet. This first version of the ecocredit module will be permissioned, meaning only accounts approved through an on-chain governance process will have the authority to create credit classes. The list of approved credit class designers will be an on-chain parameter that will require a parameter change proposal in order to be updated. There will also be an on-chain parameter that determines whether the list of authorized credit class designers is in effect, which will be enabled on Regen Mainnet (authorized credit class designers required) and disabled on our test networks (no authorization required to create a credit class). With the upgrade to Regen Ledger v2.0, the list of authorized credit class designers on Regen Mainnet will initially be empty. The RND team plans to initiate a subsequent proposal adding an RND owned address to the allowlist, following the same process that other groups will be asked to follow.

The decision to make the ecocredit module permissioned is to ensure that we are providing the best user experience for projects looking to create credit classes and issue credits. Although we are confident that the ecocredit module is ready for Regen Mainnet, we are also aware that there may be some adjustments that need to be made when we introduce the data module. We believe a permissioned approach to the ecocredit module is the best path forward at this time, ensuring that authorized credit class designers are ready to work closely with the RND team to make the necessary migrations if and when the time comes. With this approach, the Regen Network community (REGEN token holders) will ultimately decide which accounts will be included as authorized credit class designers on Regen Mainnet.

Regen Ledger v2.0 also introduces the notion of “credit type” as an on-chain parameter for the first time. The default value includes an initial “carbon” credit type, intended to be used by all credit classes which use metric tons CO2 equivalent as a primary indicator / unit of measurement. The initial carbon credit type will be the credit type used for our own CarbonPlus Grasslands credit class, which will be the first credit class created if the RND team receives approval from the Regen Network community to be added to the list of authorized credit class designers.

The initial carbon credit type will have the following properties:


For more information about the ecocredit module, see the following RFC:


In addition to the ecocredit module, the Regen Ledger v2.0 upgrade will include an update to Cosmos SDK v0.43 and the addition of the feegrant and authz (“authorization”) modules. The feegrant module will enable the ability for a granter to grant an allowance to a grantee where the allowance is used to cover fees for sending transactions. The allowance can either be a periodic allowance that automatically resets after a set time or a one-time allowance that has a one-time spending limit. The authz module will enable a granter to grant an authorization to a grantee that allows the grantee to execute messages on behalf of the granter.

For more information about the Regen Ledger v2.0 upgrade, see the following blog post:

A Ledger For The Earth

The purpose of this post is to lay the groundwork for a signalling proposal that the RND team is planning to submit after the Regen Network community has had a chance to ask questions and provide comments. The signalling proposal will include an overview of the permissioned ecocredit module approach, the changes included in Regen Ledger v2.0, and the criteria and process for becoming an authorized credit class designer. The criteria and process will be further specified in an accompanying document hosted on IPFS or within the proposal itself. In short, the criteria for becoming an authorized credit class designer will include the following:

  • demonstrate a well-thought out credit class design
  • demonstrate desire and capacity to work with the RND team on data migration for credit class metadata (should the schema change in Regen Ledger v3.0)
  • socialize candidacy as a credit class designer with the Regen Network community via a forum post and engaged discussion

Once socialization has been conducted, formal credit class applications will be processed via an on-chain parameter change proposal.

The results of the signalling proposal will be interpreted as follows:

  • A Yes result on the proposal would provide a clear signal that the Regen Network community accepts and understands the decision made to pursue a permissioned ecocredit module design, the upgrade to Regen Ledger v2.0, and the criteria and process for becoming an authorized credit class designer.
  • A No result on the proposal would force reconsideration of the upgrade to Regen Ledger v2.0, the permissioned ecocredit module design, and/or the criteria and process for becoming an authorized credit class designer.

Please add questions and comments below. Thanks!


Thanks for this detailed post Ryan, very exciting. The permissioned approach makes a lot of sense at this time.

Can you provide a little more regarding the process to become a credit class designer, thoughts or plans. Also I’m curious how the wider community could help, permissioning or education or vetting for example, towards a decentralized approval process.

Thank you!


Thanks @swidnikk!

We are still sorting out the details and open to ideas from the community but I’ll attempt to elaborate on the points above with my own thoughts and understanding.

demonstrate a well-thought out credit class design

A credit class will be associated with a methodology, so an applicant would need to provide a document that outlines a proposed methodology. The RND team has created a flowchart that outlines the process for creating a methodology and a methodology framework that provides a general structure for developing new methodologies. These documents are also linked on the recently updated registry website under the create a methodology section.

As an example, the RND team plans to submit a proposal to be added to the list of authorized credit class designers in order to create a credit class for the GHG and Co-Benefits in Grazing Systems methodology, which will use the initial “carbon” credit type described above.

demonstrate desire and capacity to work with the RND team on data migration for credit class metadata (should the schema change in Regen Ledger v3.0)

This could be accomplished by socializing commitment and understanding within the proposal and by being an active member of the community.

socialize candidacy as a credit class designer with the Regen Network community via a forum post and engaged discussion

All governance proposals should start with a forum post outlining the proposal that links to the accompanying documentation and that socializes commitment and understanding to work with the RND team. The forum post should receive general support from the community before being submitted as an on-chain governance proposal.

I’ll have to think a bit more about how the wider community might be able to help aside from reviewing the proposed methodology documentation and engaging in discussions. I think the links above are a good place to start for community members looking to better understand the process for developing a methodology and what a methodology might look like.


Really awesome! Thank you. Enjoyed reading and reviewing the support documents you provided.

Curious, if needed, would the process be the same for removing an already approved EcoCredit Class Designer, via proposal? And the same for removing an EcoCredit Classe itself, if a class was to be deprecated?



Thanks @I-A! Great questions.

The removal of a credit class designer would require a parameter change proposal as well. The process would be slightly different as the conditions might vary, but in general there should be a post in the forum outlining the proposal before it is submitted on chain, giving the community a chance to ask questions.

I’m not entirely sure how we would handle a credit class needing to be deprecated. I don’t think we would want to remove the credit class but it might be worth considering a feature that would mark a credit class as deprecated and prevent further credits being issued from that credit class. I’ll have to think a bit more about how that would work but it’s definitely worth considering!

1 Like

Hi @ryanchristo , thanks for the details! And congrats to @aaronc and Cory Levinson and the rest of the crew for the engineering and development!

From the technical side of “does the code seem reasonable”, I trust the development team, and if they say it’s ready, then I’ll go with that… although… I wonder if some sort of 3rd-party audit could be done, so that folks like me who aren’t going to read or understand all the code, we can look at the analysis by someone else. Who could do such an audit? What level of detail or formality? Maybe some of the IXO team, or some other team that knows Cosmos SDK and also understands the ecocredit module use case? Also, I think a testnet would make sense before a formal on-chain upgrade proposal – because it’s much wiser to make a decision after testing. So, what’s the testnet plan? I’ve heard “We’ll run a testnet” and I’d like more details.

From the practical side, I have lots of questions.

Structure and process

I see that in practice, there are now credit types – those are not mentioned in the RFC. Looks like a credit type is like a super-class, where all the carbon-focused credit types would be instances of the carbon credit type… am I understanding this correctly? So, if we want a credit based on biodiversity, first we would have to create a biodiversity credit type, then create our-great-biodiversity-credit-class as an instance of that credit type?

And, just to add confusion to type/class distinction: On the Kasigau Corridor project profile, it says:

standard: VCS
credit class (type): REDD+

I’m guessing it means:

  • credit type: carbon
  • credit class (methodology): Verra VCS REDD+

Or maybe I shouldn’t expect the on-chain module language to coincide with the registry language… but I think the system will be clearer if the language is consistent.

Deprecation of credit classes

I think being able to deprecate a credit class is important, because over time I bet that some methodologies will be upgraded and others will be deemed obsolete.

Language about taking a credit out of circulation

I think it would be a bit silly to “burn” carbon credits (as mentioned in the RFC) – even worse for biodiversity credits! “Retire” seems more sensible. Other ideas: “bury the credit” (though this won’t make sense for other credit types besides carbon), “commit the credit” (although this sounds like being committed to the hospital, I mean it more like entering into a committed relationship)… a fruitful area for more ideas, but for now, “retire” seems generic enough.

Interface, Methodologies, Regen Ledger and Regen Registry

I see the stuff about peer review to create a methodology on Regen Registry. So, what’s the connection between Ledger and Registry? Could a whitelisted account create a credit type and a credit class on Regen Ledger (on the blockchain, in other words) without going through the whole Regen Registry process? Is the Registry a user interface to the chain, or an interface to its own data set, or not an interface at all? At this point, the Registry exists even though the ecocredit module isn’t live yet, so obviously the Registry has its own data set for now – what’s the future plan.

I see the list of accepted 3rd-party methodologies – does this mean that all of those 3rd-party methodologies are carbon-focused, and each would have its own credit class of the credit type carbon? And then the issuer of those credits would be the agency/organization that created the methodology and does the certification? So, those entities will have on-chain accounts and some sort of interface in order to issue credits? Have any of those projects expressed interest in putting their entire database of projects on the Registry and/or on-chain?

I see that there’s already a project in the registry using a 3rd-party methodology – the Kasigau Corridor project with the Verra method. Maybe this can be an example to explain answers to some of my questions.

Retiring credits

In what circumstances are credits retired?

Feegrant and auth/z

Your explanation of the new modules describes the code-level, but not the human use case rooted in the Regen Network vision. I’ve heard an explanation of how this can be useful in practice, and I think it’s worth explaining here. In other words, why does this matter, and how will it be useful for the vision of Regen Network?

As I understand, it will someone let land stewards or verifiers run txs to put data on the chain, without having to have their own accounts, and this will make Regen Network more usable for more people. Can someone fill in the gaps with a more detailed vision?

Credit class abbreviations

I see in the code that:

credit type abbreviation must be 1-3 uppercase letters

So, will there be any controls about not using widely-meaningful three-letter codes, like BTC or USD or ETH, in order to avoid confusion? This is also an interface question, going back to the Regen Registry vs Regen Ledger matter.


A few quick updates.

As part of our internal audit process, we’ve decided to change “designer” to “admin” within the credit class because this a more accurate description of the planned permissions of this account; the designer of the methodology associated with the credit class may not be involved in the process of managing the credit class on-chain. For example, one of the planned permissions for this account is the ability to update the list of credit class issuers.

The “allowlist” has also been updated to help clarify what action can be taken by the addresses listed. The allowlist includes addresses that are allowed to create credit classes and the creator of a credit class only becomes an admin of a credit class after creation. When an address is listed on the allowlist, they technically have the ability to create as many credit classes as they would like, which is another reason this distinction is important to make. The community also needs to take this into consideration, trusting that any account listed would not abuse this power.

Thanks @patogit for your thoughtful response! I’ll try to answer some of your questions and maybe some other team members can jump in to help clarify others.

The RFC reflects an earlier design and the credit type was added later. We are working on some documentation updates to provide updated definitions of key concepts as well as some UML diagrams to help visualize the relationship between credit types, classes, and batches.

It’s not a super-class in the sense that a class is an instance of the carbon credit type. The credit class is stored on-chain and references a credit type also stored on-chain.

There is a hierarchy in some regard to how they are related. The ID for each credit class is constructed from the abbreviation of the credit type and a sequence number. For example, the first credit class of the “carbon” credit type will be C1 where C is the abbreviation and 1 is the sequence number. The denomination for each credit batch starts with the credit class ID, so the credit type is reflected all the way down to the credit batch level.

If you want to create a credit class associated with a “biodiversity” credit type, the “biodiversity” credit type would need to be added to the list of credit types (an on-chain parameter) before you can create the credit class.

Retired credits are credits that cannot be transferred between accounts nor can they be unretired. Retired credits are equivalent to burned tokens with the exception that retired credits are actively tracked after being retired. Retiring a credit implies that the holder of a credit is “consuming” the credit as an offset.

1 Like

Thanks for such thorough questions @patogit! I can provide a bit more context from the perspective of RND’s engineering team when it comes to how we’re thinking about audits more generally (and for this release).

When we launched our mainnet for Regen Network, really the overwhelming majority of our codebase was essentially the same as any other Cosmos SDK based blockchain. The Stargate release series of the Cosmos SDK (which Regen’s mainnet was based off of), did go through an extensive audit & testnet process (which involved a formal external audit of IBC by the Informal team).

Similarly, 3 of the 4 new features in Regen Ledger 2.0 are pieces that have already been audited & tested as part of the SDK’s release process for v0.43.0 (fee grant, msg authorization, and support for in-place store migrations for chain upgrades).

That leaves us with the ecocredit module as the main piece of Regen Ledger 2.0 that hasn’t already been audited, and we decided that the best path forward was to follow the process we did for v0.43 version of the Cosmos SDK, and have our team do an internal audit of the module prior to release.

The ecocredit module is more or less a straight forward cosmos-sdk module, our method of tracking account balances closely models the method used by the x/bank module (which stores REGEN balances), and the metadata layer is stored using an ORM module (which we designed & built for the group module - and is also having an audit done on it by our team for this release).

I do think that as we work on more features in the future, we should consider doing formal external audits with 3rd parties, but it likely won’t make sense unless we are developing something more architecturally complex like the IBC module, which is the one recent case where a core Cosmos SDK module had a formal external audit.

1 Like

We just recently setup the Redwood testnet which will be used for doing a “dress rehearsal” for the mainnet upgrade. You can find the details for the testnet The chain-id for redwood is regen-redwood-1 and you can find the faucet by running the following command.


Ill have a more detailed plan for upgrading redwood as we get closer to the date feel free to reach out to me “Dan P | RND” on Discord if you have any further questions. Thanks Patrick!

Thank you for changing the language from “whitelist” to “allowlist”! More precise language that leaves behind categories with a long, painful, racist history. This attention to detail matters.

The “admin” role name makes sense to me. Yes, credit design involves lots of people, and administering the credit class on-chain can be done by fewer people.

Will the allowlist admin role include credit type creation, or will there be a super-admin role for credit type creation and a second allowlist?

I don’t understand the “on-chain parameter” situation exactly. There are parameters that define the behavior of various modules, and they are listed here: Aneka - Block Explorer . Those parameters are changed via on-chain governance proposals. If I understand correctly, we will add to that page an ecocredit section, and the only parameter changed via on-chain governance votes will be the allowlist addresses. Those addresses will be able to modify the list of credit types, credit classes, and credit batches… which are also parameters (of the same sort?) but not modifiable via on-chain governance?

I don’t have advanced understanding of on-chain parameters vs on-chain data vs on-chain something elses, so maybe I’m mixing things up here. Please correct me!

Ok, so to make the example more concrete: an oil company chooses to buy offsets (we’re not talking about regulatory obligations because Regen Network isn’t qualified for that arena yet, right?), so they buy the credits and then retire them, and count that as part of their annual portfolio. Any other examples or details to add in order to understand the situations where credits are retired?

In reply to @corlock 's post about audits:

How much would an external audit cost? As you mentioned elsewhere, there are now over 2 million REGEN in the community pool. The 7-day low price for REGEN is USD 3.41. That means the community pool is worth over 6.8 million USD. I think code audits could be a very reasonable use for some community pool funds, but I have no idea how much an audit would cost. RND Inc. is paying for the development, so the community pool could pay for an audit.

Thanks for the replies! There are still some unanswered questions, mostly about the registry, interfaces, and the credit class abbreviations.

Ok, great! I see that it launched August 18th. Not sure how I missed that announcement. I’m comparing the genesis.json files for the current mainnet and for the redwood testnet, and I see some parameter differences that might give insight into things changing about the network, or might just be things to make the testnet easier to run. The parts I suspect are relevant seem to be focused on making the blocks hold more data, and something about IBC. @corlock Will these parameters get updates on mainnet as well?

--- genesis-regen-1-params.json
+++ genesis-regen-redwood-1-params.json

-  "chain_id": "regen-1",
+  "chain_id": "regen-redwood-1",
   "consensus_params": {
     "block": {
-      "max_bytes": "200000",
-      "max_gas": "2000000",
+      "max_bytes": "22020096",
+      "max_gas": "-1",
     "evidence": {
-      "max_age_num_blocks": "1000000",
-      "max_bytes": "50000"
+      "max_age_num_blocks": "100000",
+      "max_bytes": "1048576"
   "app_state": {
     "auth": {
       "params": {
-        "max_memo_characters": "512",
+        "max_memo_characters": "256",
     "ibc": {
         "params": {
           "allowed_clients": [
+            "06-solomachine",

1 Like

How to put limits on reselling credits (a.k.a. stopping speculation)?

The example I started earlier:

…continuing that example:

If the oil company didn’t retire the credit, then they could wait for the price of the credit to rise and then sell the credits at a profit. Considering that the credits might have been sold by a federation of forest peoples in order to finance their community processes, or a farmer growing potatoes and wheat, I would prefer that all financial value generated by the credits go to those forest peoples or farmers, and not to the oil company – more profits to the oil companies based on the labor of forest peoples and farmers would just be another repetition of the system my family is trying to compost, where the financially wealthiest companies in the world profit off the financially poorest people in the world, and then use their money to keep hurting more people.

Would it be possible to create a credit batch, class, and/or type that is limited to only one transfer? This would be similar to something mentioned elsewhere: marking certain credits as retired at the moment they’re minted. This way we know that all the financial value of the credits went to the people who created them, not to brokers, intermediaries, and others looking to extract value without contributing value all while free-riding on the good reputation of the people doing the real work – there’s a long history of certain people using the names and images of native peoples (and others) to sell t-shirts, NGO projects, weapons, and many other things, often without their permission, and we don’t want to see that repeated with ecosystem service credits.

Thinking long term, I guarantee that if credits based on my family and neighbors protecting and regenerating the forest are sold to an oil company or even an organic fair trade clothing company or some other nice people, and then they hold the credits while the price rises, and then sell the credits for a profit… if that happens, federations of native peoples and farmers all over the world are going to reject this system of “a marketplace of credits.” People are sick and tired of being used, and the ecosystem service credit scheme is already kind of suspect from the perspective of land-based peoples: oil companies give us money to regenerate our territory, but they keep doing harm elsewhere and to the climate? That’s already sub-optimal, and if people hear that the credit purchasers profit by holding and reselling, that will break people’s trust in this system.

Another way to talk about this is:

  • living systems (that include humans) are mentally divided into “services” that they “perform”.
  • those “services” are financialized – they’re given a value in some currency, based on either some market created by someone, or by other decision making methods.
  • you know what happens next with financialized assets: speculative bubbles!!!
  • and you know what happens while a speculative bubble inflates: a bunch of scams and meaningless projects get funded.
  • and you know what happens next with speculative bubbles: they burst!!!
  • and when a speculative bubble bursts: the people on the ground lose, the people behind those assets, they lose.

So, how do we avoid using land-based peoples as vehicles of further financial wealth concentration? How do we avoid a speculative bubble that in the long term hurts living systems instead of regenerating them?

So, is the solution for us as credit batch administrators to issue all the credits in a “retired” state? Or is there some other consideration here?

I guess this depends on the process of finding credit buyers. If we find the buyers first, and then mint the credits, we can issue them “retired”. If we mint the credits first, in order to demonstrate to buyers that we’re serious, then we can mint them into our own account, and then transfer them to buyers and retire them immediately…? Who can perform the “retire” transaction on the chain? The credit class admin, or the credit holder, or both? I imagine the answer is “the credit holder”… because if someone purchases a credit, it’s theirs. Please explain.

Edit: I’ve now made a separate thread for this part of the conversation:


Hi @patogit! Thanks for sparking such an engaging conversation. You bring up some really great points and it’s nice to hear someone from outside our team thinking about a lot of the same things we are.

Regen Ledger & Regen Registry

To answer your question about if an allow-listed account could create a credit type and a credit class on Regen Ledger without going through the Registry, the answer is yes. Regen Ledger and Regen Registry do not have to be used in unison. If you wanted, you could put fourth a governance proposal for an entirely new credit type, then create a credit class and then issue credits using that credit class. As @ryanchristo mentioned earlier, however, credit classes must be well thought out and the credit class designer should explain how a proposed credit class can be used in conjunction with a methodology (or set of methodologies) to back claims and agreements related to ecological state.

So where does the Registry fit in? Right now, the Regen Registry operates almost exactly like other registries such as Verra or Gold Standard. It provides land stewards & project developers with with a platform list their projects, tell their stories, and sell the resulting credits using existing methodologies, or ones they develop together with scientists & credit designers. The data backing these claims are stored the Registry itself (see on the Wilmot, Woodburn, or Cavan project pages for examples).

In the future, the Registry will interface with the ledger such that ecological transactions happening on the Registry will be stored on chain. This includes everything from uploading data to back up a claim, to issuing and listing credits, providing curation opportunities to rank credits based on things like buyer preference or scientific rigor. But building these kinds of interfaces take time, and we need think through how we can serve the needs of different actors (buyers, land stewards, credit designers, and methodology developers) in a way that makes participation easy while providing a diverse set of functionality.

Third Party Methodologies

All of the project/method developers and credit designers working with in Regen Network have expressed interest in putting their entire database of projects on the Registry, and eventually on chain. Right now all the methodologies on our registry website are carbon-focused, meaning they share the credit type carbon. But our platform is designed to support a variety of ecosystem service credits that focus on much more than just carbon.

Some of the non-carbon examples currently in development include biodiversity credits, where the crediting unit is based on number of species present, soil health credits based on a set soil health properties, and credits focused practice adoption where the crediting unit is measured as the number of hectares successfully converted to regenerative land management.

Each of these credits will need to have their own credit type and credit class. The proposer of these new credit classes, as well as the issuer of the credits themselves could be the agency/organization who created the methodology, or a trusted third party (ie the credit class administrator). As I mentioned earlier, we will eventually have interfaces for credit class administrators and issuers to propose new credit classes or mint credits without having to go through the CLI or API, but such functionality is still in the design stages.

Credit Classes on The Registry vs Ledger

I saw this comment in your post and thought I would briefly explain how credit classes are being presented on the Registry.

Generally speaking, credit classes represent different types of ecosystem service credits and claims made about ecological state. Reforestation projects, grazing projects, and biodiversity projects all focus on different types of ecosystem services, and have their own set of project eligibility requirements, measurement standards, and verification requirements. Regen Registry credit classes documents, such as the GHG & Co-Benefits in Grazing Systems Credit Class, are intended to provide a detailed description about credit classes and the kinds of claims they represent. Our team is currently in the process of writing documentation describing credit classes along with UML diagrams to help visualize the relationship between credit types, classes, and batches. In the meantime I thought I would present this example to (hopefully) provide more insight into how we are working to describe credit classes consistently on both the Registry & Ledger.


The allowlist is for credit class creators. Addresses on the allowlist will be able to create credit classes. When a credit class is created, the creator becomes the admin of the credit class.

There is no super-admin role for credit type creation. Approved credit types are an on-chain parameter that require a governance proposal to be updated. Anyone can submit a governance proposal to update the list of credit types. The list will start with the “carbon” credit type.

Yes, these parameters can be changed via on-chain governance proposals. The allowlist for credit class creators is not the only parameter. The parameters for the ecocredit module include:

  • credit_class_fee is is the fixed fee charged on creation of a new credit class
  • allowed_class_creators is an allowlist defining the addresses with the required permissions to create credit classes
  • allowlist_enabled is a param that enables/disables the allowlist for credit creation
  • credit_types is a list of definitions for credit types

The addresses listed in the allowed_class_creators parameter will not be able to modify the list of credit types, credit classes, and credit batches. They can only create new credit classes. The list of credit types is an on-chain parameter that requires a governance proposal to be updated, credit classes and credit batches are on-chain data that cannot be updated using a governance proposal; they can only be modified by executing transactions.

1 Like

There are three options for retiring credits. When creating a credit batch, the credit batch issuer can choose to retire the credits upon issuance. When sending credits, credits can be retired upon transfer. When in possession of credits, the owner can choose to retire the credits.

When the owner retires credits, the owner is consuming the credit as an offset. When credits are issued or transferred in retired form, the recipient is consuming the credit as an offset.

Credit class issuers can choose to issue credits in a retired state. Credit owners can choose to transfer credits in a retired state. Only the owner can perform the retire transaction on chain.

The credit class admin is simply the account that created the credit class in this initial version of the ecocredit module. In the next version, the credit class admin will have the ability to update the list of approved credit issuers within the credit class that they administer.

1 Like

There are currently no rules to prevent widely used abbreviation such as BTC, USD, or ETH. The list of approved credit types is an on-chain parameter. The only way to update the list of credit types is to submit a governance proposal. The community could choose to vote against a proposal that adds a widely used abbreviation. The only restrictions at the moment are that the abbreviation is 1-3 characters in length and the abbreviation is unique.

One thing to note, the credit type abbreviation will not be used as the credit denomination. Credits use the credit batch ID as the denomination. The credit batch ID has the following format:


The credit type abbreviation is included in the credit-class-id, which has the following format:


Even if a credit type had a commonly used abbreviation, there should be no confusion.

Thanks @S4mmyB and @ryanchristo for the detailed replies :slight_smile:

I’m coming to understand that the Registry will be an interface to the Ledger, and the ecocredit module on the Ledger is being created largely to serve the Registry’s needs. Other projects (besides Regen Registry) might or might not use the ecocredit module, depending on their needs.

Transferability of retired credits

If I have a credit, and I retire it upon transfer to you, can you then transfer it again, or is the credit now locked in your account forever?

Offsets are off-chain

The “offset” logic isn’t actually implemented on Regen Ledger or Regen Registry, is it? I mean, a credit can be retired on-chain, but the meaning of retiring a credit isn’t defined here. The meaning of “holding a retired credit” depends on how a person, corporation, NGO, or government chooses to publicly talk about their retired credits, and/or perform audits on their credit portfolio using some 3rd-party system… am I understanding this the same way you understand it?

Governance of credit classes

I think this is a weird part of this proof-of-stake blockchain: decisions about credit types will be made by on-chain voting. Maybe this would make sense if the people voting actually knew about credit types, ecological and cultural regeneration, credit design, and beyond. However, I suspect that:

  • (A) most votes will be made by validators, not token holders (because most token holders purchased their tokens as a financial investment, not out of an interest to participate in the design and governance of Regen Network), and
  • (B) most validators have knowledge about running validators, not about regeneration or credit types.

This means that the decisions about credit types will be made by the wrong group of people, in the sense that they generally don’t have knowledge about the decision. I think governance and decision making systems that function well place decisions in the hands of the people affected by decision and the people with relevant knowledge about the decision, and validators and tokens holders do not meet either of those criteria. Who’s affected by the decision? People who want to design and issue credits. Who has relevant knowledge? The credit designers (this includes farmers, native communities, scientists, software developers, economists, and more), and maybe other people.

So, is there a way we could handle governance of credit types (and the ecocredit module in general, including the allow-list) in a way that aligns decisions with consequences? Maybe the formation of separate decision making body for the ecocredit module?

Avoiding speculation that harms regeneration

This seems to fit better in its own topic, so I made a topic for it:


Two alternative ideas here that would still need to be approved by on-chain governance to initialize, but then could take it from there:

  • Community Staking DAOs (potentially delineated as holders of “cREGEN”—permanently staked REGEN) alone could decide via on-chain governance about credit creation, at the exclusion of general token holders
  • Or Regen Consortium (potentially via Regen Foundation’s cREGEN)

I assume there’s a technical roadmap that would need to be established here on how to differentiate between these different kinds of token holders, and I’m not sure what sort of complexity this would introduce (moderate, challenging, or untenable).

I will say these questions of “who decides who decides,” as Zuboff would put it, have been on our mind since Regen’s inception, and inspired the CSDAO model, and could further influence Regen Ledger’s evolution…