66 lines
2.7 KiB
Markdown
66 lines
2.7 KiB
Markdown
# Depth Bump - Add new tokens to reserve and supply without effecting price
|
|
|
|
Author: Will Ruddick
|
|
Date: 2020.03.16
|
|
Version: 0.0.3
|
|
|
|
## Rationale
|
|
|
|
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 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 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
|
|
|
|
* 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 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
|
|
|
|
### Interface (CLI)
|
|
|
|
cmd: depthbump <-r reserve added>
|
|
|
|
## Testing
|
|
|
|
```
|
|
cmd: depthbump -r R1 (R1 in units of the Reserve)
|
|
|
|
You are creating R1 new tokens? (yes/no/quit)
|
|
|
|
....
|
|
|
|
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
|
|
|
|
```
|
|
|
|
|
|
## Changelog
|
|
|
|
* 0.0.2: Clean up formatting, subsection implementation
|
|
* 0.0.1: Created initial stub
|