Ability to List/Buy/Sell Ecocredits

[dtkong]

Summary

With the ecocredit module allowing the creation and transfer of ecocredits, we'd now like the ability to list, sell, and purchase. This will be minimum viable functionality towards an ecocredit exchange.

User stories

• As an issuer, I'd like the ability to list and sell an ecocredit at a particular price, so that I can monetize my ecocredits.
• As a user, I'd like the ability to purchase a listed ecocredit at a listed price.

Problem Definition

Issuers need the ability to not only create and transfer ecocredits but also market them.

Proposal

• Issuer can list an ecocredit at a fixed price denominated in $REGEN
• Buyers can purchase a listed ecocredit at the issuer's fixed price.
• TBD whether an ecocredit is automatically-retired upon purchase or whether there's a choice of the seller to auto-retire vs let the buyer retire. Update: an ecocredit is auto-retired upon purchase.

[technicallyty]

It might be cool to implement a credit marketplace using CosmWasm, we could deploy some marketplace contracts to other chains and have our credits be supported everywhere cosmwasm is supported.

[clevinson]

I think there's a few different ways we could choose to build something like this out, one of which is the CosmWasm approach Tyler's illustrating. I think using CosmWasm may require that we implement #407 first though. Cosmwasm has some basic x/bank integrations, but not sure how easy it is for cosmwasm to integrate / interact with other module's substores.

Here's the options as I see it. All of these could implement the desired functionality, but have different tradeoffs. Happy to hear others' thoughts w/ more pros&cons too!

1. Cosmwasm smart contract

We integrate CosmWasm (which has long been discussed, though currently still TBD exactly when) and write a basic CosmWasm smart contract that can hold assets of any denom in x/bank (which includes ecocredit assets) and offer them for sale at a fixed price. Seller can withdraw unsold credits from the contract at any point in time.

Pros:

