moved conversion and multi-token issues to their own specs
This commit is contained in:
parent
ebec819689
commit
9f0cd601e4
|
|
@ -9,7 +9,7 @@ valid status values are: Pre-draft|Draft|Proposal|Accepted
|
|||
* Status: Pre-draft
|
||||
|
||||
## Rationale
|
||||
Enabeling users to create their own tokens is one of the main goals of CICs. This spec goves of the token creation process as well as conversion between tokens (to be pulled into it's own spec).
|
||||
Enabeling users to create their own tokens is one of the main goals of CICs. This spec goves of the token creation process
|
||||
|
||||
## Intro
|
||||
* Today users only receive Sarafu created by Grassroots Economics
|
||||
|
|
@ -20,9 +20,9 @@ Enabeling users to create their own tokens is one of the main goals of CICs. Thi
|
|||
## Sarafu Network – Sarafu and New Token Minting – User Flow:
|
||||
|
||||
1. Users create a token issuance agreement (for Sarafu or their own token) [(Sarafu Network Application)](https://gitlab.com/grassrootseconomics/cic-docs/-/blob/master/Sarafu_Network_Member_App_-_Draft__en_.pdf)
|
||||
2. The application is audited and signed by all parties (paper form)
|
||||
3. All users in the agreement dial the USSD code and setup an account (with 0 initial balance for new accounts). If they have existing tokens those will simply stay there in their account. *Note that Users with multiple tokens in their account should have an option to switch their home token to trade the other tokens.
|
||||
4. GE creates the new token (or mints more Sarafu) and sends it to the users as per the agreement. Also changing their Home token to the new token if one was created.
|
||||
2. The token creation application is audited and signed by all parties (paper form)
|
||||
3. All users in the agreement dial the USSD code and setup an account (with 0 initial balance for new accounts). If they have existing tokens those will simply stay there in their account. *Note that Users with multiple tokens in their account should have an option to switch their active token to trade the other tokens. (see milti-token-env spec)
|
||||
4. GE creates the new token (or mints more Sarafu) and sends it to the users as per the agreement. Also changing their Active token to the new token if one was created.
|
||||
5. Initally conversion between tokens will not be allowed (see conversion below)
|
||||
|
||||
## Inputs
|
||||
|
|
@ -38,40 +38,17 @@ Enabeling users to create their own tokens is one of the main goals of CICs. Thi
|
|||
1. All blockchain wallet addresses in application
|
||||
|
||||
|
||||
## Token creation process - Backend
|
||||
## Token creation process - Backend Command line and In-Person process
|
||||
|
||||
1. Ensure TOKEN_Name is unique
|
||||
1. Create / mint the token supply
|
||||
1. sarafu-token-deploy or giftable-token-deploy
|
||||
1. sarafu-token-deploy
|
||||
1. eth-token-index-add
|
||||
1. eth-address-declarator-add
|
||||
1. to discover the contract addresses on the network you use:
|
||||
1. eth-contract-registry-list
|
||||
1. Put the TOKEN_NAME tokens into the Users wallet (as per agreement)
|
||||
1. All members in the agreement should have their community token set to TOKEN_NAME
|
||||
|
||||
|
||||
## 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 community token
|
||||
|
||||
## Auto Join Token
|
||||
1. Users with only one token in their account will default to that as their community token
|
||||
|
||||
## Join Token Interfaces - UX
|
||||
|
||||
### Command Line - CLI Join Token
|
||||
1. User ID and Name or ID of the token - ensure it is a valid token
|
||||
|
||||
### CICADA Mgmt Platform - GUI
|
||||
1. On the user info page you should be able to set their Community Token - via a drop down
|
||||
|
||||
### USSD feature phones - Change Community Token
|
||||
- New user dials ussd session code where she selects My Account -> Community Token
|
||||
- They are shown the top 6 tokens by balances tehy have in their wallet and given a choice to choose which one they want.
|
||||
- Confirmation message and entry of pin number to Confirm
|
||||
- Future transactions send from this account will try to send that token
|
||||
- Future incomming transactions will attempt to convert to that token
|
||||
1. All members in the agreement should have their active token set to TOKEN_NAME
|
||||
|
||||
## Token creation Interface - UX
|
||||
|
||||
|
|
@ -85,39 +62,6 @@ Enabeling users to create their own tokens is one of the main goals of CICs. Thi
|
|||
2. The next page comes up with the inputs above
|
||||
5. Confirmation please type the token name to proceed
|
||||
|
||||
## Conversion between Tokens
|
||||
(to be pulled into own spec)
|
||||
|
||||
### Manual Conversion
|
||||
Users with different home tokens will not be able to trade with each other unless there is a path (liquidity pool) between them. They will get a message suggesting to call GE. Note that GE may also act as a manual exchange by holding a supply of several tokens.
|
||||
|
||||
### Liquidity Pools
|
||||
If users want automated conversion between tokens, then GE will have to be given a supply of that token and any other that they want to convert to (preferably Sarafu or a central network token) – and a static (1:1) liquidity pool connecting those tokens will be created with that given supply of each tokens.
|
||||
|
||||
If the amount in the liquidity pool is insufficient for a trade – the sending user will get an error message and not be able to trade. This should also alert the owner of the liquidity pool – and possibly trigger a community process to refill the pool.
|
||||
|
||||
### Conversion User Flow
|
||||
User Bob chooses to send 40 B tokens to Sally who has S as her home token.
|
||||
The system 1st checks to see if there is a liquidity pool (or path between pools) with sufficient supply to
|
||||
give back 40 S ….. if less than 40 S are available (or there is a bonded pool) it will tell Bob the most he can receive (quotation and he could specify the minimum he wants in return to allow an exchange).
|
||||
|
||||
If there is sufficient liquidity in the pool(s) then his 40 B will be added to the pool and 40 S removed and given to Sally.
|
||||
|
||||
## Liquidity pool creation process
|
||||
1. GE holind 2 tokens will add a supply of both to a liquiditiy pool with a 1:1 excahnge rate.
|
||||
1. THe pool needs to be added it to the registry
|
||||
1. A static pool will/can become empty on one side and will stop to function in that director of conversion
|
||||
|
||||
|
||||
## 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
|
||||
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
|
||||
|
||||
## Manual convert
|
||||
1. For admin accounts we may want to convert from and to specific tokens via the Managment Platform
|
||||
2. Admins may also want to convert a users tokens who are failing to auto convert
|
||||
|
||||
|
||||
## Testing
|
||||
|
|
@ -138,10 +82,7 @@ If there is sufficient liquidity in the pool(s) then his 40 B will be added to t
|
|||
|
||||
|
||||
## Security
|
||||
1. Liquidity pool supply and value Alerts
|
||||
1. For bonded pools: Whenever the token is converted to another token and the price changes more than 10% an alter is sent to the token issuer
|
||||
1. For Bonded Pools: 1. Message Alert your excahnge value of TOKEN_NAME tokens have changed in +X% / -X% value
|
||||
1. Note that the receipt messages for token transfers that include a conversion should also show the tokens exchange value
|
||||
1.
|
||||
|
||||
|
||||
## Changelog
|
||||
|
|
|
|||
Loading…
Reference in New Issue