# ReFi Project Spec(s)

## Dynamic Pooling

This project would try to solve the problem of dynamic pooling, which will be particularly useful for carbon credits.

The formulation of the problem is this: We have a family of *semi-fungible* tokens, which is a family of tokens which share a common identity and use case (e.g. carbon credits) but don't all share the *exact* token structure, being differentiated by (1) being on distinct token contracts, and/or (2) having different metadata.

Note that this is not the same thing as a family of NFTs. Take for example carbon credits: Each credit contains metadata about the location of the carbon capture project, the time frame in which carbon was captured, other environmental data, and a quality rating. Each token counts as 1 tonne of carbon captured, so in any given time frame there will likely be multiple tokens that share the same metadata, for example if a carbon project captured 100 tonnes of carbon over a given time frame, they can mint 100 tokens, all of which share the same metadata and are managed by the same token contract (ERC-20 or ERC 721 on Ethereum, FA1.2 or FA2 on Tezos).

We call these tokens, taken together, *semi-fungible* because in practice they all represent the same thing, but taken as a family they are disparate from a valuation point of view (not all tokens are created equal, and they should be valued differently relative to each other), and from a computational point of view (they are on distinct smart contracts, for example).

The goal of this project is to do the following: Given an initial methodology for valuing tokens in the family relative to each other, create a smart contract that allows holders of tokens in the semi-fungible family to deposit their tokens in this pooling contract in exchange for the *pool token*. The exchange rate for constituent tokens (tokens in the semi-fungible family) to pool tokens should depend on the specific token type. The smart contract should allow for users to deposit and withdraw them (if they have a pool token they should be able to withdraw it in exchange for any constituent tokens in the pool, according to the exchange rate). Note that being able to deposit and withdraw means that people can trade tokens for which there is liquidity in the pool, simply by depositing some constituent tokens in exchange for the pool tokens, and then withdrawing constituent tokens of another type. To ease this, there should be a swap function that allows you to swap directly instead of depositing and then withdrawing.

Because there is a swap function, this contract essentially turns into an AMM of sorts, where people can provide liquidity by depositing tokens and liquidity providers can earn fees from trades. Additionally, due to the trading functionality, the contract should respond to supply/demand shifts: the price of one token type relative to the others should go up if it is in higher demand relative to the others. This needs to be kept track of internally by the smart contract.

Finally, the smart contract ought to be optimized so that gas consumption is as low as possible. In particular, this means that the way this internal exchange rate is stored, and the way that trades are priced, should be as computation-light as possible.

An example of an initial, in-the-ballpark prototype of this on Tezos [is here](https://github.com/differentialderek/tezos-templates/tree/main/FA3). Happy to discuss this further.

## MEV-resistant AMM

Miner extractible value (MEV) is the phenomenon where parties pay miners to include transactions from the mem pool in a specific order and at the top of their block. This was first discovered and articulated in the paper [Flashboys 2.0](https://arxiv.org/abs/1904.05234).

This is relevant for trading on AMMs like [Uniswap](https://uniswap.com/) or [Curve](https://curve.fi/). Bots can observe the mem pool and detect when they have a chance to either *front run* or *sandwich* a transaction. Both of these are opportunities for the bot to make a profit by injecting their own transactions, along with those from the mem pool, in a specific order at the top of a block. Currently, on Ethereum, the market for MEV is quite large (see this [very good article by Dan Robinson](https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff) and [this good paper](https://courses.grainger.illinois.edu/ece598pv/sp2021/lectureslides2021/ECE_598_PV_course_notes13.pdf) and [this article](https://ethresear.ch/t/improving-front-running-resistance-of-x-y-k-market-makers/1281)).

A good project would be to build an MEV-resistant AMM, sometimes called "ordering protocols." No concrete version of an MEV resistant AMM exists, though they are theoretically possible, and it would be of high interest for the community to see one.

One way to do this on Tezos (hehe :)) would be to use the timelock mechanism (see [here](https://tezos.gitlab.io/alpha/timelock.html) and [here](https://tezos.org.ua/en/blog/tezos-timelock-explained)). I have some ideas on how this could work and it would make a very good project.

While not directly related to carbon credits, this would help future marketplaces for carbon credits resist MEV.