# Carbon Tokenomics

This writeup relates to the [contracts found in this repository](https://github.com/differentialderek/cce-token-contract). The two principle contracts in this repo are the `carbon.mligo` and `carbon-fa2.mligo` contracts.

## Basic Idea
Someone with a nature-based climate-change solution (we'll call these "projects" from here on out) can mint tokens meant to capture the positive externalities of their project. These positive externalities are primarily carbon capture, but also include things like wildlife preservation, protecting endangered species, etc. and are represented in the token's metadata.

Tokens are minted retroactively, after carbon capture and positive externalities can be verified using freely-available satellite image data and the algorithms developed by our team of botanists/zoologists.

## Semi Fungible Tokens

The positive externalities a project captures will be specific to the project. Furthermore, since a project can span a large geographical area, it may have distinct zones, each with its own distinct metadata. A project will be able to mint tokens corresponding to each of its constituent zones, each with its own token id.

These tokens all represent carbon capture, so they are (almost) fungible in a sense. However, tokens have metadata specific to their projects and zones, so they are not all equal and should not be priced equally. Thus we call these "semi-fungible" tokens. There should be an AMM where these semi-fungible tokens can be traded and priced.

* *Note*: We're still debating if 1 token should equate to 1 tonne of carbon, or if a token should correspond to a security representing a "share" of the project. My preference is that it be a commodity, representing 1 tonne of carbon.

## Basic Architecture
Each project is allocated an FA2 contract, with token types and metadata corresponding to zones within their project. There is a central contract, `carbon.mligo` in the repo, which manages permissions on who is approved to create a project, which kinds of tokens they can mint, what the minting cap is, etc. In a similar architecture to Checker, we have a central admin contract with a bunch of satellite FA2 contracts that represent projects; the admin contract has certain permissions manage the FA2 contracts.

## Market-Making Mechanism

Attached to the carbon contract and FA2 contracts representing projects, we would like to have an AMM that allows for carbon tokens to be freely and automatically traded. There are some desireable traits that we might want out of this AMM.

### Desireable Traits
1. Price discovery that reflects the value of projects over time, so that:
* Carbon credits can be held speculatively, where a project's good fundamentals increase the price of a carbon credit over time.
* The price of carbon credits should reflect the value system of the general public—i.e. it should respond to supply and demand pressures.
1. The owner of a carbon token should be able to exchange their tokens at any time at the "market rate," either for XTZ, some stablecoin, or for a basket of other carbon tokens.
* We'd like to avoid an order book system common with NFTs.
* Token owners shouldn't have to post their tokens for sale and wait to be matched with a buyer.
1. Projects that have more positive externalities should be priced higher to incentivize better-quality projects due to greater profitability.

### The AMM

The proposed AMM relies on a ranking/comparison metric between carbon tokens based on their metadata. Initially, in our project we will consider the following four aspects of metadata, all of which can (I believe) be quantified numerically from our botanists/zoologists:
1. Additionality
1. Leakage
1. Permanence
1. Biodiversity

I'll be honest and say I don't know exactly what each of these refers to, but the important thing is that there are four metrics, each of which can be given a numerical score.

Thus each carbon token represents a vector in 4-dimensional space. We can proceed in a variety of different ways, but the main idea is that we need to define some notion of hierarchy or relative distance between any two carbon tokens. We can use this notion to define an exchange rate.

### Rarity Metric

One option is to make a "rarity metric," similar to crypto punks, tezzardz, or project neon. Each token gets a rarity score and the price of token `y` in terms of token `x` could be:

$$ \chi \cdot \frac{\textrm{rarity}(x)}{\textrm{rarity}(y)} $$

where $\chi$ is a scalar that reflects how much rarity should influence price—should a token that's twice as "rare" be twice the price? Or 10x the price? If we want the price to relate to rarity in a nonlinear way, we could also have the price expressed as:

$$ e^{\frac{\textrm{rarity}(x)}{\textrm{rarity}(y)}} $$

or, more generally:

$$ f \Big(\frac{\textrm{rarity}(x)}{\textrm{rarity}(y)} \Big) $$

for some function $f$ which expresses the relationship between rarity and exchange rate.

This works well if the metric of "rarity" is fixed and known *a priori*, which may or may not be true in the carbon example. This exchange mechanism, however, could be useful for exchanging NFTs within a single project like punks or tezzardz.

*(Research question)*: Is there a way to construct a function $f$ that responds to market data over time, so there can be some sense of price discovery? Higher demand should increase the price to close arbitrage loops.

With enough liquidity, this strategy should fulfill criteria 2. and 3. from our list above. I am not yet sure how to make this strategy responsive to market activity so that prices change over time. This would likely be done with the rarity function, having it adapt over time with each trade to respond to supply/demand price pressures.

### Partial Ordering/Hierarchy
Another way to do it would be to set the tokens in a hierarchy with a partial order. A partial order is a relation on a set, denoted $\leq$, with the following properties:
1. $a \leq a$ : each element is related to itself
1. $a \leq b$ and $b \leq c$ implies $a \leq c$ : ordering is transitive
1. $a \leq b$ and $b \leq a$ implies $a = b$.

With a finite number of tokens, you can organize this into a DAG and say the exchange rate between tokens $x$ and $y$, $x \leq y$, could be proportional to the length of the shortest path from $x$ to $y$ on the DAG representing the partial order. This could also scale unevenly, where steps close to the highest-ranked token are more costly to traverse than those closer to the leaves.

As above, with enough liquidity this should satisfy criteria 2. and 3., but in order to satisfy 1. the partial ordering would have to be responsive over time to market data. For example, if we have $x \leq y$ initially, but over time people buy $x$ more frequently than $y$, there may be a point where the ordering should flip so that $y \leq x$.

### Preferences Vector

Another option (which is my preffered) is to use what I call a "preferences vector," which is a vector that can change over time in response to market movement. We say that tokens are worth more the more they are "aligned" with this preference vector, by using the dot product.

Like before, tokens represent a 4-dimensional vector. Each token $x$ has a magnitude $||x||$, which is its distance from the origin. This is calculated as the square root of the dot product of the vector with itself, i.e.
$$ ||x|| = \sqrt{x \cdot x} $$

This is in one sense its value, since having higher values in each piece of metadata is presumably a good thing. We can also look at how aligned $x$ is with the preferences vector $p$, by dotting the two:
$$ x \cdot p $$

We can give each token (vector) $x$ a "score" by summing its magnitude and the value of its dot product with $p$:
$$ \textrm{score}(x) := ||x|| + x \cdot p$$

Then the price of token $y$ in terms of token $x$ is given, as before, by

$$ f\Big( \frac{\textrm{score}(x)}{\textrm{score}(y)} \Big) $$

where $f$ is a function that encodes how influential this ratio of scores is on the actual exchange rate, as in the example above of the rarity metric.

If the preferences vector starts out small, then carbon prices largely depend on magnitude. However, over time, prices can reflect market preferences if the preference vector updates incrementally with each trade: if someone buys token $y$ with token $x$, the preferences vector can be updated roughly as follows: `p = p - m * x + n * y`, where `m` and `n` are scalars so the change is very small, and `m < n` so that the magnitude of `p` grows over time.

If $p$ grows over time, this means that over time price will be determined more by the dot product (a notion of "being aligned") with $p$ than by the token's magnitude. If, for example, a token $x$ is orthogonal to $p$, over time it will become less and less valuable, since $x \cdot p = 0$.

*Note:* It may not be desireable for the influence of market preferences to grow in influence over time in an unbounded way as described above; the size of `p` could be roughly fixed, for example, by making `m = n` in the formula above, or some other mechanism.

### Price of XTZ

In each of these cases, we want these tokens to be tradeable with XTZ as well as other carbon tokens (or, more generally, tokens in a semi-fungible family). Thus XTZ should be given a score, like a "rarity score" or whatever metric is being used. That way, it becomes comparable to the other carbon tokens and the exchange rate can be priced.

What the initial price should be is an open question. My intuition is that its score should be quite low. This could take a few different forms:
* In the case of the "rarity score" example, its rarity score should be close to the most common score, or to the 0th percentile.
* In the case of the partial ordering/hierarcy, the leaves (lowest-ranked values) of the partial order should all be XTZ. At the very least, you need the property that XTZ is comparable to any other token, i.e. that for every token $x$, either $\textrm{XTZ} \leq x$ or $x \leq \textrm{XTZ}$.
* In the case of the preferences vector, perhaps the vector representing XTZ could be the preferences vector, scaled way down.

We could make the price, or ranking, of XTZ also responsive to market movements.

## Liquidity
In order to avoid the order book system, we need liquidity locked in the contract so people can trade on demand. This liquidity could take the form of XTZ or of carbon tokens. The pool should contain a mix of the two.

A project owner can mint their tokens and swap them on this AMM, either for other carbon tokens or for XTZ directly (assuming there is enough XTZ in the pool to fill the trade). Because demand is so high right now for carbon tokens, we expect carbon tokens to sell quickly, and thus that the pool will mostly consist of XTZ.

Once project owners have swapped their carbon tokens, the tokens become part of the pool and can be bought by anyone else using an exchange rate mechanism described above.

### LP Token Incentives
(I have not thought through LP tokens as well as the other sections.)

People wishing to contribute liquidity can do so with XTZ or carbon tokens.

The exchange rate of an LP should initially be 1:1 for XTZ: If I want to contribute a carbon token to the liquidity pool, I could get the same number of LP tokens as the amount of XTZ I would get if I swapped it for XTZ. If I contribute XTZ, the exchange rate is 1:1. How the exchange rate should change over time is an open question, but the pool will likely grow with transaction fees and so the exchange rate will have to evolve over time.

If an LP token holder wants to cash out, they can do so in carbon tokens or XTZ.

Liquidity providers could be incentivized to provide liquidity, for example, by implementing transaction fees and growing the liquidity pool over time.

## Burning Carbon Tokens
Carbon token holders can burn them by calling the `%burn` entrypoint of the `carbon` contract. This will give them, in exchange, a token which we're calling BURIED (for now).

The exchange rate between carbon tokens and BURIED should be the same as between those same tokens and XTZ—i.e. if you burn carbon tokens you should get the same amount of BURIED that you would get if you exchanged them instead for XTZ. Having the option to burn carbon tokens has the advantage that, no matter what the liquidity pool looks like, you can always exchange your carbon tokens (semi-fungible tokens) for a fully-fungible token, BURIED.

Since entities will burn these credits to offset emissions, there will likely be a large supply of BURIED tokens in circulation.

*Research question*: Is there a way to do this exchange mechanism so that the price of BURIED roughly corresponds to the price of XTZ? Perhaps using an oracle you can change the exchange rate so that:
* If price of BURIED is greater than XTZ, the exchange rate into BURIED tokens becomes more favorable, and
* If the price of BURIED is less than XTZ, the exchange rate into BURIED tokens becomes less favorable, reducing the amount of tokens minted.

## To Do/Open Questions:
* How to update metadata over time? If priorities/desired characteristics evolve, can we update which metadata we consider?
* How to decouple the positive externalities of carbon capture and other environmental things, wildlife preservation or preserving a species?
* Would it make sense to mint tokens separately, one just for carbon capture, and others that represent the other positive externalities?
* How can we incentivize liquidity if the pool might shrink over time by people burning their tokens instead of selling them? Is this a problem?
* If it is, there should be exchange rate mechanisms or incentive systems to keep liquidity in the pool.