Separate out depth bump comments
This commit is contained in:
nolash
parent
e999077d5f
commit
e9b6a46238
GPG Key ID:
93EC1C676274C889
@ -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
|
||||
|
||||
@ -24,24 +24,14 @@ Enabeling users to create their own tokens is one of the main goals of CICs
|
||||
2. Token Long Name - 128 character limit
|
||||
3. Token short name no more than 6 Character - must be unique
|
||||
2. Reserve amount - amount of tokens they want to put in reserve (minimum upon conversion 100k xDAI)
|
||||
|
||||
> lash: Does the current conversion price between xdai and sarafu play a role here? The chama may have sarafu initially, and that will be translated into the xdai (which for their part is just some abstraction of ksh anyway). How sensitive is this to timing / quality of arbitrage agents?
|
||||
|
||||
> lash: Do donors play a role in the initial reserves here? Like a frational top-up? If it does, should it be allocated before or after conversion?
|
||||
|
||||
3. Number of chama members (NCM) (before we enable conversion of the new tokens there must be at least this many token members with a positive token balance)
|
||||
4. Token Backing Statement: 256 Character limit - What is the off-chain guarentee behind these tokens
|
||||
|
||||
> lash: this should rather be a crypto proof of off-chain information sources.
|
||||
|
||||
5. Defaults:
|
||||
1. 25% Target Reserve Ratio (1:1 with reserve)
|
||||
1. Minimum initial reserve is $100 USD = 100 xDAI in value (of some inital token such as Sarafu)
|
||||
|
||||
> lash: do we need to clarify better what the effect of asymmetric changes in real-world assets against the initial issued tokens is? 100 goats may be committed initially, but if they get eaten by mutant locusts, what happens to the value of the token then, and what transparency should be provided in that event? (for example, should the actual backing statement be revised etc?)
|
||||
|
||||
5. These should all be added to the Token table information
|
||||
|
||||
|
||||
## Token creation process - Backend
|
||||
|
||||
1. Ensure TOKEN_Name is unique
|
||||
@ -58,24 +48,14 @@ Enabeling users to create their own tokens is one of the main goals of CICs
|
||||
## Join Token
|
||||
2. Each user needs to be assigned a default / community token - they start with Sarafu by default.
|
||||
2. Users need to be able to change tokens - but after a grace period of 1 month.
|
||||
|
||||
> lash: how should the grace period be enforced? if on smart contract level this would mean changing the bancor contracts most likely.
|
||||
|
||||
3. Users on USSD should not be allowed to join Sarafu or the reserve xDAI as their community token. Admin accounts like the GE Agent will still be in Sarafu as their community token
|
||||
|
||||
> lash: not allowed to join sarafu once they _left_ sarafu in the first place, right?
|
||||
|
||||
## Auto Join Token
|
||||
1. Users with Sarafu as their token will automatically join a Community Token of a user they trade with (given the recipient is not in Sarafu) - This is a one time event
|
||||
|
||||
> lash: who pays the fee for this, or is it negligble?
|
||||
|
||||
## Auto convert
|
||||
1. We want to avoid having multiple tokens in user wallets
|
||||
1. When a user recieves a token we automatically try to convert that token into her Community token
|
||||
|
||||
> lash: where is this enforced? this may be complicated to do on a smart contract level as the network isn't designed to do any per-address discrimination. What consequences can multiple tokens on one account due to external converts have?
|
||||
|
||||
2. We should be able to turn this feature off for selected users (like admins)
|
||||
3. If users have multiple tokens in their wallet - it is a sign conversion failed - we need some process to retry failed conversions and to altert admins
|
||||
|
||||
@ -117,24 +97,11 @@ Enabeling users to create their own tokens is one of the main goals of CICs
|
||||
- My Account -> Create Token
|
||||
1. Token Name (limited to 9 characters (auto converted to lowercase no special letters) (TOKEN_NAME)
|
||||
2. Reserve amount (the minimum is 10,000 Kenyan Shillings in value- higher amount means a higher price of the final tokens) - Max is the user’s current balance. Note that this10,000 Kenyan Shillings can be in the form of other tokens and converted to Sarafu.
|
||||
|
||||
> lash: it seems here like there is an option only to put _part_ of the currently held amount of sarafu (or whatever token) in reserve. but elsewhere we're enforcing one token per wallet/group only. shouldn't this choice be all-or-nothing?
|
||||
|
||||
3. Token Backing Statement: What goods or services will be accepted for these tokens?
|
||||
|
||||
> lash: isn't this rather difficult to handle on a phone interface? what about timeouts? how do we sanitize the input? what about the real-world documents that get signed? how about if there are many types of goods and/or they will change over time?
|
||||
|
||||
4. Please confirm that you will accept (4x Reserve) of TOKEN_NAME's for (goods or services)?
|
||||
*. Yes / No (if no -please contact Office 0757628885)
|
||||
4. How many people are in this chama that will recieve (Token_Name) - Minimum 10 - Note your account will be locked until you've sent out all all your tokens to this many users.
|
||||
|
||||
> lash: where should this lock be enforced? that seems like a specialized token contract. does that mean that our bancor suite would have to support "non-standard erc20 tokens" only?
|
||||
|
||||
|
||||
5. Note that members must ‘join’ the token (via USSD) using the TOKEN_NAME to receive this.
|
||||
|
||||
> lash: what happens then if a user never joins? do the tokens just linger? are they returned? is the above account forever locked? is there any use case where they wouldn't join?
|
||||
|
||||
4. Pin
|
||||
* “Enter PIN
|
||||
* _______________”
|
||||
@ -169,9 +136,6 @@ Enabeling users to create their own tokens is one of the main goals of CICs
|
||||
2. Also when people buy in they are adding to theri own token's reserve and minting new tokens.
|
||||
3. Since GE is the intermediary for Kenyan Shillings Mpesa - sending TOken X to the GE Agent Account should first convert that token to
|
||||
it's own reserve and give back that much Mpesa (limited by chama rules)
|
||||
|
||||
> lash: is the ge agent getting xdai or sarafu here?
|
||||
|
||||
4. When a user sends mpesa to us - they can mint whatever their current currency is.
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user