grassrootseconomics/cic-docs
5
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Separate out self-service token comments

Browse Source
This commit is contained in:
nolash 2020-06-17 16:25:19 +02:00
parent e999077d5f
commit 991647b255
Signed by: lash
GPG Key ID: 93EC1C676274C889
2 changed files with 0 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
spec/002_xdai_migration.md
View File

@ -22,17 +22,9 @@ with a connector weight (target Reserve Ratio) of 0.25 (25%) and an inital price
(Note that the 100 Sarafu to 1 xDAI will approximate the Kenyan Shillings to USD rate)
## Implementation
Each existing user should have a completley new wallet and private key for security reasons and be given the same balances they currently have with the new (xDAI reserve) Sarafu. Roughly 8Million Sarafu_1 in wallet will be replaced with Sarafu_2
### Workflow
> lash: what's meant by public and private functions here?
> lash: private keys: should we take the opportunity of setting up deterministic wallets? perhaps even on the platform we may want to shuffle private keys once in awhile.
> lash: what is a "facilitator address"?
1. Synch db <->Blockchain - ensure synronization between our db (USSD interface) and blockchain
1. Finalize any contract changes to Bancor Suite (such as [Depth Bump](https://gitlab.com/grassrootseconomics/cic-docs/-/blob/master/spec/003_depth_bump.md))
1. Create Public vs Private Functions - Contracts as permissionless as possible

12
spec/003_depth_bump.md
View File

@ -28,19 +28,12 @@ the price of the token may shoot up and CIC sell offs will cause the reserve to
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 (with the same multiple) (off the curve)
To avoid gaming: 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.
> lash: "specific address in the converter constructor." Is this feasible without changing code? Where else could we put this without changing code? Could contract registry help?
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
> lash: this must be performed as an atomic operation.
> lash: Is it possible to set up the equation so that we avoid the case of having to handle overshoot in a special wallet; does it help to define the token issuance as the target instead of the amount of reserve?
* A public depthBump Funcation is added to the converter contract which takes in reserve R1
* Calculate the multiple to teh reserve (R1/R0) and mint an amount of tokens T1 = T0(R1/R0) - Where R0 and T0 are the inital amount of reserve and supply
* Calculate the amount of tokens (Tc) that would have been created on the bonding curve due to R1.
@ -51,11 +44,6 @@ A donor in this case can choose to always get back as many CICs as they add to r
* Amount of Reserve to add R1 8,000,000
* A community Pool account (for excess) in the constructor of the converter contract
> lash: Who would have spend access to this community pool, and how?
> lash: Is the community pool the only source of "basic income / usage bonus"?
* Note taht this pool may be used for other system functions like rewards and holding fees
### Interface (CLI)