Crypto Economics, Perpetual Liquidity and IL offsets
Update: This is 100% valueless, not in the meme sense, as in this is an experimental concept to be further developed and co-collaborated on. This won’t be used in the future, nor does it do anything more than create a perpetual distribution pool. Its shared for devs to help think tank and figure out how to create this new distribution mechanism. Don’t put funds into it. I promise, I will create things for you to use your funds for, but this is not it.
Inspired by protocols such as APML, YAM, UNI, and SNX I started playing around with a few new economic concepts. I ended up with an liquidity based inflationary token that can offset IL via liquid governance.
The goal we would like to achieve is two fold;
- Generate as much trading fees as possible
- Offset IL as much as possible
To achieve 1 we need to create a platform that self promotes arbitrage. The new designed liquidity token has a K invariant (Uniswap) bonding curve to mint tokens, however, no burn method. Any liquidity used to mint the token is automatically provided to the uniswap pair. The net result of this, as a purchase occurs, the price increases on the uniswap pair, and the price increases on the curve. The sweet spot here is 50% purchased on the curve for every 50% purchased on the pair.
To achieve 2 we need to adequately incentivize liquidity providers via standard liquidity incentive mechanisms (with a further advancement below).
The design before these kinds of tokens, has been fairly standard in terms of provisioning, an initial pool to distribute (pool 1), and a secondary pool to provide liquidity (pool 2). The problem with this design is that pool 2 often simply becomes a farm and dump pool, where pool 1 is used to mint tokens and pool 2 is used to burn tokens. The net result is bad for liquidity providers.
The design above incorporates pool 1 and pool 2 into the same design structure, as well as create an arbitrage incentive for traders.
The goal with this design is not particularly around token value, however around token volatility, liquidity providers generate income via high volume trades, and this system promotes that outcome.
Technicals
Continuing, I will break down each concept and explain its purpose, I hope this design will lead to further liquidity based incentive programs.
At the core, we have the incrementing function. Very simple, it rewards liquidity provided by 1% every 7000 blocks (~roughly 25 hours).
The design pattern here is the same we have seen before; acquire token > provide liquidity in uniswap > provide LP token to reward contract > receive rewards for providing liquidity over time.
The design as described above favors LP providers, and essentially means everyone would simply be LP providers, so instead, I added a small tweak, the amount of tokens to be minted is only 50%, the other 50% is taken from the liquidity pool itself. 90% of the new tokens are provided to the liquidity providers, 10% to general holders.
Given that there should in theory only be 1 liquidity source, this has the net effect of increasing the 1:1 denominated value.
So simplistically speaking, if you provide liquidity, you will receive 0.90% interest every 25 hours.
Every time token balances are changed the system keeps track of their pro rata portion of the increase.
Users can simply call claim or claimFor to interact to claim their rewards.
Initial liquidity is a constraint, for that purpose the token itself can be minted from the contract itself, any liquidity provided to mint tokens is automatically provided as liquidity to the uniswap pair. This curve itself is similar to a uniswap K and should keep price constant with standard uniswap trades.
Goals
As I further expand on this concept, I believe that these tokens can become a liquidity bridge that couples together multiple exchange endpoints. The net result will be consolidated liquidity as well as further order book depth and within limits, IL offsets.
This first release is ETH only, but this will be further enhanced to include other tokens and protocols.
Core Contracts
Any devs interested in these concepts can review the following contracts;
Liquidity 0x375Da3e307Ef2E1A9D9e1516f80738Ca52cb7B85
Governance 0x71c882bC3191b36bbE839e55dec2e03024943DCD
Rewards 0x6803c357fb329755f906839d800617a93d61C202
These contracts are purely for research purposes and should not be used for any other purpose.
