Compare commits
No commits in common. "master" and "max-cash-out-feature" have entirely different histories.
master
...
max-cash-o
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
name: Bug report
|
||||
about: Create a report to help us improve
|
||||
title: ''
|
||||
labels: ''
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
please keep explanations in this section brief
|
||||
-->
|
||||
|
||||
**Did you read _all_ the READMEs and are system requirements fulfilled?**
|
||||
|
||||
**What did you try to do?**
|
||||
|
||||
**What did you expect should have happened?**
|
||||
|
||||
**What happened instead?**
|
||||
|
||||
**What were the exact steps you took?**
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
here you can indulge more detailed rants about the problem
|
||||
-->
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
name: Feature request
|
||||
about: Suggest an idea for this project
|
||||
title: ''
|
||||
labels: ''
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
**Is your feature request related to a problem? Please describe.**
|
||||
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
|
||||
|
||||
**Describe the solution you'd like**
|
||||
A clear and concise description of what you want to happen.
|
||||
|
||||
**Describe alternatives you've considered**
|
||||
A clear and concise description of any alternative solutions or features you've considered.
|
||||
|
||||
**Additional context**
|
||||
Add any other context or screenshots about the feature request here.
|
||||
Binary file not shown.
|
|
@ -1,2 +1,7 @@
|
|||
## Community Inclusion Currencies (CICs) Documentation -
|
||||
Please visit https://gitlab.com/grassrootseconomics/cic-docs/-/blob/master/README.md
|
||||
## Community Inclusion Currencies (CICs) Documentation
|
||||
+ White Paper: https://docs.google.com/document/d/1Wmnpjc5bX1b8XP1kNtiZCqurMYw__4sNmdHjtSnnLWQ/edit?usp=sharing
|
||||
+ Frequently Asked Questions: https://docs.google.com/document/d/1qtlOEL4pqW1vOL893BaXH9OqRSAO3k0q2eWbVIkxEvU/edit?usp=sharing
|
||||
+ Blog: https://grassecon.org/blog
|
||||
+ CIC Platform: https://github.com/teamsempo
|
||||
+ CIC Blockchain Smart Contract: https://github.com/GrassrootsEconomics/CIC-Liquid-Token
|
||||
+ Data - Transaction Datasets: https://www.grassrootseconomics.org/research
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The Transaction csv fields:
|
|||
|
||||
1. id - internal transaction ID number
|
||||
1. timeset - date and time of transaction
|
||||
1. transfer_subtype - internal typing: DISBURSMENT = from Grassroots Economics, RECLEMATION = Back to GE, STANDARD = a trade between users, AGENT = when a group account is cashing out (see held_roles) below
|
||||
1. transfer_subtype - internal typing: DISBURSMENT = from Grassroots Economics, RECLEMATION = Back to GE, STANDARD = a trade between users, AGENT = when a group account is cashing out
|
||||
1. transfer_use - The category the sender marked the transaction as - used for 'confidence' later for the user category - note this will be changed to boolean
|
||||
1. tx_hash - hashed transaction address on blockchain
|
||||
1. source - wallet ID of sender
|
||||
|
|
@ -41,8 +41,7 @@ The user summary csv fields:
|
|||
1. old_POA__blockchain_address - Wallet ID on POA Blockchain if they had one
|
||||
1. comm_tkn - Their token name (each user only has 1 token) currenlty only Sarafu
|
||||
1. bal - current balance of [comm_tkn] as of file date
|
||||
1. location - User input (village name)
|
||||
1. held_roles - Standard transactions are between Beneficiaries, anything to an Admin is a Reclemation or from and Admin is a Disbursment and anything to a Agent is a Agent_out
|
||||
1. location - User input (village name)
|
||||
1. gender
|
||||
1. business_type - Input by GE staff based on what the users sell
|
||||
1. ovol_in - total number of tokens that came into this account from non-STANDARD transactions
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
git clone https://gitlab.com/nolash/grassroots-app
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
# Current Platform Incentives spec
|
||||
|
||||
<!--
|
||||
valid status values are: Pre-draft|Draft|Proposal|Accepted
|
||||
-->
|
||||
* Authors: Will Ruddick <willruddick@gmail.com> (grassecon.org)
|
||||
* Date: 2020.04.22
|
||||
* Version: 1
|
||||
* Status: Pre-draft
|
||||
|
||||
## Rationale
|
||||
The current system seeks to maximize circulation in order to fill market gaps and help CIC users to support eachother.
|
||||
|
||||
## Currently
|
||||
Grassroots Economics started with a pool of 8 Million Sarafu tokens (which they value 1:1 with Kenyan Shillings ala buy backs). Of which 90% will have been distributed to users as below by the end of April 2020.
|
||||
The following are all rules are platform based (not blockchain contract based). Note that these rules are for the Sarafu CIC only and are not meant to be the rules for other CIC creators.
|
||||
1. *airdrop-selfservice*: New users get 50 Sarafu (a CIC) (Shown as Disbursement in database)
|
||||
1. *airdrop-full-profile*: New users that fill out their profiles (name, business, location, gender) get additional 400 Sarafu (a CIC) (must call office line) (Shown as Disbursement in database)
|
||||
1. *referral*: Users that are the 1st to send a new user at least 20 tokens in the 1st 24 hours get 100 Sarafu - after that new user has begun to trade with another user (not the referrer) (Shown as Disbursement in database)
|
||||
1. *chama bonus*: Savings Groups (aka Chamas are groups of users that save and give loans to eachother) get 10,000 Sarafu divided between their members after 2 months of trading.(Shown as Disbursement in database)
|
||||
1. *chama redemption*: Savings Groups can redeem 50% of their Sarafu Balance for Kenyan Shillings up to a maximum of 30k Sarafu each month but must have spent (and/or given loans) of at least as much as they want to cash out. (Shown as Agent_out in database) Cashing out is done using donor funds by Grassroots Economics Foundation and Sarafu is valued 1:1 with Kenyan shilligns using eMoney (Mpesa).
|
||||
1. *usage bonus*: Users get a daily or weekly Sarafu bonues depending on how they trade. They are ranked by the number of other people they trade above 20 Sarafu with and awarded based on their percentage of such overall trade. (Possibly moving to k-cycle centrality).(Shown as Disbursement in database)
|
||||
1. *Holding Fee*: If an account if dormant (no trades in or out) for 7 days 20 Sarafu are deducted and added back to the pool. (Shown as Reclaimation in database)
|
||||
1. *Donation bonues* Anyone with Mpesa or Bonga points can send them to Grassroots Economics to receive additional Sarafu (Shown as Disbursement in database) Donors can give Grassroots Economics funds to support the Sarafu buy-back and operations
|
||||
|
||||
## After
|
||||
After the migration to xDAI (https://github.com/GrassrootsEconomics/CIC-Docs/blob/master/spec/xdai_migration.md)
|
||||
anyone (with access to blockchain) in the world can contribute reserve in the form of xDAI. xDAI is a stable token to the US dollar and can be purchased with USD.
|
||||
With a reserve in xDAI each Sarafu token will now have spot price or excahnge price to xDAI given by P = R/(S*TRR)
|
||||
Where R = the amount of xDAI in reserve, S= the total supply of Sarafu, and TRR = Target Reserve Ratio = that ratio of R/S such that the echange price is 1:1.
|
||||
1. Grassroots Economics will continue with all the above incentives for Sarafu and to buy the vouchers off on a regular basis 1:1 from Savings groups.
|
||||
1. Any funds going into the reserve will increase the price and mint additional Sarafu following a bonding curve.
|
||||
Anyone with a webApp or MetaMask can add xDAI and mint more Sarafu (+) increase the value of all Sarafu
|
||||
Anyone with a webApp or MetaMask can add send Sarafu to the converter contract to destroy it and withdraw reserve (-) decreasing the value of all Sarafu.
|
||||
1. As the reserve of Sarafu is depleted and the exchange price drops Grassroots Economics as well as other donors will add more reserve and mint more tokens to distribute.
|
||||
1. Grassroots Economics will destroy Sarafu it collects to pull out excess reserve and convert that xDAI to Kenyan shillings to continue with Savings Group buy backs.
|
||||
1. A % fee on conversion between reserve and supply in both directions is done on blockchain and added to the reserve.
|
||||
|
||||
|
||||
## Implementation
|
||||
|
||||
### Workflow
|
||||
|
||||
### Variables
|
||||
|
||||
### Interface
|
||||
|
||||
|
||||
## Testing
|
||||
<!--
|
||||
Please describe what test vectors that are required for this implementation
|
||||
-->
|
||||
|
||||
## Changelog
|
||||
<!--
|
||||
Please remember to describe every change to this document in the changelog using
|
||||
serial number:
|
||||
|
||||
* version 1:
|
||||
-->
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
# xDAI Migration spec
|
||||
|
||||
<!--
|
||||
valid status values are: Pre-draft
|
||||
-->
|
||||
* Authors: Will Ruddick <will@grassecon.org>
|
||||
* Date: 2020.04.22
|
||||
* Version: 1
|
||||
* Status: Pre-draft
|
||||
|
||||
## Rationale
|
||||
We want to give donors and community mambers a way to contribute to and cash out from Community Inclusion Currencies with National Currency. By connecting to a reserve that is stable to the US dollar called xDAI we bring some stability and the ability for many to support local communities. We also enable any CICs that have xDAI as a reserve to convert to any other CIC with xDAI as reserve.
|
||||
|
||||
## Before
|
||||
Currently we are using a virtual reserve a generic ERC20 token. We have 2 Million of those reserve tokens against 8 Million Sarafu issued (the current Kenyan CIC). (Call those Sarafu_1 or S1)
|
||||
|
||||
## After
|
||||
We have 40,000 xDAI to put as the reserve and are looking at minting O(16Million) tokens (called Sarafu_2 S2)
|
||||
with a connector weight (target Reserve Ratio) of 0.25 (25%) and an inital price of roughly 0.01 Sarafu to a xDAI (USD stable)
|
||||
|
||||
## 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
|
||||
1. Synch db <->Blockchain - ensure synronization between our db (USSD interface) and blockchain
|
||||
1. Create group of govenors on a multi-sig wallet with the power to assign the facilitator address of all blockchain contracts.
|
||||
1. Create a white list for token users
|
||||
1. Deploy contracts to create Sarafu_2, set inital variables - deposit reserve and mint tokens
|
||||
1. Migration - New wallets for users - Replicate user accounts with new token Sarafu_2
|
||||
|
||||
### Variables
|
||||
|
||||
1. Synch variables, - synch frequency - and limitations
|
||||
2. Contract variables (reserve ratio (0.25), reserve amount (40k xDAI), number of Sarafu_2 (16Million), convert fee 0.005 (0.5%))
|
||||
3. Migration speed - how often is synching done between USSD db and blockchain
|
||||
4. 3rd party Fiat <-> xDAI conversion costs and speed
|
||||
|
||||
### Interface
|
||||
This migration will all be done at code and command line level, while some testing can be done on the platform gui
|
||||
|
||||
## Testing
|
||||
1. Check db<->blockchain synch - verify they are synched and we can do external transactions and handle RPC failure
|
||||
1. Token Governance
|
||||
1. Contract deplyment - conversions, transfers all work as expected
|
||||
1. Migration - new wallets match old wallets
|
||||
1. Store old blockchain wallet IDs (as a list with old POA wallets)
|
||||
|
||||
|
||||
## Changelog
|
||||
<!--
|
||||
Please remember to describe every change to this document in the changelog using
|
||||
serial number:
|
||||
|
||||
* version 1:
|
||||
-->
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
# Depth Bump - Add new tokens to reserve and supply with a specified price
|
||||
|
||||
Author: Will Ruddick
|
||||
Date: 2020.03.16
|
||||
Version: 0.0.2
|
||||
|
||||
## Rationale
|
||||
|
||||
Moving to xDAI looks unstable right now. In order to increase our token supply we can increase the amount of virtual reserve and CIC supply and keep the price fixed.
|
||||
|
||||
## Before
|
||||
|
||||
We have a virtual token right now as the reserve.
|
||||
|
||||
## After
|
||||
|
||||
We would need to be able to mint tokens and the reserve outside of the bonding curve.
|
||||
The idea would be to keep the price 1:1 with reserve and increase both reserve and supply (off the curve)
|
||||
|
||||
## Implementation
|
||||
|
||||
### Workflow
|
||||
|
||||
* return ownership of the token to a person (not the converter)
|
||||
* mint more tokens (off the curve)'
|
||||
* give ownership back to the converter
|
||||
* add more virtual reserve to the converter
|
||||
|
||||
### Variables
|
||||
|
||||
* Amount of supply to add S2 16,000,000
|
||||
* Amount of Reserve to add R2 8,000,000
|
||||
* Resulting Exchange Price: P2 1.0
|
||||
|
||||
* Existing CIC Supply: S1 ~8,000,000
|
||||
* Existing Reserve: R1 ~2,000,000
|
||||
* Existing Price: P1 ~1.0
|
||||
|
||||
### Interface
|
||||
|
||||
cmd: depthbump <-s targetsupply> <-p price>
|
||||
|
||||
## Testing
|
||||
|
||||
```
|
||||
cmd: depthbump targetsupply=16000000.0 price=1.0
|
||||
|
||||
You are creating (16000000.0 - S1) new tokens? (yes/no/quit)
|
||||
You are creating ((16000000.0)/4-R1)*P2 new reserve tokens? (yes/no/quit)
|
||||
|
||||
....
|
||||
|
||||
the new supply of CIC should be: 16,000,000
|
||||
the new reserve should be: 4,000,000
|
||||
|
||||
(error if P2 != 4(R1+R2)/(S1+S2)) (where 4 is 1/cw from converter contract)
|
||||
(warning if P2 != P1 and confirmation)
|
||||
```
|
||||
|
||||
|
||||
## Changelog
|
||||
|
||||
* 0.0.2: Clean up formatting, subsection implementation
|
||||
* 0.0.1: Created initial stub
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
|
||||
# Public View Only
|
||||
|
||||
1. View public data only and no ability to edit
|
||||
|
||||
# Private View Only
|
||||
|
||||
1. View private data and no ability to edit
|
||||
|
||||
Private data inlcudes, names, phone numbers, location
|
||||
|
||||
# Enroller
|
||||
|
||||
1. See private data
|
||||
1. Add users
|
||||
1. Edit user fields
|
||||
1. Pin reset
|
||||
1. Initial Disbursement only (1 time per user with a max of 400)
|
||||
1. Disbursement (besides initial) and reclamation (with approval of Admin)
|
||||
|
||||
# Admin
|
||||
|
||||
1. See private data
|
||||
1. Add users
|
||||
1. Edit user fields
|
||||
1. Pin reset
|
||||
1. Disbursement and reclamation (without approval)
|
||||
1. Give approval to Enrollers
|
||||
|
||||
# Super Admin
|
||||
|
||||
1. Assign the roles (Suber Admin, Enroller, View Only)
|
||||
1. See private data
|
||||
1. Add users
|
||||
1. Edit user fields
|
||||
1. Pin reset
|
||||
1. Disbursement and reclamation (without approval)
|
||||
1. Give approval to Enrollers
|
||||
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
## USSD Menu Staging (```*483*061#```)
|
||||
-----------------------
|
||||
## User Creation
|
||||
* Create a new user via self service (Dial the code above with a phone number not in the system)
|
||||
* ensure user is setup correctly and given (50) tokens
|
||||
* ensure user can set their profile information and check the information
|
||||
* See my profile
|
||||
* Change my business, name, location
|
||||
* Check balance
|
||||
* Change pin
|
||||
* Opt out of market place
|
||||
* ☐ Create a new user via webpage
|
||||
|
||||
## User Types
|
||||
* ☐ Change a user type to Group and Agent
|
||||
* ☐ Change an existing user type to Chama and Agent and test features work like exchange - then back to User and test again
|
||||
|
||||
|
||||
## Pin Reset
|
||||
* ☐ Reset pin for a user
|
||||
|
||||
## Disburse Reclaim
|
||||
* ☐ Disburse and reclaim a token from menu
|
||||
|
||||
## Change language
|
||||
* ☐ English / Kiswahili (do this entire process in both languages -- checking spellings)
|
||||
|
||||
## Send
|
||||
* ☐ Send to registered number
|
||||
* ☐ Verify both parties got the receipt SMS after a transfer
|
||||
* ☐ recheck the balance of each user to verify on our platform
|
||||
* ☐ recheck the balance of each user to verify on blockchain
|
||||
|
||||
* ☐ Send to number not registered
|
||||
* ☐ Verify both you and they both got a SMS
|
||||
|
||||
* ☐ Send from an account with insufficient balance
|
||||
* ☐ Verify SMS with balance
|
||||
|
||||
## Market place
|
||||
* ☐ Check all Business categories
|
||||
* ☐ Check all directory entries on Directory
|
||||
|
||||
|
||||
## Exchange
|
||||
* ☐ Check exchange rate
|
||||
* ☐ Create a Token Agent
|
||||
* ☐ Create a Chama
|
||||
* ☐ Check that Exchange doesn’t work for a normal user
|
||||
* ☐ Check that Exchange only works for a Chama to and Agent
|
||||
* ☐ Check that a 2nd Exchange doesn't work (should only allow it once ever 30 days)
|
||||
* ☐ Check that regular transfers do not work to an Agent
|
||||
*
|
||||
|
||||
## Help
|
||||
* ☐ Correct helpline 0757628885
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
# Title
|
||||
|
||||
<!--
|
||||
valid status values are: Pre-draft|Draft|Proposal|Accepted
|
||||
-->
|
||||
* Authors: Firstname Lastname <email> (url)
|
||||
* Date: YYYY.MM.DD
|
||||
* Version: 1
|
||||
* Status: Pre-draft
|
||||
|
||||
## Rationale
|
||||
<!--
|
||||
Why are you proposing this?
|
||||
-->
|
||||
|
||||
## Before
|
||||
<!--
|
||||
What is the current state of the described topic?
|
||||
-->
|
||||
|
||||
## After
|
||||
<!--
|
||||
How will things be different after this has been done?
|
||||
-->
|
||||
|
||||
## Implementation
|
||||
<!--
|
||||
Here is the description of how these changes should be implemented.
|
||||
Please use subheadings to improve readability.
|
||||
Some suggestions:
|
||||
|
||||
### Workflow
|
||||
|
||||
### Variables
|
||||
|
||||
### Interface
|
||||
-->
|
||||
|
||||
## Testing
|
||||
<!--
|
||||
Please describe what test vectors that are required for this implementation
|
||||
-->
|
||||
|
||||
## Changelog
|
||||
<!--
|
||||
Please remember to describe every change to this document in the changelog using
|
||||
serial number:
|
||||
|
||||
* version 1:
|
||||
-->
|
||||
Loading…
Reference in New Issue