• reusable code (any chain that supports cosmwasm could have this contract deployed and provide the exact same functionality). In fact -- if we do a bit of digging, this type of cosmwasm smart contract may already exist off the shelf from another project?
• bringing CosmWasm into Regen (something we've talked about for a long time, but are still waiting for the initial use case to prioritize it)
• Can be deployed to a live chain without a coordinated software proposal & upgrade (we would still need one initial upgrade to integrate cosmwasm into Regen Ledger)
• reusable by other assets (not just ecocredits, but potentially also eco-NFTs if we have those on-chain in the future)

Cons:

• requires a bit more overhead (introducing cosmwasm, when that's not strictly necessary to satisfy this user story)
• smart contracts cannot be easily upgraded (I think?) via state-migrations, but rather new additions to this functionality would likely come as new contracts of an upgraded version rather than upgrading an already deployed smart contract

2. extend x/ecocredit functionality

This approach would basically mean keeping the selling functionality scoped to x/ecocredit module. Assuming we migrate the storage of tradable ecocredits to x/bank, would this be a use case for ADR033 / inter-module communication?

Pros:

• only building for the known use case, so less chance of scope creep from trying to build generic list/sell functionality
• can be more easily integrated w/ existing ecocredit module functionality (allow for creation of listings that force auto-retire on sell)

Cons:

• not as reusable if we want to list other assets later down the line (e.g. NFTs, derivative shares of basket assets?)
• any later upgrades in functionality are tied to a software upgrade & gov proposal cycle

3. new native SDK module for "market" functionality

This option entails a specific new module w/ its own msg server & queriers for providing basic marketplace functionality. In its most generic form, we'd probably take an approach of integrating with x/bank? This would be similar to (2) in terms of code complexity, but likely more similar to (3) in terms of use cases & API.

Pros:

• reusable by other assets (not just ecocredits, but potentially also eco-NFTs if we have those on-chain in the future)
• reusable by other chains who want similar functionality

Cons:

• any later upgrades in functionality are tied to a software upgrade & gov proposal cycle
• potentially less straight forward to do custom logic tied to ecocredit functionality (e.g. auto-retire on sell)

[dtkong]

1 and 2 were the initial (albeit uninformed) approaches that came to mind. 3 sounds intriguing though!

My initial thoughts was also that there was a lot of scope creep with 1. Based on @clevinson 's analysis there's considerable uncertainty. Although it may be worth time-boxing a spike to investigate.

Side note, why would we want to upgrade smart contracts via state migration ?

Ideally, there's a path of progressive enhancement towards whatever fully-featured exchange functions we might have in the future.

Some simple use cases to consider:

• A credit issuer wanting to stop the sale of a given credit batch
• A credit issuer wanting to sell a portion of credits issued
• A credit issuer wanting to split proceeds of credit sales amongst multiple addresses
  Could perhaps get around these by transferring credits to another address upon issuance or when wanting to stop the sale.

Also quick note, seems like for the immediate future we will be auto-retiring credits upon sale. I'm not sure if this applies to other transfers out of the issuer's account or if the act of "purchase" is the trigger.

[dtkong]

Relevant DEX architecture designs:
#406
#395

[clevinson]

@aaronc noticing your PR in #560 takes the 2nd approach outlined above.

I imagine if we're having NFTs or other non-ecocredit assets on the ledger we would also want these to be bought/sold through the same marketplace functionality as ecocredits. This may be a case for us having a distinct module for buy/sell functionality.

The same goes if someone wants to make a direct listing for a basket asset.

Can you provide a bit of context as to why you think we should just be implementing this inside ecocredit itself?

[aaronc]

I am assuming that an order book model would need to allow buy orders that don't just target specific credit batches but rather specific criteria for what credits satisfy the order. i.e. "buy 10 tons of carbon credits from 2019 or 2020 from Brazil, Colombia or Ecuador issued by Regen Registry". These would be set up sort of like search filters similar to how the basket functionality I proposed (#406). Unlike a liquidity pool model, however, which just uses these criteria to determine deposits into the pool, an order book would need to use these search filters to create indexes of orders and match them against batches in a batch auction. Such a system because it is index heavy and because the indexes are rather domain specific doesn't seem amenable to generalization. Or rather, we can probably make our lives easier and make the system more performant by designing just the filters and indexes we need for credits rather than an open-ended system like in #406. An order book IMHO is quite a bit more computationally intensive than a liquidity pool. Because the indexes we need depend specifically on things we have are pulling into the top-level credit model (dates, issuer, class, region, etc.), I think it makes most sense to simply do it in the same module. Also, we can't deal with (optional) auto-retirement with a generic model and I think we'll run into a bunch of edge cases which merit a domain specific design.

I would add that the liquidity model I proposed in #406 is more of a shortcut towards having a marketplace using existing AMM modules than something that will work well for our problem domain. The basket model while simple suffers from the fact that all the things in the basket are not actually the same and it may be hard to predict what buyers will want upfront when creating a liquidity pool and it will be impossible to change the basket to respond to changing market conditions. Like a basket of fruit at the market, this model comes with the risk that all the good fruit will get picked out leaving a basket of rotten fruit. If we remove the ability to pick specific fruit out of the basket and make it a blind grab bag that could be even worse in that a few rotten fruit spoil the bunch. At the end of the day, we don't yet know how buyers will make their choices and I think we do want a market where buyers can respond to new information and be selective in their credit purchases. In addition, the AMM model comes with significant legal liability hurdles for credits - maybe surmountable, but certainly non-trivial.

All that's to say that my current assessment is that we should start with a simple store model and proceed to an order book in x/ecocredit and probably forget about AMMs for the time being. It's more complex computationally, but that's what we have a whole domain specific blockchain for, no?

[paplco]

If there was a Regen Market Place, sort of like an App Store, with the ability to add a collection of Credits, NFTs, or even perhaps services such as Attestation/Verification ... would the buyer be able to add these items to their cart and execute one transaction to complete the sale? And what would happen if a certain item sold out just before execution, would the entire transaction fail? NFT marketplaces might have good example code bases for dealing with the buyer shopping experience.

As far as the catalogue to browse/search/query the available items, wouldn't this be done off chain through a web-based front end? The available items and their quantities could be polled periodically, refreshed by category as needed, and cached separately for display in the web store. And a wallet such as Keplr would be used do send payment for items in the user's cart and receive confirmation that the items were successfully purchased. So the only time a buyer would 'query' the chain would be to execute the transaction, which would just fail if an item had sold out already.

[ryanchristo]

Closing this epic given the first version of the marketplace submodule is complete and included in Regen Ledger v4.0. A new epic will be created to track orderbook functionality.