New tx message to reject a project.

• Only an admin from the issuer of the credit class referenced in the project is allowed to reject a project (See how this was done for Approve Project)
• It should not be possible to reject an already approved project
• It should not be possible to reject an already rejected project
• It should not be possible to issue credits for a project that has been rejected

Extra: Check and test that you can only approve projects that are in the NEW state (i.e. that you can approve a project that is already approved or rejected)

Tip: look at the code done in #354.

Depends on #382

See how this was done in 382

Currently, the binary name is "empowerchaind". To have a nicer and shorter name (similar to regen network that just uses "regen") we will change the binary to "empower".

No linting is added. Use whatever is standard for other chains. Do formatting at the same time?

Add to:

• Makefile
• CI/CD

Depends on:

• #2

We have to implement access control mechanism for transactions. For now similar functionality to Access Control from OpenZeppelin should suffice.

We should use mapping of address => []bool to achieve that.

We need to go over the different entities we have and look at where we need to set some limits to avoid abuse.

Potential examples include (but are not limited to):

• credit class abbreviations
• names for most entities

Some potential limitations to look for are:

• Specific business rules in terms of min/max-length
• Other rules

Start the migration from our current bash-based E2E tests to programmatic test like in the Cosmos SDK.

Definition of done:

• Set up, and document, a new E2E programmatic testing approach (similar to the one in the Cosmos SDK)
• Create tasks to move over existing E2E tests (in other words, don't do them all in this task)

Epic to keep track of all the tasks related to the first version of the Plastic Credit module

Any references to the old org "empowerchain" should be renamed to the new org "EmpowerPlastic"

Not sure if we can generate them from a changelog document or something, but we need better release notes into our release process.
The current release process is:

1. Tag a release
2. The tag triggers this GHA workflow https://github.com/empowerchain/empowerchain/blob/main/.github/workflows/release.yml

We need:

• Run all tests for every PR and push
• Simulation
• Linting
• Gen?

Set up CI/CD with scripts and earthly/dagger (TBD)

Currently, we don't get any of the nice cli client help with different types of proposals. So that needs to be wired up properly.

State sync doesn't seem to work now, can you please review and fix if possible.

empowerd version # 0.0.1

RPC node configuration
snapshot-interval = 2000
snapshot-keep-recent = 2

pruning = "custom"
pruning-keep-recent = "100"
pruning-keep-every = "2000"
pruning-interval = "10"

RPC link
SNAP_RPC="https://empower-testnet.nodejumper.io:443"

Error
3:12PM ERR snapshot manager not configured
3:12PM ERR State sync failed err="state sync aborted" module=statesync

The only one who should be able to update the applicant is the admin:

The fields that can be updated:

• name
• description

Just leaving this here to remember to remove the proofofexistence upgrade logic and reset the consensus version to 1 before next testnet and mainnet

https://docs.cosmos.network/main/building-modules/invariants

We should add proper invariant checks. Especially for balances.

Let's find a smart way to combine genesis validation and invariant checking so that we can reuse the code. Most of the checks and logic is the same, just different way of getting the data (perhaps some interface or something could do the trick?)

Depends on #382

Implement invariant and genesis checks for balances.

In chain/CODING_GUIDELINES.md we need to document our test strategy. To what extent we use different types of tests (unit, integration, e2e, smoketests, simulation), how we write them and where they are located.

Currently we have pretty comprehensive tests on genesis, but fully lack invariant check, which is needed for catch issues after upgrades for instance.

The goal for this task is to find a way to extract the logic done in the genesis validation and reuse it for invariant checking. The main difference will be how to get/fetch the different entities (JSON/Struct vs Keeper).

For reference on invariants: https://docs.cosmos.network/main/building-modules/invariants

EmpowerChain should be upgraded to SDK v0.46.X before we go to testnet, so LFG :))))

A plastic credit issuer is an entity that is allowed to create credit classes and issue credits to projects.

Creating a new issuer should be governance controlled, but needs to be possible for governance to hand over control to a sub-dao/group for easier management.

Access control for creating an issuer should therefore be limited to a single address, which is set by a governance parameter. The default genesis value should be set to the governance module.

• Document the Issuer state in x/plasticcredit/spec
• Implement an "IssuerCreator" param that can be changed with a gov proposal
• Implement create issuer msg
• Implement queries for "issuer", "issuers"
• Create a smoke test that does this as well from the CLI (see scripts/tests)

Unit and integration tests everywhere!

Simulation testing will be implemented after Cosmos SDK 0.47 is out and upgraded.

New tx message to update a credit class.

Rules:

• Only the admin from the Issuer that owns the Credit Class is allowed to perform this update
• Can only change the name

For now, we, unfortunately, need to pull out ignite because it hinders our ability to make design choices (design choices that would break scaffolding, for instance).

We will, however, need to replicate some of the functionality (scaffolding won't be one of them).

Things to do:

• Pull out everything ignite related
• Remove scaffolding comments
• Create Makefile with build and install
• Add protoc make commands?
• Add doc build command (Done in #7 instead)
• Update the readme file with instructions to build, generate, etc

Which code coverage tool? Not sure. Something cheap? Codecov is always an option.

Currently, all generated docs are pulled out of the repo.

We need to generate new swagger documentation at the very least, but probably would make sense to make a more holistic approach to documentation on empowerchain for both design, tech, APIs and users.

• Add status field to projects
• Issuer-only tx to approve a project
• Update issuing of credit to check if a project is approved first.

Set up simulation testing for what we have + add it to CI

Reminders:

• Update CODING_GUIDELINES
• Add non-determinism and perhaps a short sim test to the regular test pipeline
• Modules for import/export test

This repo will house all the empowerchain-related code, and a proper monorepo with good separation between different projects will make a lot of things easier and nice to work with (also: things that change together, go together).

The flow for creating a new project is currently called "Create Project", but a more accurate description of what is happening is that an applicant is registering a project.

So we need to rename and rephrase a few places to make this more accurate.

We currently only build for linux amd64. We should also build:

• Linux arm64
• Darwin amd64
• Darwin arm64 (M1)

Find a way to generate them into the existing docs site

Change all errors to the following format:
Err[Object][Reason]

Example: ErrProjectNotFound (instead of ErrNotFoundProject)

New tx message to allow updating a project

Rules:

• Can only be done by the admin from the Applicant that owns the Project
• Can only change the name of the project

An applicant is a collection organization or other type of plastic credit applicants.

Creating an applicant can be permissionless as they can't perform any harmful actions until they've been approved for a project. Therefore we need to keep track of when they were created so we can later add cleanup logic if it becomes necessary.

• Document applicant state
• Implement create applicant tx message
• Implement get applicant query (not sure we need a query for all of them, so let's wait for that)

We have to implement Credit Issuance logic. Boilerplate is already generated. There's a msg_server_issue_credits.go were we should put most of the logic.

CreditBatchIssuance is the MsgIssueCredits body and it contains:

• project_id - we can identify both Collector and Credit Class with it
• total_amount which is the overall credit amount to be minted for this operation. We might already make possible to issue both active and retired credits (Regen does that, TBD, @bjaanes)

batch_denom should be created from credit_class_denom and some kind of a suffix. The assumption for now is that the suffix should be generated automatically in some way, but we may want to change that so it can be provided by the user. Then we'll have to extend CreditBatchIssuance with the suffix, TBD, @bjaanes.

We should leave TODO for the access control implementation as it will be addressed by a different issue.

Issuing credits should update CreditBatch store, CreditDenom list and BatchDenomToCreditBalance store. Make sure that the suffix used for the store is the address of the credits' owner.