Update 003_depth_bump.md

This commit is contained in:
Will Ruddick 2020-05-14 11:56:23 +00:00
parent 8c1a9d19cf
commit 16c187e60c
1 changed files with 27 additions and 26 deletions

View File

@ -1,60 +1,61 @@
# Depth Bump - Add new tokens to reserve and supply with a specified price
# Depth Bump - Add new tokens to reserve and supply without effecting price
Author: Will Ruddick
Date: 2020.03.16
Version: 0.0.2
Version: 0.0.3
## Rationale
Moving to xDAI looks unstable right now. In order to increase our token supply we can increase the amount of virtual reserve and CIC supply and keep the price fixed.
The reserve on the Bancor contracts will never grow far beyond the Target Reserve Ratio point as holders will sell off the CICs and remove the reserves beyond it.
Giving people the option to add reserve and mint an equal amount of tokens (without a price change) would be a way to increase the overall liquidity.
But because that would give an advantage to liquidity providers when the CIC price is above 1:1 we need to ensure that excess tokens are given to the community.
(note that a depth shrink could also be created )
## Before
We have a virtual token right now as the reserve.
We have no ability to increase liquidity depth (reserve and supply outside of the bonding curve).
Example if a donor decides to add 40,000 in reserve to a CIC (which is already at the designated TRR)
the price of the token will shoot up and CIC sell offs will cause the reserve to fall back again.
## After
We would need to be able to mint tokens and the reserve outside of the bonding curve.
The idea would be to keep the price 1:1 with reserve and increase both reserve and supply (off the curve)
We would need to be able to mint tokens and the reserve outside of the bonding curve in a controled way.
The idea would be to keep the CIC price 1:1 with reserve and increase both reserve and supply equally (off the curve)
Excess tokens created in this process (beyond those minted along the bonding curve) should be given to a specific address designated in the Converter constructor.
A donor in this case can choose to always get back as many CICs as they add to reserve - with no speculative advantage.
## Implementation
### Workflow
* return ownership of the token to a person (not the converter)
* mint more tokens (off the curve)'
* give ownership back to the converter
* add more virtual reserve to the converter
* A public depthBump Funcation is added to the converter contract which takes in reserve R1 and mints an equal amount of tokens T1
* Calculate the amount of tokens (Tc) that would have been created on the bonding curve due to R1.
* If the tokens T1 > Tc then Te = (T1-Tc) and Te goes to a desginated wallet (Community Pool) and Tc goes to whomever added the R1 (thus not giving the liquidity provider a advantage)
* If the tokens T1 <= Tc then T1 goes to whomever added the R1 (in this case the liquidity provider takes a loss)
### Variables
* Amount of supply to add S2 16,000,000
* Amount of Reserve to add R2 8,000,000
* Resulting Exchange Price: P2 1.0
* Amount of Reserve to add R1 8,000,000
* A community Pool account (for excess) in the constructor of the converter contract
* Note taht this pool may be used for other system functions like rewards and holding fees
* Existing CIC Supply: S1 ~8,000,000
* Existing Reserve: R1 ~2,000,000
* Existing Price: P1 ~1.0
### Interface (CLI)
### Interface
cmd: depthbump <-s targetsupply> <-p price>
cmd: depthbump <-r reserve added>
## Testing
```
cmd: depthbump targetsupply=16000000.0 price=1.0
cmd: depthbump -r R1 (R1 in units of the Reserve)
You are creating (16000000.0 - S1) new tokens? (yes/no/quit)
You are creating ((16000000.0)/4-R1)*P2 new reserve tokens? (yes/no/quit)
You are creating R1 new tokens? (yes/no/quit)
....
the new supply of CIC should be: 16,000,000
the new reserve should be: 4,000,000
the new supply of CIC should be: The old supply + R1
the new reserve should be: The old reserve + R1
the new excahnge price should be the same as the old price
(error if P2 != 4(R1+R2)/(S1+S2)) (where 4 is 1/cw from converter contract)
(warning if P2 != P1 and confirmation)
```