cicnet/erc20-demurrage-token
5
0
Fork 0
mirror of git://holbrook.no/erc20-demurrage-token synced 2024-11-22 16:26:46 +01:00
Code Issues Packages Projects Releases Wiki Activity

updated to a time-frame reference with minute resolution - rather than blocks

Browse Source
This commit is contained in:
Will Ruddick 2021-02-06 15:40:23 +00:00
parent 0f816ebdc5
commit e32001e7e0
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
README.md
View File

@ -4,13 +4,13 @@
* Network / Basic Income Token * Network / Basic Income Token
* 100 Sarafu is distributed to anyone in Kenya after user validation by the owner of a faucet which mints new Sarafu. * 100 Sarafu is distributed to anyone in Kenya after user validation by the owner of a faucet which mints new Sarafu.
* Validated users are those that validate their phone number in Kenya. * Validated users are those that validate their phone number in Kenya.
* A monthly Sarafu holding tax aka ([demurrage](https://en.wikipedia.org/wiki/Demurrage_(currency))) of 2% is deducted from users * A Sarafu holding tax aka ([demurrage](https://en.wikipedia.org/wiki/Demurrage_(currency))) of 0.000050105908373373% is charged from users per minute - such that over 1 month to total tax would be 2%.
* Each month (after a number of blocks) the total amount tax is distributed evenly out to _active_ users. * After 1 week the total amount tax is distributed evenly out to _active_ users.
* any single transaction by a user is considered _active_ (heartbeat) (possibly add minimum size of heartbeat in constructor (TODO)) * any single transaction by a user within that week is considered _active_ (heartbeat)
* This is meant to result in a disincentivization to hold (hodl) the Sarafu token and increase its usage as a medium of exchange rather than a store of value. * This is meant to result in a disincentivization to hold (hodl) the Sarafu token and increase its usage as a medium of exchange rather than a store of value.
* This token can be added to liquidity pools with other ERC20 tokens and or Community Inclusion Currencies (CICs) - and thereby act as a central network token and connect various tokens and CICs together. * This token can be added to liquidity pools with other ERC20 tokens and or Community Inclusion Currencies (CICs) - and thereby act as a central network token and connect various tokens and CICs together.
* Example * Example
- With a demurrage of 2% - If there are 10 users all with balances of 1000 Sarafu and only 2 of them trade (assume they trade back and forth with no net balance change). - With a demurrage of 2% (net per month) and a reward period of 1 month - If there are 10 users all with balances of 1000 Sarafu and only 2 of them trade that month (assume they trade back and forth with no net balance change).
- Then the resulting balances after one tax period of those two trading would be 1080 Sarafu while the remaining non-active users would be 980 Sarafu. If this behaviour continued in the next tax period, with the same two users only trading (with no net balance changes), they would have 1158.39999968 Sarafu and those users that are not trading would have their balances further reduced to 960.40 Sarafu. If this continued on ~forever those two active trading users would have the entire token supply and the non-trading users would eventually reach a zero balance. - Then the resulting balances after one tax period of those two trading would be 1080 Sarafu while the remaining non-active users would be 980 Sarafu. If this behaviour continued in the next tax period, with the same two users only trading (with no net balance changes), they would have 1158.39999968 Sarafu and those users that are not trading would have their balances further reduced to 960.40 Sarafu. If this continued on ~forever those two active trading users would have the entire token supply and the non-trading users would eventually reach a zero balance.
- this example calculation for 3 tax periods can be found here: https://gitlab.com/grassrootseconomics/cic-docs/-/blob/master/demurrage-redist-sarafu.ods - this example calculation for 3 tax periods can be found here: https://gitlab.com/grassrootseconomics/cic-docs/-/blob/master/demurrage-redist-sarafu.ods
@ -18,8 +18,8 @@
## Variables ## Variables
* Inputs to Constructor (Set only once during contract deployment can't be changed ) * Inputs to Constructor (Set only once during contract deployment can't be changed )
* `Demurrage` aka Decay amount: A percentage of token supply that will be charged once per - aka `period` and evenly redistributed to _active_ users * `Demurrage` aka Decay amount: A percentage of token supply that will be charged once per minute and evenly redistributed to _active_ users every Demurrage Period (minutes)
* Demurrage Period (blocks)- aka `period`: The number of blocks (equivalent to a time frame) over which a new Holding Fee is applied and redistributed. * Demurrage Period (minutes)- aka `period`: The number of minutes over which a user must be _active_ to receive tax-redistibution.
* Inflated Balance: The inflated balance of each user is stored for bookkeeping. * Inflated Balance: The inflated balance of each user is stored for bookkeeping.
* Number of Decimals: Resolution on token (TODO) (Default 6) * Number of Decimals: Resolution on token (TODO) (Default 6)
* Minimum Activity Volume: (TODO) the minimum transaction amount to be considered active * Minimum Activity Volume: (TODO) the minimum transaction amount to be considered active
@ -41,12 +41,12 @@
## Demurrage ## Demurrage
* Holding Tax (`demurrage`) is applied when a **mint** or **transfer** is triggered for first time/block in a new `period`; (it can also be triggered explicitly) * Holding Tax (`demurrage`) is applied when a **mint** or **transfer**; (it can also be triggered explicitly)
- Supply _stays the same_. - Note that the token supply _stays the same_ but a virtual _balance output_ is created.
- Updates `demurrageModifier` which represents the accumulated tax value and is an exponential decay step (of size `demurrage`) for each `period` - Updates `demurrageModifier` which represents the accumulated tax value and is an exponential decay step (of size `demurrage`) for each minute that has passed.
- `demurrageModifier = (1-demurrage)^period` - `demurrageModifier = (1-demurrage)^(minute_passed)`
- e.g. a `demurrage` of 2% at a `period` of 1 would be give a `demurrageModifier = (1-0.02)^1 = 0.98`. - e.g. a `demurrage` of 2% after the 1st minute would be give a `demurrageModifier = (1-0.02)^1 = 0.98`.
- e.g. a `demurrage` of 2% at a `period` of 2 would be give a `demurrageModifier = (1-0.02)^2 = 0.9604`. - e.g. a `demurrage` after the 2nd minute would be give a `demurrageModifier = (1-0.02)^2 = 0.9604`.
* All client-facing values (_balance output_ , _transfer inputs_) are adjusted with `demurrageModifier`. * All client-facing values (_balance output_ , _transfer inputs_) are adjusted with `demurrageModifier`.
- e.g. `_balance output_ = user_balance - user_balance * demurrageModifier` - e.g. `_balance output_ = user_balance - user_balance * demurrageModifier`
* Edge case: `approve` call, which may be called on either side of a period. * Edge case: `approve` call, which may be called on either side of a period.
@ -54,13 +54,13 @@
## Redistribution ## Redistribution
* One redistribution entry is added to storage for each period; * One redistribution entry is added to storage for each `period`;
- When `mint` is triggered, the new totalsupply is stored to the entry - When `mint` is triggered, the new totalsupply is stored to the entry
- When `transfer` is triggered, and the account did not yet participate in the `period`, the entry's participant count is incremented. - When `transfer` is triggered, and the account did not yet participate in the `period`, the entry's participant count is incremented.
* Account must have "participated" in a period to be redistribution beneficiary. * Account must have "participated" in a period to be redistribution beneficiary.
* Redistribution is applied when an account triggers a **transfer** for the first time in a new period; * Redistribution is applied when an account triggers a **transfer** for the first time in a new `period`;
- Check if user has participated in `period`. (_active_ user heartbeat) - Check if user has participated in `period`. (_active_ user heartbeat)
- Each _active_ user balance is increased by `(total supply at end of period * demurrageModifier ) / number_of_active_participants` via minting - Each _active_ user balance in the `period` is increased by `(total supply at end of period * demurrageModifier ) / number_of_active_participants` via minting
- Participation field is zeroed out for that user. - Participation field is zeroed out for that user.
* Fractions must be rounded down (TODO) * Fractions must be rounded down (TODO)
- Remainder is "dust" and should be sent to a dedicated "sink" token address (TODO) - Remainder is "dust" and should be sent to a dedicated "sink" token address (TODO)