grassrootseconomics/cic-docs
5
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
3c1d728e48
cic-docs/spec/021_manual_token_creation.md

7.0 KiB
Raw Blame History

Manual Token Creation spec

  • Authors: Will Ruddick willruddick@gmail.com (grassecon.org)
  • Date: 2021.05.11
  • Version: 2
  • 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)

Intro

  • Today users only receive Sarafu created by Grassroots Economics
  • This means Users have very little ownership or feel the need to accept or back the token.
  • We want users to be able to create their tokens to create more ownership and diffusion.
  • A CIC primarliy represents the goods and services committed by the Issuer.

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)
  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.
  5. Initally conversion between tokens will not be allowed (see conversion below)

Inputs

  1. Signed Membership Application
  2. if not Sarafu
    1. Accounts (walllet address) of all users in membership application
    2. Token Long Name - 128 character limit
    3. Token short name no more than 6 Character - must be unique
    4. A maximum supply should be set to the token supply.
    5. Demurrage set to accumulate to 2% a month
  3. Token Supply to be minted
  4. All blockchain wallet addresses in application

Token creation process - Backend

  1. Ensure TOKEN_Name is unique
  2. Create / mint the token supply
  3. sarafu-token-deploy or giftable-token-deploy
  4. eth-token-index-add
  5. eth-address-declarator-add
  6. to discover the contract addresses on the network you use:
    1. eth-contract-registry-list
  7. Put the TOKEN_NAME tokens into the Users wallet (as per agreement)
  8. All members in the agreement should have their community token set to TOKEN_NAME

Join Token

  1. 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

Token creation Interface - UX

Command Line - CLI

  1. Process Inputs on command line
  2. Confirmation please type the token name to proceed
  3. Ability to send specific ammounts of the token to addresses in the agreement (csv)

CIC Mgmt Platform - GUI

  1. On a user account there should be a button for Create Token - - this required super admin privlages
  2. The next page comes up with the inputs above
  3. 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.
  2. THe pool needs to be added it to the registry
  3. 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
  2. When a user recieves a token we automatically try to convert that token into her Community token
  3. We should be able to turn this feature off for selected users (like admins)
  4. 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

  1. Ensure conversions are working between tokens when liquidity pools exist and not when they dont
  2. Test out auto-conversion - one user gets sent a foreign token ... try to convert

Action items

Implementation

Workflow

Variables

Interface

Security

  1. Liquidity pool supply and value Alerts
  2. 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
  3. For Bonded Pools: 1. Message Alert your excahnge value of TOKEN_NAME tokens have changed in +X% / -X% value
  4. Note that the receipt messages for token transfers that include a conversion should also show the tokens exchange value

Changelog