Balance/Denom credit design

[aaronc]

Summary

This proposes an architecture for ecosystem service credits (#107) based on the existing Cosmos SDK x/bank and x/ibc/applications/transfer Coin model.

Problem Definition

See #107

Proposal

This is based off of work done in https://github.com/regen-network/reDAOmint/tree/reDAOmint/x/ecocredit and updated to actually use an updated x/bank under the hood.

In ADR 001 a convention for modules defining a "namespace" of denom identifiers is outlined.

We define a denom identifier for a credit batch as: fmt.Sprintf("ecs/%s/%s", classId, batchId) where classId are batchId unique string identifiers for the credit class and batch.

The ecs (ecosystem-service credit) module, defines the following Msgs for creating credit classes and batches, and retiring credits:

service Msg {
  rpc CreateClass(MsgCreateClass) returns (MsgCreateClassResponse);
  rpc CreateBatch(MsgCreateBatch) returns (MsgCreateBatchResponse);
  rpc Retire(MsgRetire) returns (MsgRetireResponse);
}

message MsgCreateClass {
  string designer;
  repeated string issuers;
  bytes metadata;
}

message MsgCreateClassResponse {
  string class_id;
}

message MsgCreateBatch {
  string issuer;
  string class_id;
  repeated BatchIssuance issuance;
}

message MsgCreateBatchResponse {
  string batch_denom;
}

message BatchIssuance {
  string recipient;
  string tradeable_units;
  string retired_units;
}

message MsgRetire {
  string holder;
  repeated cosmos.base.Coin credits;
}

message MsgRetireResponse { } 

Consequences

Pros

• integrates smoothly with existing Cosmos paradigm (sdk.Coin, x/bank and IBC transfer)

Cons

• requires upgrades to x/bank to be performant (Index supply by denom cosmos/cosmos-sdk#7092) and elegant (Do Proper Ocaps for x/bank (or not): A Case Study cosmos/cosmos-sdk#7093 and Use decimals in x/bank cosmos/cosmos-sdk#7113).

Neutral

• the ecs module will need to track balances of retired/burned coins

[robert-zaremba]

I didn't go through all details of the x/bank changes you propose, but instead of extending it, how about creating a new module which will extend it? With that we will keep x/bank minimal.

[robert-zaremba]

That new module could do things like: checked transfers / whitelisting, compliance etc...

[aaronc]

Some of the changes I'm suggesting to x/bank are relatively minor or should be done anyway IMHO. The ocaps stuff allows better encapsulation so other module can manage more rules based stuff like transfers/whitelisting on top of bank. I agree x/bank should be minimal.

[robert-zaremba]

It seams that #125 supersedes this issue, and it will be easier to keep discussion in one place. Shall we remove this issue , and other references to this issue (to keep focus in one place)? You can add Consequences section to a README file or to a PR description.