# Regen Ledger Token Burning Proposed Upgrades

In order to achieve an effective and sustainable monetary policy for the REGEN token, a simple startegy is proposed: identify the biggest economic activities in the network and use some percentage of those economic flows to burn REGEN tokens. This reduces the supply of REGEN tokens and provides a counter-balance to minting. This document proposes on-chain upgrades to enable this.

## `MsgBurn`

Many of the largest economic transactions in the network are actually expected to occur off-chain and to the value of these transactions on-chain currenly only be accounted for via minimal gas fees. The simplest method for accounting for these economic activities on-chain in proportion to their off-chain value is to setup contractual and social obligations to burn a corresponding amount of tokens. On-chain the simplest mechanism for doing so is to introduce a single message which allows for burning REGEN tokens.

A very simple `MsgBurn` message is proposed which would live in either `x/ecocredit` or a new `x/regen` module:

message MsgBurn {
  // the address of the burner
  string sender = 1;
  
  // the amount to burn in uregen
  string amount = 2;
  
  // some metadata associated with this burn which can be used to indicate which economic activities it relates to. Suggested maximum length of 256 characters.
  string reason = 3;
}

## Improvements to `x/ecocredit` `MsgSend`

The `x/ecocredit` [`MsgSend`](https://buf.build/regen/regen-ledger/docs/main:regen.ecocredit.v1#regen.ecocredit.v1.Msg.Send) message (different from `x/bank` `MsgSend`) is used to transfer eco-credits and would be called whenver off-chain transactions take place. In this scenario, eco-credits are being paid for off-chain but the credits are transferred on-chain. One of the key transactions where we can account for the value of newly created eco-credits is in the primary sale of those credits (the sale to the first buyer after issuance). We could extend the [`SendCredits`](https://buf.build/regen/regen-ledger/docs/main:regen.ecocredit.v1#regen.ecocredit.v1.MsgSend.SendCredits) message to include information about the value of the primary sale and the corresponding amount of REGEN that will be burned. Then when executing `MsgSend` for the primary sale, this amount of REGEN tokens will be burned from the sender's account. Note that this only works when the sender takes responsibility for effectuating the platform fee associated with the primary sale.

It is proposed that both a generic `MsgBurn` be created as well as an extension to `MsgSend`. `MsgSend` is more specific and allows public visibility of off-chain economic transactions linked to specific batches of credits. `MsgBurn` can be used to account for all other scenarios that we can't necessarily foresee.

## Fees in `x/ecocredit/marketplace`

The above upgrades allow mechanisms for accounting for off-chain transactions, but we still do need to account for on-chain transactions which hopefully will grow in volume over time and can be programmatically enforced.

The obvious place to extract fees in marketplace transactions would be when orders are matched and fulfilled and either the buyer or seller or both could pay these. Different fees could be charged for primary sale and secondary sales and these could be stipulated both by governance and/or credit classes.

The big challenge is that the transactions themselves may not be denominated in REGEN which poses problems if we want the fee to be a percentage of the sale value because we need some way to convert other currency values (ex. USDC) to REGEN value.

Three potential solutions are proposed:

### Conversion to and burning of REGEN is dealt with manually via on-chain governance

This may be the simplest approach to implement but requires the largest amount of human overhead. This would involve charging a percentage fee on marketplace transactions in whatever denomination they occur in and either immediately burning REGEN when the REGEN is used or placing any non-REGEN tokens in a fee pool. So if we say there is a 3% buyer fee and the transacton happens REGEN that 3% of the REGEN value gets burned immediately. If however a transaction happens in USDC, then 3% of the USDC value goes into the fee pool. At some regular intervals, on-chain governance or some authority delegated by governance (a fee pool manager) takes all the non-REGEN tokens in the fee pool and uses them to buy REGEN on some exchange and then burns them using the generic `MsgBurn` defined above.

One downside of this approach is that if the interval at which the fee pool manager is converting to REGEN and burning is infrequent, the REGEN price could fluctuate significantly during this time frame. On the other hand, this approach wouldn't require buyers to hold sufficient amounts of both REGEN and the token they're buying eco-credits with.

### Price oracles

With the price oracle model, some off-chain price oracle would need to be authorized to update REGEN conversion rates for all non-REGEN tokens used as marketplace denoms. For example, there could be some authorized bot that submits a transaction to the x/ecocredit/marketplace module every 30 minutes with the latest price of REGEN on Osmosis. Then the marketplace would use the latest prices to require that this amount of REGEN is paid in marketplace buy orders. Since all buy orders currently are direct buy orders (meaning immediate fulfillment, no order book), the pricing would be more or less accurate. So if the REGEN price is 0.10 USDC, and there is a 3% fee on a 100.0 USDC transacton, then 3.0 USDC of REGEN or 30 REGEN must be paid in the buy order and this REGEN would get burned.

This approach avoids any manual work on part of governance, but a trusted bot needs to be created and the pricing information needs to be trustworthy and accurate. Also, if an order book is implemented in the future, then orders might fail to match simply because the amount of REGEN posted in the order may not be enough to pay the fee if the price drifts significantly between when the order is posted and when it is matched. Another challenge with this approach is that buyers would need to hold sufficient amounts of both REGEN and the marketplace denom they're paying for eco-credits with which could introduce significant logistical friction.

### On-chain liquidity pools

This approach would involve creating on-chain liquidity pools between REGEN and every denomination used as a marketplace denom using some liquidity module. Then when marketplace transactions occur in a non-REGEN denomination, the correct amount of REGEN can be purchased from the liquidity pool and burned on the spot.

The advantage of this approach is that it doesn't require users to have sufficient amounts of both REGEN and another token, doesn't rely on trusted off-chain actors such as price oracle bots or human fee pool managers, and also creates an easy on-chain utility for acquiring all tokens used in marketplace transactions. Also there are likely good off-the-shelf liquidity pool modules that could be integrated into Regen Ledger fairly easily.

Challenges of this approach would be making sure there are no legal risks with hosting on-chain liquidity pools on Regen Ledger and ensuring that there is sufficient pool liquidity for all desired denominations. If there is not sufficient liquidity, price fluctuations could happen in dramatic bursts and at times not reflect prices elsewhere.