From 2074c23ea2a06a5e8ad199040b6e6c9f98c45ab9 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:17:06 +0300 Subject: [PATCH 01/32] test --- bsip-0043.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0043.md b/bsip-0043.md index 7c5e328..406c71c 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -10,7 +10,7 @@ # Abstract - + When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. From 015c21011bcd26bc9f1d9edbfef229e506b80a77 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:28:36 +0300 Subject: [PATCH 02/32] test 2 --- bsip-0043.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index 406c71c..d368943 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -7,8 +7,8 @@ Updated: 2018-10-19 Discussion: https://github.com/bitshares/bsips/issues/102 Worker: - - + + # Abstract When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. From ad28bd4157396a973a3c3f92e2ae7ae8e3e034fe Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:34:28 +0300 Subject: [PATCH 03/32] initial draft commit --- bsip-00Dynamic.md | 150 +++++++++++++++++++++++++++++++++++++++++++ bsip-00Sharedrop.md | 151 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 301 insertions(+) create mode 100644 bsip-00Dynamic.md create mode 100644 bsip-00Sharedrop.md diff --git a/bsip-00Dynamic.md b/bsip-00Dynamic.md new file mode 100644 index 0000000..f25e118 --- /dev/null +++ b/bsip-00Dynamic.md @@ -0,0 +1,150 @@ + BSIP: 00XX + Title: Dynamic Market Fees + Authors: OpenLedgerApp + Status: Draft + Type: Protocol + Created: 2018-12-10 + Updated: 2018-12-10 + Discussion: https://github.com/bitshares/bsips/issues/130 + Worker: (optional) +# Abstract +UIA owners does not have many marketing tools to increase trade volume of their assets. + +One of the ways to increase the trade volume can be Dynamic Market Fees that will provide additional discounts for active traders. +For example, to set lower fees for trading larger volumes. + +So, instead of market fee, an asset owner can optionally set up dynamic_market_fee_percent property that may look like a following example table. + + +## Motivation + +- To provide additional marketing tools to encourage traders. +- To increase trading volume on BitShares. +- To attract traders to the ecosystem. + +# Rationale + +## Use cases: + +**1) Supporting money makers.** +Every trade occurs between two parties: the maker, whose order exists on the order book prior to the trade, and the taker, who places the order that matches (or "takes") the maker's order. + +Makers are so named because their orders make the liquidity in a market. Takers are the ones who remove this liquidity by matching makers' orders with their own. + +The maker-taker model encourages market liquidity by rewarding the makers of that liquidity with a fee discount. It also results in a tighter market spread due to the increased incentive for makers to outbid each other. The higher fee that the taker pays is usually offset by the better prices this tighter spread provides. + +**2) Supporting heavy volume traders.** +Fees are charged and deduced on a per-trade basis. The bigger “trading volume” users have traded, the lower fee they get on subsequent trades. + +# General notes + +Each asset will have either usual market fee or a table with dynamic market fees that will represent the table above. + +A switch market_fee_type (REGULAR, DYNAMIC) should clearly indicate, which market fee type is used. + +**Makers** are the ones who put up their orders first. + +And **takers** are the ones to put up their orders later in time than makers. + +# Discussion + +We have had a discussion what's the best way to average out Trading Volume. + +There are a few ways of doing this: + +Use an average volume since day the beginning of trading. +Up for discussion is - what to take as a day 1. 1st trade of this asset? 1st trade minus 30 days? Account open date? +This way we have a normal fair average volume if we figure out the fair beginning interval date. +However, if a trader started trading this asset a few years ago he might be in a significant disadvantage. + +Average trading volume over the last 30 days - sliding window. +This way it is a bit clearer how to calculate. +However there might be extreme but real cases where this kind of calculation might not be fair: +a. when a person who usually trades high volumes throughout the year goes to vacation for 30 days. Suddenly all his discount is gone when he comes back +b. When another person comes in and makes 1 or 2 high volume trades while trading really low volumes before that. Suddenly this person might have a big discount. +30-day volume +This mehod gives enough information to figure out last 30-days traders habits with much lower memory requirements but slightly less precision than the 30-day average sliding window. +Average trading volume over the last 365 days (a year). + +# Technical Specifications + +We suggest using average total volume for a particular asset. However, it's open for the discussion. + +## Statistics Storage** + +There are two options for storing account statistics for trading: + +1. expand class account_statistics_object by adding a map of trade_statistics_object for each asset +2. create a new type trade_statistics_object and a new index + + +## Statistics Update +Statistics updates during fill_order. +We need to update statistics for the user and for the specific asset at the same time. + + + +## Calculations + +### Average since Day 1 + +**Trader Activity** is estimated as average trading volume of a user for a given asset for 1 day. + +`Trader_activity = total_volume / (Now - first_start_date) //(in days). +` +This way we accumulate total bought volume for each user for each asset and average out daily volumes for his entire term of trading of this asset (per day). + +Volume discounts are estimated based on the average daily Trader_Activity * 30 days. + +_Trade statistics object_ + + +``` +class trade_statistics_object +{ + +account_id_type owner; +asset_id_type asset; +timestamp first_trade_date; //first trade date for this asset +share_type total_volume; //total bought asset volume +}; +``` + +### 30-day sliding window average + +In `trade_statistics_object` we need to store the queue of volumes aggregated by 1 day. In other words, for each asset a user should have a queue of 30 daily volumes. + +During the first maintenance interval of the day, yesterday's volume will be added to the queue and the oldest volume will be deleted (for each asset even for assets where there was no trade done). + +This way it will cost significant memory usage!!! + +Technically we can store only the aggregated sum for 30 days and take the first day volumes from the blockchain. This will take less memory but will take more CPU time. + + +### 30-day volume method + +Alternative way would be to store one 30-day volume for each asset for each user. This way we would only need one 30-day volume and one aggregated daily volume for today. i.e. only 2 values for each asset. + +So the memory requirements will be at least 30 times less than in a previous method. + +The algorithm is like this: +For example, the 30-day volume is 90. Hence daily average is 3. Let's say today's volume is 13. +First of all, we subtract average daily volume from the 30-day volume. 90-3 =87. +Then we add today's volume. So the new 30-day volume would be 87+13 = 100. A new daily average would be 100/30 = 3.33333 + +### 365-day sliding window average + +This is similar to the 30-day sliding window average except the memory requirements for the stored values are SIGNIFICANTLY larger. + +## Potential issues +We need to make sure that the suggested calculations will not lead to the significantly wrong results or the blockchain abuse. +We need to consider border conditions: For example, when there is no statistics at all, unusual statistics of many very small orders, very large order at the beginning of the average window and then no activity registered, etc. + + +## Technical challenges +Some problems include performance as an additional search and update new index are required. + +# Copyright +This document is placed in the public domain. + +# See Also diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md new file mode 100644 index 0000000..70d837d --- /dev/null +++ b/bsip-00Sharedrop.md @@ -0,0 +1,151 @@ + BSIP: 00XX + Title: Sharedrop operation + Authors: OpenLedgerApp + Status: Draft + Type: Protocol + Created: 2018-12-10 + Updated: 2018-12-10 + Discussion: + Worker: + +A sharedrop is a giveaway of some tokens to a certain group of people, for example to all BTS holders in proportion to their holdings. +# Abstract +We should add the ability to distribute arbitrary amount of some token (SHAREDROP token) to holders of a specific other token (STAKE token) according to the share(stake) of such tokens. +The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). + + +# Motivation +TBD - девелоперам не нужно +# Rationale +TBD - девелоперам не нужно +To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. + +Sharedrop operation should be quite expensive as well. +However, to make such an expensive operation more lucrative for BtiShares - the sharedrop operation will send the money to each stakeholder's vesting balance. Thus making them withdraw the drop from the vesting balances. + + +# Specifications +## General workflow +First of all, there is a need to calculate transaction fee, so Calculate operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. + +Then, knowing that user has enough BTS for transaction fees and vesting money, he should call Sharedrop operation itself. Vesting specifics will be covered below. + +Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. + +## Calculate operation + +This is a locally done operation with the following parameters: + +Sharedrop asset +Sharedrop amount +Stake asset +Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) +Calculate operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. + +This will be approximate calculation as the final calculation will be determined only during the sharedrop operation. + +The following parameters are calculated by a node and presented to the user: + +Sharedrop operation price +Sharedrop vesting stake +sharedrop vesting period +## Sharedrop operation + +Sharedrop operation should be available with the following parameters: + +Sharedrop asset +Sharedrop amount +Stake asset +Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) +Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. + +Each stakeholder will then need to retrieve the sharedrop token from the vesting balance in a separate operation. + +If the amount to distribute for stakeholders is too small and cannot be distributed among stakehoders or part of stakeholders then it accumulates and is returned to the account that originated sharedrop operation. + +## Sharedrop Parameters + +### Minimum amount to participate in sharedrop. +If an asset holder has too little amount of the stake token it becomes expensive for the blockchain to do sharedrop for such a user. +So a sharedrop operation should have **minimum_amount_for_drop** property. + +### Sharedrop price + +sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in stakeholder number * sharedrop_price_multiplier. sharedrop_price_multiplier is defined by the committee. + +## Sharedrop vesting stake + +Sharedrop vesting stake will be a flat fee determined by the committee. It will be charged in BTS. + +It will be in BTS only and it will be held on a vesting balacne under a specific sharedrop vesting policy for the period of sharedrop_vesting_period (in weeks) defined by the committee. At the end of the sharedrop_vesting_period, a sharedrop originator will be able to retrieve his funds from the vesting account. + +Let's say a vesting period is 2 months. +If a sharedrop originator does another sharedrop before the vesting period is over, the sharedrop_vesting_period counter resets and these 2 months will start from fresh. + +### Complicated vesting cases + +One complicated case is that when the committee increases vesting stake. In this case calculate operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. + +When the committee decreases the vesting stake, the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. + +When the committee decreases or increases the sharedrop_vesting_period - the new vesting period is updated during the sharedrop operation. + + + +## Technical specifications + +struct sharedrop_result { + // cost of sharedrop + share_type fee; + // required amount on the vesting balance + share_type vesting_stake; + // money may be claimed after this time + fc::time_point_sec vesting_period; +} + + + +There is a function that helps to fill parameters for sharedrop operation + +// function that helps to fill parameters for sharedrop operation +// returns sharedrop_result +sharedrop_result dry_run_sharedrop(asset sharedrop_asset, asset_id_type stake_asset, share_type min_stake_asset_amount) + + +// share_type max_fee - a max value that caller agree to pay +void sharedrop(asset sharedrop_asset, asset_id_type stake_asset, share_type min_stake_asset_amount, share_type max_fee) +For sharedrop vesting balance add specific type for vesting_balance_object + +struct sharedrop_vesting_policy +{ + // money may be claimed after this time + fc::time_point_sec start_claim; +} +After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period + + + +# Discussion +1. Flag allow_sharedrop for an asset. Should we have it? +Each asset should have **allow_sharedrop** flag (TRUE/FALSE) that would either allow sharedrop to the holders of this asset or not allow it. + +2. One of the ideas is instead of making flat fee vesting for all sharedrop transactions, for each sharedrop transaction we put into vesting a separate amount based on the stakeholder number. +In this case, it might quickly become too expensive for some users. + +# Summary for Shareholders + +# Copyright +This document is placed in the public domain. + +# See Also +https://github.com/bitshares/bsips/blob/master/bsip-0020.md + + + +# CORE TEAM TASK LIST +- [ ] Evaluate / Prioritize Feature Request +- [ ] Refine User Stories / Requirements +- [ ] Define Test Cases +- [ ] Design / Develop Solution +- [ ] Perform QA/Testing +- [ ] Update Documentation \ No newline at end of file From 38eecaac07d2f041ee164ecf62d4110977cab9ae Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:38:53 +0300 Subject: [PATCH 04/32] test 2 --- bsip-00Sharedrop.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index 70d837d..2ebaf06 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -94,6 +94,7 @@ When the committee decreases or increases the sharedrop_vesting_period - the new ## Technical specifications +''' struct sharedrop_result { // cost of sharedrop share_type fee; @@ -102,7 +103,7 @@ struct sharedrop_result { // money may be claimed after this time fc::time_point_sec vesting_period; } - +''' There is a function that helps to fill parameters for sharedrop operation From 7af44c050e3977f0fec29f3c2d26d8a67aaa9a8c Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:46:17 +0300 Subject: [PATCH 05/32] test3 --- bsip-00Sharedrop.md | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index 2ebaf06..c564ee7 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -1,10 +1,10 @@ BSIP: 00XX Title: Sharedrop operation Authors: OpenLedgerApp - Status: Draft + Status: Draft 1 Type: Protocol - Created: 2018-12-10 - Updated: 2018-12-10 + Created: 2018-12-14 + Updated: 2018-12-14 Discussion: Worker: @@ -93,8 +93,7 @@ When the committee decreases or increases the sharedrop_vesting_period - the new ## Technical specifications - -''' +``` struct sharedrop_result { // cost of sharedrop share_type fee; @@ -103,26 +102,30 @@ struct sharedrop_result { // money may be claimed after this time fc::time_point_sec vesting_period; } -''' +``` There is a function that helps to fill parameters for sharedrop operation + + +``` // function that helps to fill parameters for sharedrop operation // returns sharedrop_result sharedrop_result dry_run_sharedrop(asset sharedrop_asset, asset_id_type stake_asset, share_type min_stake_asset_amount) +``` - -// share_type max_fee - a max value that caller agree to pay -void sharedrop(asset sharedrop_asset, asset_id_type stake_asset, share_type min_stake_asset_amount, share_type max_fee) For sharedrop vesting balance add specific type for vesting_balance_object +``` + struct sharedrop_vesting_policy { // money may be claimed after this time fc::time_point_sec start_claim; -} -After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period +}``` +After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period + @@ -149,4 +152,7 @@ https://github.com/bitshares/bsips/blob/master/bsip-0020.md - [ ] Define Test Cases - [ ] Design / Develop Solution - [ ] Perform QA/Testing -- [ ] Update Documentation \ No newline at end of file +- [ ] Update Documentation + + + From 0b09a84ee50cabf5238f229653f09ab248879e7c Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 18:47:19 +0300 Subject: [PATCH 06/32] test 5 --- bsip-00Sharedrop.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index c564ee7..990b0c7 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -123,7 +123,9 @@ struct sharedrop_vesting_policy { // money may be claimed after this time fc::time_point_sec start_claim; -}``` +} +``` + After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period From 2954b7c0e111af036f6aa02fc6534ef57e170293 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 19:19:07 +0300 Subject: [PATCH 07/32] test 5 --- bsip-00Sharedrop.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index 990b0c7..705eed2 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -18,6 +18,7 @@ The importance of a similar solution was raised in BSIPs-19, 20, however never TBD - девелоперам не нужно # Rationale TBD - девелоперам не нужно + To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. Sharedrop operation should be quite expensive as well. @@ -36,26 +37,26 @@ Sharedrop operation will drop the Sharedrop asset in proportion to the stake tha This is a locally done operation with the following parameters: -Sharedrop asset -Sharedrop amount -Stake asset -Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) +- Sharedrop asset +- Sharedrop amount +- Stake asset +- Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) Calculate operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. This will be approximate calculation as the final calculation will be determined only during the sharedrop operation. The following parameters are calculated by a node and presented to the user: -Sharedrop operation price -Sharedrop vesting stake -sharedrop vesting period +- Sharedrop operation price +- Sharedrop vesting stake +- Sharedrop vesting period ## Sharedrop operation Sharedrop operation should be available with the following parameters: -Sharedrop asset -Sharedrop amount -Stake asset +- Sharedrop asset +- Sharedrop amount +- Stake asset Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. From ed77dfc510d647be0362d69c7ec24cf39a84edf8 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 19:30:30 +0300 Subject: [PATCH 08/32] test6 --- bsip-00Sharedrop.md | 37 +++++++++++++------------------------ 1 file changed, 13 insertions(+), 24 deletions(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index 705eed2..2c2ad2e 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -27,21 +27,20 @@ However, to make such an expensive operation more lucrative for BtiShares - the # Specifications ## General workflow -First of all, there is a need to calculate transaction fee, so Calculate operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. +First of all, there is a need to calculate transaction fee, so dry_run_sharedrop operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. Then, knowing that user has enough BTS for transaction fees and vesting money, he should call Sharedrop operation itself. Vesting specifics will be covered below. Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. -## Calculate operation - +## dry_run_sharedrop operation This is a locally done operation with the following parameters: - Sharedrop asset - Sharedrop amount - Stake asset - Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) -Calculate operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. +**dry_run_sharedrop** operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. This will be approximate calculation as the final calculation will be determined only during the sharedrop operation. @@ -50,14 +49,14 @@ The following parameters are calculated by a node and presented to the user: - Sharedrop operation price - Sharedrop vesting stake - Sharedrop vesting period -## Sharedrop operation +## Sharedrop operation Sharedrop operation should be available with the following parameters: - Sharedrop asset - Sharedrop amount - Stake asset -Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) +Minimum stake asset amount to participate in airdrop (**minimum_amount_for_drop**) Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. Each stakeholder will then need to retrieve the sharedrop token from the vesting balance in a separate operation. @@ -71,11 +70,9 @@ If an asset holder has too little amount of the stake token it becomes expensive So a sharedrop operation should have **minimum_amount_for_drop** property. ### Sharedrop price - -sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in stakeholder number * sharedrop_price_multiplier. sharedrop_price_multiplier is defined by the committee. +sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `stakeholder_number * sharedrop_price_multiplier. sharedrop_price_multiplier is defined by the committee. ## Sharedrop vesting stake - Sharedrop vesting stake will be a flat fee determined by the committee. It will be charged in BTS. It will be in BTS only and it will be held on a vesting balacne under a specific sharedrop vesting policy for the period of sharedrop_vesting_period (in weeks) defined by the committee. At the end of the sharedrop_vesting_period, a sharedrop originator will be able to retrieve his funds from the vesting account. @@ -84,8 +81,7 @@ Let's say a vesting period is 2 months. If a sharedrop originator does another sharedrop before the vesting period is over, the sharedrop_vesting_period counter resets and these 2 months will start from fresh. ### Complicated vesting cases - -One complicated case is that when the committee increases vesting stake. In this case calculate operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. +One complicated case is that when the committee increases vesting stake. In this case dry_run_sharedrop operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. When the committee decreases the vesting stake, the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. @@ -108,18 +104,16 @@ struct sharedrop_result { There is a function that helps to fill parameters for sharedrop operation - - ``` // function that helps to fill parameters for sharedrop operation // returns sharedrop_result -sharedrop_result dry_run_sharedrop(asset sharedrop_asset, asset_id_type stake_asset, share_type min_stake_asset_amount) +sharedrop_result dry_run_sharedrop(asset sharedrop_asset, asset_id_type stake_asset, +share_type min_stake_asset_amount) ``` For sharedrop vesting balance add specific type for vesting_balance_object ``` - struct sharedrop_vesting_policy { // money may be claimed after this time @@ -128,26 +122,21 @@ struct sharedrop_vesting_policy ``` After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period - - # Discussion -1. Flag allow_sharedrop for an asset. Should we have it? +1. Flag **allow_sharedrop** for an asset. Should we have it? Each asset should have **allow_sharedrop** flag (TRUE/FALSE) that would either allow sharedrop to the holders of this asset or not allow it. -2. One of the ideas is instead of making flat fee vesting for all sharedrop transactions, for each sharedrop transaction we put into vesting a separate amount based on the stakeholder number. +2. One of the ideas is instead of making flat fee vesting for all sharedrop transactions, for each sharedrop transaction we put into vesting an amount based on the stakeholder number. And we have to put a new amount for every sharedrop transaction. In this case, it might quickly become too expensive for some users. -# Summary for Shareholders - -# Copyright -This document is placed in the public domain. # See Also https://github.com/bitshares/bsips/blob/master/bsip-0020.md - +## Copyright +This document is placed in the public domain. # CORE TEAM TASK LIST - [ ] Evaluate / Prioritize Feature Request From aa8daf3e176b2b297787c2401e8ccb5f1d327083 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Fri, 14 Dec 2018 19:33:44 +0300 Subject: [PATCH 09/32] test7 --- bsip-00Sharedrop.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/bsip-00Sharedrop.md b/bsip-00Sharedrop.md index 2c2ad2e..1af08b0 100644 --- a/bsip-00Sharedrop.md +++ b/bsip-00Sharedrop.md @@ -27,7 +27,7 @@ However, to make such an expensive operation more lucrative for BtiShares - the # Specifications ## General workflow -First of all, there is a need to calculate transaction fee, so dry_run_sharedrop operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. +First of all, there is a need to calculate transaction fee, so **dry_run_sharedrop** operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. Then, knowing that user has enough BTS for transaction fees and vesting money, he should call Sharedrop operation itself. Vesting specifics will be covered below. @@ -39,8 +39,8 @@ This is a locally done operation with the following parameters: - Sharedrop asset - Sharedrop amount - Stake asset -- Minimum stake asset amount to participate in airdrop (minimum_amount_for_drop) -**dry_run_sharedrop** operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. +- Minimum stake asset amount to participate in airdrop (**minimum_amount_for_drop**) +dry_run_sharedrop operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. This will be approximate calculation as the final calculation will be determined only during the sharedrop operation. @@ -70,24 +70,22 @@ If an asset holder has too little amount of the stake token it becomes expensive So a sharedrop operation should have **minimum_amount_for_drop** property. ### Sharedrop price -sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `stakeholder_number * sharedrop_price_multiplier. sharedrop_price_multiplier is defined by the committee. +sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `` stakeholder_number * sharedrop_price_multiplier. **sharedrop_price_multiplier** is defined by the committee. ## Sharedrop vesting stake Sharedrop vesting stake will be a flat fee determined by the committee. It will be charged in BTS. -It will be in BTS only and it will be held on a vesting balacne under a specific sharedrop vesting policy for the period of sharedrop_vesting_period (in weeks) defined by the committee. At the end of the sharedrop_vesting_period, a sharedrop originator will be able to retrieve his funds from the vesting account. +It will be in BTS only and it will be held on a vesting balacne under a specific sharedrop vesting policy for the period of **sharedrop_vesting_period (in weeks)** defined by the committee. At the end of the sharedrop_vesting_period, a sharedrop originator will be able to retrieve his funds from the vesting account. Let's say a vesting period is 2 months. -If a sharedrop originator does another sharedrop before the vesting period is over, the sharedrop_vesting_period counter resets and these 2 months will start from fresh. +If a sharedrop originator does another sharedrop before the vesting period is over, the **sharedrop_vesting_period** counter resets and these 2 months will start from fresh. ### Complicated vesting cases -One complicated case is that when the committee increases vesting stake. In this case dry_run_sharedrop operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. +One complicated case is that when the committee increases vesting stake. In this case **dry_run_sharedrop** operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. When the committee decreases the vesting stake, the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. -When the committee decreases or increases the sharedrop_vesting_period - the new vesting period is updated during the sharedrop operation. - - +When the committee decreases or increases the **sharedrop_vesting_period** - the new vesting period is updated during the sharedrop operation. ## Technical specifications ``` @@ -133,6 +131,7 @@ In this case, it might quickly become too expensive for some users. # See Also + https://github.com/bitshares/bsips/blob/master/bsip-0020.md ## Copyright From a30b126f3719addcea7c27ce6ced4288dac401e6 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 13:14:02 +0300 Subject: [PATCH 10/32] test 78 --- bsip-00Dynamic.md => bsip-00XX Dynamic market fees.md | 5 +---- bsip-00Sharedrop.md => bsip-00XX Sharedrop Operation.md | 0 2 files changed, 1 insertion(+), 4 deletions(-) rename bsip-00Dynamic.md => bsip-00XX Dynamic market fees.md (99%) rename bsip-00Sharedrop.md => bsip-00XX Sharedrop Operation.md (100%) diff --git a/bsip-00Dynamic.md b/bsip-00XX Dynamic market fees.md similarity index 99% rename from bsip-00Dynamic.md rename to bsip-00XX Dynamic market fees.md index f25e118..5919183 100644 --- a/bsip-00Dynamic.md +++ b/bsip-00XX Dynamic market fees.md @@ -17,7 +17,6 @@ So, instead of market fee, an asset owner can optionally set up dynamic_market_f ## Motivation - - To provide additional marketing tools to encourage traders. - To increase trading volume on BitShares. - To attract traders to the ecosystem. @@ -25,8 +24,7 @@ So, instead of market fee, an asset owner can optionally set up dynamic_market_f # Rationale ## Use cases: - -**1) Supporting money makers.** +**1) Supporting market makers.** Every trade occurs between two parties: the maker, whose order exists on the order book prior to the trade, and the taker, who places the order that matches (or "takes") the maker's order. Makers are so named because their orders make the liquidity in a market. Takers are the ones who remove this liquidity by matching makers' orders with their own. @@ -37,7 +35,6 @@ The maker-taker model encourages market liquidity by rewarding the makers of tha Fees are charged and deduced on a per-trade basis. The bigger “trading volume” users have traded, the lower fee they get on subsequent trades. # General notes - Each asset will have either usual market fee or a table with dynamic market fees that will represent the table above. A switch market_fee_type (REGULAR, DYNAMIC) should clearly indicate, which market fee type is used. diff --git a/bsip-00Sharedrop.md b/bsip-00XX Sharedrop Operation.md similarity index 100% rename from bsip-00Sharedrop.md rename to bsip-00XX Sharedrop Operation.md From 3e02f8217cec188f5dafd33a4d493c22895540ad Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 13:33:16 +0300 Subject: [PATCH 11/32] test8 --- bsip-00XX Dynamic market fees.md | 6 +++--- bsip-00XX Sharedrop Operation.md | 12 ++++++------ 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 5919183..d84420c 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -8,7 +8,7 @@ Discussion: https://github.com/bitshares/bsips/issues/130 Worker: (optional) # Abstract -UIA owners does not have many marketing tools to increase trade volume of their assets. +UIA owners do not have many marketing tools to increase trade volume of their assets. One of the ways to increase the trade volume can be Dynamic Market Fees that will provide additional discounts for active traders. For example, to set lower fees for trading larger volumes. @@ -37,7 +37,7 @@ Fees are charged and deduced on a per-trade basis. The bigger “trading volume # General notes Each asset will have either usual market fee or a table with dynamic market fees that will represent the table above. -A switch market_fee_type (REGULAR, DYNAMIC) should clearly indicate, which market fee type is used. +A switch **market_fee_type (REGULAR, DYNAMIC)** should clearly indicate, which market fee type is used. **Makers** are the ones who put up their orders first. @@ -67,7 +67,7 @@ Average trading volume over the last 365 days (a year). We suggest using average total volume for a particular asset. However, it's open for the discussion. -## Statistics Storage** +## Statistics Storage There are two options for storing account statistics for trading: diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md index 1af08b0..955a826 100644 --- a/bsip-00XX Sharedrop Operation.md +++ b/bsip-00XX Sharedrop Operation.md @@ -1,7 +1,7 @@ BSIP: 00XX Title: Sharedrop operation Authors: OpenLedgerApp - Status: Draft 1 + Status: Draft Type: Protocol Created: 2018-12-14 Updated: 2018-12-14 @@ -70,7 +70,7 @@ If an asset holder has too little amount of the stake token it becomes expensive So a sharedrop operation should have **minimum_amount_for_drop** property. ### Sharedrop price -sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `` stakeholder_number * sharedrop_price_multiplier. **sharedrop_price_multiplier** is defined by the committee. +sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `stakeholder_number * sharedrop_price_multiplier`, where **sharedrop_price_multiplier** is defined by the committee. ## Sharedrop vesting stake Sharedrop vesting stake will be a flat fee determined by the committee. It will be charged in BTS. @@ -80,12 +80,12 @@ It will be in BTS only and it will be held on a vesting balacne under a specific Let's say a vesting period is 2 months. If a sharedrop originator does another sharedrop before the vesting period is over, the **sharedrop_vesting_period** counter resets and these 2 months will start from fresh. -### Complicated vesting cases -One complicated case is that when the committee increases vesting stake. In this case **dry_run_sharedrop** operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. +### Complicated vesting cases, when the committee updates sharedrop vesting parameters. +- Vesting stake increases. In this case **dry_run_sharedrop** operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. -When the committee decreases the vesting stake, the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. +- Vesting stake decreases. Then the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. -When the committee decreases or increases the **sharedrop_vesting_period** - the new vesting period is updated during the sharedrop operation. +- **Sharedrop_vesting_period** decreases or increases. The new vesting period is updated during the next sharedrop operation. ## Technical specifications ``` From d25bb106df701b131f0e752e5372c94f48f6b26b Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:15:43 +0300 Subject: [PATCH 12/32] test9 --- bsip-00XX Dynamic market fees.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index d84420c..5246c6b 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -87,11 +87,11 @@ We need to update statistics for the user and for the specific asset at the same **Trader Activity** is estimated as average trading volume of a user for a given asset for 1 day. -`Trader_activity = total_volume / (Now - first_start_date) //(in days). -` +`Trader_activity = total_volume / (Now - first_start_date) //(in days).` + This way we accumulate total bought volume for each user for each asset and average out daily volumes for his entire term of trading of this asset (per day). -Volume discounts are estimated based on the average daily Trader_Activity * 30 days. +Volume discounts are estimated based on the average daily `Trader_Activity * 30 days.` _Trade statistics object_ @@ -109,11 +109,11 @@ share_type total_volume; //total bought asset volume ### 30-day sliding window average -In `trade_statistics_object` we need to store the queue of volumes aggregated by 1 day. In other words, for each asset a user should have a queue of 30 daily volumes. +In **trade_statistics_object** we need to store the queue of volumes aggregated by 1 day. In other words, for each asset a user should have a queue of 30 daily volumes. During the first maintenance interval of the day, yesterday's volume will be added to the queue and the oldest volume will be deleted (for each asset even for assets where there was no trade done). -This way it will cost significant memory usage!!! +This way it will cost significant memory usage!! Technically we can store only the aggregated sum for 30 days and take the first day volumes from the blockchain. This will take less memory but will take more CPU time. @@ -124,10 +124,13 @@ Alternative way would be to store one 30-day volume for each asset for each user So the memory requirements will be at least 30 times less than in a previous method. -The algorithm is like this: -For example, the 30-day volume is 90. Hence daily average is 3. Let's say today's volume is 13. +The algorithm is like this: + +```For example, the 30-day volume is 90. Hence daily average is 3. +Let's say today's volume is 13. First of all, we subtract average daily volume from the 30-day volume. 90-3 =87. -Then we add today's volume. So the new 30-day volume would be 87+13 = 100. A new daily average would be 100/30 = 3.33333 +Then we add today's volume. So the new 30-day volume would be 87+13 = 100. +A new daily average would be 100/30 = 3.33333``` ### 365-day sliding window average From 88eda95f42723da75c4499cfb1471f6c3635e339 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:16:39 +0300 Subject: [PATCH 13/32] test9 --- bsip-00XX Dynamic market fees.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 5246c6b..f669ed0 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -130,7 +130,8 @@ The algorithm is like this: Let's say today's volume is 13. First of all, we subtract average daily volume from the 30-day volume. 90-3 =87. Then we add today's volume. So the new 30-day volume would be 87+13 = 100. -A new daily average would be 100/30 = 3.33333``` +A new daily average would be 100/30 = 3.33333 +``` ### 365-day sliding window average From 3b3a39b81406cc0fbaf03a1a4e52edbcc70f5c28 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:18:34 +0300 Subject: [PATCH 14/32] TEST10 --- bsip-00XX Dynamic market fees.md | 5 +++-- bsip-00XX Sharedrop Operation.md | 8 ++++++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index f669ed0..ec8af8a 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -126,12 +126,13 @@ So the memory requirements will be at least 30 times less than in a previous met The algorithm is like this: -```For example, the 30-day volume is 90. Hence daily average is 3. +``` +For example, the 30-day volume is 90. Hence daily average is 3. Let's say today's volume is 13. First of all, we subtract average daily volume from the 30-day volume. 90-3 =87. Then we add today's volume. So the new 30-day volume would be 87+13 = 100. A new daily average would be 100/30 = 3.33333 -``` +``` ### 365-day sliding window average diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md index 955a826..ec3e637 100644 --- a/bsip-00XX Sharedrop Operation.md +++ b/bsip-00XX Sharedrop Operation.md @@ -19,10 +19,14 @@ TBD - девелоперам не нужно # Rationale TBD - девелоперам не нужно + +- Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. +- Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within the BTS DEX (unless I'm mistaken?). + To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. -Sharedrop operation should be quite expensive as well. -However, to make such an expensive operation more lucrative for BtiShares - the sharedrop operation will send the money to each stakeholder's vesting balance. Thus making them withdraw the drop from the vesting balances. +Sharedrop operation should also be quite expensive as well. +However, to make such an operation more lucrative for BtiShares - the sharedrop operation will send the money to each stakeholder's vesting balance. Thus making them withdraw the drop from the vesting balances. # Specifications From 340db9015a203a0fac3a78fdd4fd81c289e08b55 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:31:02 +0300 Subject: [PATCH 15/32] 10 --- bsip-00XX Dynamic market fees.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index ec8af8a..c8fe094 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -14,6 +14,12 @@ One of the ways to increase the trade volume can be Dynamic Market Fees that wil For example, to set lower fees for trading larger volumes. So, instead of market fee, an asset owner can optionally set up dynamic_market_fee_percent property that may look like a following example table. +**Please refer to the general notes below for terms explanation.** + +|Trade daily volume|Maker|Taker| +|< 500 USD|0.19%|0.20%| +|>=500 USD|0.18%|0.20%| + ## Motivation @@ -43,25 +49,29 @@ A switch **market_fee_type (REGULAR, DYNAMIC)** should clearly indicate, which m And **takers** are the ones to put up their orders later in time than makers. +The following table # Discussion We have had a discussion what's the best way to average out Trading Volume. There are a few ways of doing this: -Use an average volume since day the beginning of trading. +- Use an **average volume since day the beginning of trading**. Up for discussion is - what to take as a day 1. 1st trade of this asset? 1st trade minus 30 days? Account open date? This way we have a normal fair average volume if we figure out the fair beginning interval date. However, if a trader started trading this asset a few years ago he might be in a significant disadvantage. -Average trading volume over the last 30 days - sliding window. +- **Average trading volume over the last 30 days - sliding window**. This way it is a bit clearer how to calculate. However there might be extreme but real cases where this kind of calculation might not be fair: a. when a person who usually trades high volumes throughout the year goes to vacation for 30 days. Suddenly all his discount is gone when he comes back b. When another person comes in and makes 1 or 2 high volume trades while trading really low volumes before that. Suddenly this person might have a big discount. 30-day volume This mehod gives enough information to figure out last 30-days traders habits with much lower memory requirements but slightly less precision than the 30-day average sliding window. -Average trading volume over the last 365 days (a year). +Average trading volume over the last 365 days (a year) is a variation of this method. + +- **30-day volume method** +This is quite similar to the 30-day average method and shares it's advantages and drawbacks. # Technical Specifications From cedf2cf0027e2ffc18b5aee0a9eb14c687c8b16f Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:33:26 +0300 Subject: [PATCH 16/32] 11 --- bsip-00XX Dynamic market fees.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index c8fe094..aad4688 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -16,9 +16,9 @@ For example, to set lower fees for trading larger volumes. So, instead of market fee, an asset owner can optionally set up dynamic_market_fee_percent property that may look like a following example table. **Please refer to the general notes below for terms explanation.** -|Trade daily volume|Maker|Taker| -|< 500 USD|0.19%|0.20%| -|>=500 USD|0.18%|0.20%| +Trade daily volume|Maker|Takerq +< 500 USD|0.19%|0.20% +>=500 USD|0.18%|0.20% From 9419c6cd42ead29d0a8f9963c0095bcf73ef393c Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:36:38 +0300 Subject: [PATCH 17/32] 11 --- bsip-00XX Dynamic market fees.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index aad4688..a985494 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -16,11 +16,14 @@ For example, to set lower fees for trading larger volumes. So, instead of market fee, an asset owner can optionally set up dynamic_market_fee_percent property that may look like a following example table. **Please refer to the general notes below for terms explanation.** -Trade daily volume|Maker|Takerq -< 500 USD|0.19%|0.20% ->=500 USD|0.18%|0.20% - - +Trade daily volume | Maker fee, % | Taker fee, % +< 500 USD | 0.19% | 0.20% +>=500 USD | 0.18% | 0.20% + +Number | Title | Owner | Type | Status +-------------------|----------------------------------------------------------|-------------------|----------------|-------- +[1](bsip-0001.md) | BSIP Purpose and Guidelines | Fabian Schuh | Informational | Draft +[2](bsip-0002.md) | Refund Create Order Fees on Cancel | Daniel Larimer | Protocol | Installed ## Motivation - To provide additional marketing tools to encourage traders. From 1db21e0b9bda021748b3f6d4e5dd8b2b20dce8fc Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:37:39 +0300 Subject: [PATCH 18/32] 11 --- bsip-00XX Dynamic market fees.md | 1 + 1 file changed, 1 insertion(+) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index a985494..4ba754e 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -17,6 +17,7 @@ So, instead of market fee, an asset owner can optionally set up dynamic_market_f **Please refer to the general notes below for terms explanation.** Trade daily volume | Maker fee, % | Taker fee, % +---|---|--- < 500 USD | 0.19% | 0.20% >=500 USD | 0.18% | 0.20% From 9a3276c0767e2eb5454e9ba0cac47c9b81b7d354 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:39:26 +0300 Subject: [PATCH 19/32] 12 --- bsip-00XX Dynamic market fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 4ba754e..6a02da0 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -19,7 +19,7 @@ So, instead of market fee, an asset owner can optionally set up dynamic_market_f Trade daily volume | Maker fee, % | Taker fee, % ---|---|--- < 500 USD | 0.19% | 0.20% ->=500 USD | 0.18% | 0.20% +\>=500 USD | 0.18% | 0.20% Number | Title | Owner | Type | Status -------------------|----------------------------------------------------------|-------------------|----------------|-------- From e5592e84335c5b6a166632c26ec9a60cadd5f347 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:45:04 +0300 Subject: [PATCH 20/32] 13 --- bsip-00XX Dynamic market fees.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 6a02da0..eb51320 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -20,11 +20,16 @@ Trade daily volume | Maker fee, % | Taker fee, % ---|---|--- < 500 USD | 0.19% | 0.20% \>=500 USD | 0.18% | 0.20% +\>=1K USD | 0.17% | 0.20% +\>=2.5 K USD | 0.16% | 0.19% +\>=5K USD | 0.15% | 0.18% +\>=7.5K USD | 0.14% | 0.17% +\>=10K USD | 0.1% | 0.15% +\>=15K USD | 0.075% | 0.13% +\>=20K USD | 0.05% | 0.12% +\>=25K USD | 0.025% | 0.11% +\>=50K USD | 0.01% | 0.07% -Number | Title | Owner | Type | Status --------------------|----------------------------------------------------------|-------------------|----------------|-------- -[1](bsip-0001.md) | BSIP Purpose and Guidelines | Fabian Schuh | Informational | Draft -[2](bsip-0002.md) | Refund Create Order Fees on Cancel | Daniel Larimer | Protocol | Installed ## Motivation - To provide additional marketing tools to encourage traders. From 8d2bed6107498bb2129f8409d25f969910a844f8 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:48:56 +0300 Subject: [PATCH 21/32] 14 --- bsip-00XX Dynamic market fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index eb51320..7ec2293 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -6,7 +6,7 @@ Created: 2018-12-10 Updated: 2018-12-10 Discussion: https://github.com/bitshares/bsips/issues/130 - Worker: (optional) + Worker: TBD # Abstract UIA owners do not have many marketing tools to increase trade volume of their assets. From 64eadd84a9c115987171d36b85388ea95e2939ae Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:50:11 +0300 Subject: [PATCH 22/32] 15 --- bsip-00XX Dynamic market fees.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 7ec2293..607bd46 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -169,3 +169,6 @@ Some problems include performance as an additional search and update new index a This document is placed in the public domain. # See Also +https://github.com/bitshares/bsips/issues/130 + + From a88200f60cd6d14acdbd1a95d9422ee80823cab9 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:52:25 +0300 Subject: [PATCH 23/32] 15 --- bsip-00XX Dynamic market fees.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 607bd46..c6c3310 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -169,6 +169,8 @@ Some problems include performance as an additional search and update new index a This document is placed in the public domain. # See Also + https://github.com/bitshares/bsips/issues/130 +### End of Document From 2df002e83fafc8a39c1f66e583d707264d62148d Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:53:02 +0300 Subject: [PATCH 24/32] 16 --- bsip-00XX Dynamic market fees.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index c6c3310..8a5f1f9 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -172,5 +172,3 @@ This document is placed in the public domain. https://github.com/bitshares/bsips/issues/130 - -### End of Document From 15f7d50eb38e166869635b0c1746108f714ccc4c Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:53:34 +0300 Subject: [PATCH 25/32] 17 --- bsip-00XX Dynamic market fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 8a5f1f9..44305bb 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -5,7 +5,7 @@ Type: Protocol Created: 2018-12-10 Updated: 2018-12-10 - Discussion: https://github.com/bitshares/bsips/issues/130 + Discussion: [https://github.com/bitshares/bsips/issues/130] (https://github.com/bitshares/bsips/issues/130) Worker: TBD # Abstract UIA owners do not have many marketing tools to increase trade volume of their assets. From 2b2766f795a28383dcf422a2da1cb2606df7cfda Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 15:55:20 +0300 Subject: [PATCH 26/32] 18 --- bsip-00XX Dynamic market fees.md | 6 +++--- bsip-00XX Sharedrop Operation.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 44305bb..3567d4a 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -1,11 +1,11 @@ - BSIP: 00XX + BSIP: 00TBD Title: Dynamic Market Fees Authors: OpenLedgerApp Status: Draft Type: Protocol Created: 2018-12-10 Updated: 2018-12-10 - Discussion: [https://github.com/bitshares/bsips/issues/130] (https://github.com/bitshares/bsips/issues/130) + Discussion: Worker: TBD # Abstract UIA owners do not have many marketing tools to increase trade volume of their assets. @@ -170,5 +170,5 @@ This document is placed in the public domain. # See Also -https://github.com/bitshares/bsips/issues/130 +High-level proposal and discussion https://github.com/bitshares/bsips/issues/130 diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md index ec3e637..6b0efe2 100644 --- a/bsip-00XX Sharedrop Operation.md +++ b/bsip-00XX Sharedrop Operation.md @@ -1,4 +1,4 @@ - BSIP: 00XX + BSIP: 00TBD Title: Sharedrop operation Authors: OpenLedgerApp Status: Draft From b64a867ad30794ae56e35c25cc743a4750392714 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 17:08:57 +0300 Subject: [PATCH 27/32] draft --- bsip-00XX Dynamic market fees.md | 14 +++- bsip-00XX Market Fee Based Asset (MFBA).md | 94 ++++++++++++++++++++++ bsip-00XX Sharedrop Operation.md | 13 +-- 3 files changed, 113 insertions(+), 8 deletions(-) create mode 100644 bsip-00XX Market Fee Based Asset (MFBA).md diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 3567d4a..ce3cead 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -1,10 +1,10 @@ - BSIP: 00TBD + BSIP: TBD Title: Dynamic Market Fees Authors: OpenLedgerApp Status: Draft Type: Protocol - Created: 2018-12-10 - Updated: 2018-12-10 + Created: 2018-12-17 + Updated: 2018-12-17 Discussion: Worker: TBD # Abstract @@ -172,3 +172,11 @@ This document is placed in the public domain. High-level proposal and discussion https://github.com/bitshares/bsips/issues/130 +# CORE TEAM TASK LIST +- [ ] Evaluate / Prioritize Feature Request +- [ ] Refine User Stories / Requirements +- [ ] Define Test Cases +- [ ] Design / Develop Solution +- [ ] Perform QA/Testing +- [ ] Update Documentation + diff --git a/bsip-00XX Market Fee Based Asset (MFBA).md b/bsip-00XX Market Fee Based Asset (MFBA).md new file mode 100644 index 0000000..52bf97e --- /dev/null +++ b/bsip-00XX Market Fee Based Asset (MFBA).md @@ -0,0 +1,94 @@ + BSIP: TBD + Title: Market Fee Backed Asset (MFBA) + Authors: OpenLedgerApp + Status: Draft + Type: Protocol + Created: 2018-12-17 + Updated: 2018-12-17 + Discussion: + Worker: + + +# Abstract +Market Fee Backed Asset (MFBA) is a SmartCoin introduced by this BSIP. +The main idea of a MFBA is to provide opportunity for the Assets Owners to automatically share revenue received from trading operations (Market Fees) to the holders of the MFBA in proportion of the owned amount of the MFBA. + +The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). + + +# Motivation +By implementing this proposals, we let Asset Owners an opportunity to use their assets as profit-sharing assets. +Distribution of fees will be conducted automatically (in a pre-defined period of time). Such functionality is currently not available in the blockchain. + +# Use case + + + +There will be a new type of asset created - Market Fee Backed Asset (MFBA). + +Let's say a user (owner of XXX generic asset) wants to share the market fee from assets XXX.BTC, XXX.ETH, XXX.YYY with other people. +Then this user creates an MFBA and calls it XXX.MFBA. Then he ties his other assets: XXX.BTC, XXX.ETH, XXX.YYY to this newly created XXX.MFBA. +Then holders of the XXX.MFBA will get a share of profits from the market fees of all the assets tied to XXX.MFBA. + +# Specifications + +There will be a special structure for MFBA parameters storing **MFBA_options**. It will be a part of general asset_options + +## Market Fee Backed Asset Definition + +Asset for which **MFBA_options** structure is available will be called MFBA Asset. + +## Tied assets +Issuer of the MFBA Asset will be able to tie his/her other assets (one or many) to the MFBA Asset. Tied assets cannot become MFBA. + +The list of the tied assets will be stored in the **MFBA_options** + +## Dividends + +Market Fee, received from trading operations of the tied assets will be distributed between holders of the MFBA Asset according to the stake of the MFBA Asset that holders have. +Issuer of the MFBA Asset must be able to set share of the Market Fee, that will be distributed to the holders of the MFBA Asset as a parameter **(MFBA share, %)**. +Whatever is left after distribution to the MFBA holders, will be the share of the Asset Owner **(100% - MFBA share%)**. +Funds currently in the open orders will not be included in the MFBA share. + +**MFBA share, %** will be stored in **MFBA_options**. + +## Whitelist and Blacklist + +Whitelist and blacklist (configurable by the UIA Issuer) could provide control over who is eligible to earn dividends. + +These lists will be stored in the **MFBA_options**. + +## Dividends Distribution Process + +Distribution will be performed regularly. **fee_accumulation_period** is stored in the **MFBA_options** and must be set by the MFBA Issuer (minimal available interval must exist). +Market Fee of the tied assets is accumulated during this period. At the end of the period fee is distributed to the MFBA holders' **vesting balance** and to the MFBA Issuer **vesting balance**. +After that MFBA holders and MFBA Issuer can withdraw the fees. + +The time of the last MFBA fees distribution for this asset is stored in the **MFBA_options** as well. + +The distribution occurs in the nearest maintenance interval after the ``latest MFBA distribution time + fee_accumulation_period. + +## Dividends Distribution Process Restrictions +Distribution must be performed starting from the user, that has the biggest share of the MFBA Asset. +Users will not receive their share of Market Fee if the amount to be transferred is less than should be accrued, . +The undistributed market fee will be returned to the asset issuer. + +# Discussion + + + +# Copyright +This document is placed in the public domain. + +# See Also +https://github.com/bitshares/bsips/blob/master/bsip-0020.md + + + +# CORE TEAM TASK LIST +- [ ] Evaluate / Prioritize Feature Request +- [ ] Refine User Stories / Requirements +- [ ] Define Test Cases +- [ ] Design / Develop Solution +- [ ] Perform QA/Testing +- [ ] Update Documentation \ No newline at end of file diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md index 6b0efe2..aa5e09e 100644 --- a/bsip-00XX Sharedrop Operation.md +++ b/bsip-00XX Sharedrop Operation.md @@ -1,23 +1,26 @@ - BSIP: 00TBD + BSIP: TBD Title: Sharedrop operation Authors: OpenLedgerApp Status: Draft Type: Protocol - Created: 2018-12-14 - Updated: 2018-12-14 + Created: 2018-12-17 + Updated: 2018-12-17 Discussion: Worker: A sharedrop is a giveaway of some tokens to a certain group of people, for example to all BTS holders in proportion to their holdings. + # Abstract We should add the ability to distribute arbitrary amount of some token (SHAREDROP token) to holders of a specific other token (STAKE token) according to the share(stake) of such tokens. The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). # Motivation -TBD - девелоперам не нужно +By implementing this proposal, we let Asset Owners or other businesses an opportunity to distribute their profit to the holders of a specific asset in proportion of the owned amount of this asset. + +Also, usual token drops can be done via the sharedrop operation. + # Rationale -TBD - девелоперам не нужно - Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. From e907ae6698dfa1f73e49ab68d59917e39caea525 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 17:30:28 +0300 Subject: [PATCH 28/32] draft --- bsip-00XX Dynamic market fees.md | 3 ++- bsip-00XX Market Fee Based Asset (MFBA).md | 3 +-- bsip-00XX Sharedrop Operation.md | 7 ++----- 3 files changed, 5 insertions(+), 8 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index ce3cead..97eda5e 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -7,6 +7,7 @@ Updated: 2018-12-17 Discussion: Worker: TBD + # Abstract UIA owners do not have many marketing tools to increase trade volume of their assets. @@ -14,7 +15,7 @@ One of the ways to increase the trade volume can be Dynamic Market Fees that wil For example, to set lower fees for trading larger volumes. So, instead of market fee, an asset owner can optionally set up dynamic_market_fee_percent property that may look like a following example table. -**Please refer to the general notes below for terms explanation.** +**Please refer to the general notes below for terms (maker, taker) explanation.** Trade daily volume | Maker fee, % | Taker fee, % ---|---|--- diff --git a/bsip-00XX Market Fee Based Asset (MFBA).md b/bsip-00XX Market Fee Based Asset (MFBA).md index 52bf97e..8d6d843 100644 --- a/bsip-00XX Market Fee Based Asset (MFBA).md +++ b/bsip-00XX Market Fee Based Asset (MFBA).md @@ -6,9 +6,8 @@ Created: 2018-12-17 Updated: 2018-12-17 Discussion: - Worker: + Worker: TBD - # Abstract Market Fee Backed Asset (MFBA) is a SmartCoin introduced by this BSIP. The main idea of a MFBA is to provide opportunity for the Assets Owners to automatically share revenue received from trading operations (Market Fees) to the holders of the MFBA in proportion of the owned amount of the MFBA. diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md index aa5e09e..5240094 100644 --- a/bsip-00XX Sharedrop Operation.md +++ b/bsip-00XX Sharedrop Operation.md @@ -6,7 +6,7 @@ Created: 2018-12-17 Updated: 2018-12-17 Discussion: - Worker: + Worker: TBD A sharedrop is a giveaway of some tokens to a certain group of people, for example to all BTS holders in proportion to their holdings. @@ -22,9 +22,8 @@ Also, usual token drops can be done via the sharedrop operation. # Rationale - - Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. -- Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within the BTS DEX (unless I'm mistaken?). +- Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within BitShares. To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. @@ -152,5 +151,3 @@ This document is placed in the public domain. - [ ] Perform QA/Testing - [ ] Update Documentation - - From abd61f0bbaa248480a64dad342b7702dc0090f31 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 18:26:40 +0300 Subject: [PATCH 29/32] bsip draft 1 --- bsip-00XX Market Fee Based Asset (MFBA).md | 93 ------------- bsip-00XX Sharedrop Operation.md | 153 --------------------- 2 files changed, 246 deletions(-) delete mode 100644 bsip-00XX Market Fee Based Asset (MFBA).md delete mode 100644 bsip-00XX Sharedrop Operation.md diff --git a/bsip-00XX Market Fee Based Asset (MFBA).md b/bsip-00XX Market Fee Based Asset (MFBA).md deleted file mode 100644 index 8d6d843..0000000 --- a/bsip-00XX Market Fee Based Asset (MFBA).md +++ /dev/null @@ -1,93 +0,0 @@ - BSIP: TBD - Title: Market Fee Backed Asset (MFBA) - Authors: OpenLedgerApp - Status: Draft - Type: Protocol - Created: 2018-12-17 - Updated: 2018-12-17 - Discussion: - Worker: TBD - -# Abstract -Market Fee Backed Asset (MFBA) is a SmartCoin introduced by this BSIP. -The main idea of a MFBA is to provide opportunity for the Assets Owners to automatically share revenue received from trading operations (Market Fees) to the holders of the MFBA in proportion of the owned amount of the MFBA. - -The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). - - -# Motivation -By implementing this proposals, we let Asset Owners an opportunity to use their assets as profit-sharing assets. -Distribution of fees will be conducted automatically (in a pre-defined period of time). Such functionality is currently not available in the blockchain. - -# Use case - - - -There will be a new type of asset created - Market Fee Backed Asset (MFBA). - -Let's say a user (owner of XXX generic asset) wants to share the market fee from assets XXX.BTC, XXX.ETH, XXX.YYY with other people. -Then this user creates an MFBA and calls it XXX.MFBA. Then he ties his other assets: XXX.BTC, XXX.ETH, XXX.YYY to this newly created XXX.MFBA. -Then holders of the XXX.MFBA will get a share of profits from the market fees of all the assets tied to XXX.MFBA. - -# Specifications - -There will be a special structure for MFBA parameters storing **MFBA_options**. It will be a part of general asset_options - -## Market Fee Backed Asset Definition - -Asset for which **MFBA_options** structure is available will be called MFBA Asset. - -## Tied assets -Issuer of the MFBA Asset will be able to tie his/her other assets (one or many) to the MFBA Asset. Tied assets cannot become MFBA. - -The list of the tied assets will be stored in the **MFBA_options** - -## Dividends - -Market Fee, received from trading operations of the tied assets will be distributed between holders of the MFBA Asset according to the stake of the MFBA Asset that holders have. -Issuer of the MFBA Asset must be able to set share of the Market Fee, that will be distributed to the holders of the MFBA Asset as a parameter **(MFBA share, %)**. -Whatever is left after distribution to the MFBA holders, will be the share of the Asset Owner **(100% - MFBA share%)**. -Funds currently in the open orders will not be included in the MFBA share. - -**MFBA share, %** will be stored in **MFBA_options**. - -## Whitelist and Blacklist - -Whitelist and blacklist (configurable by the UIA Issuer) could provide control over who is eligible to earn dividends. - -These lists will be stored in the **MFBA_options**. - -## Dividends Distribution Process - -Distribution will be performed regularly. **fee_accumulation_period** is stored in the **MFBA_options** and must be set by the MFBA Issuer (minimal available interval must exist). -Market Fee of the tied assets is accumulated during this period. At the end of the period fee is distributed to the MFBA holders' **vesting balance** and to the MFBA Issuer **vesting balance**. -After that MFBA holders and MFBA Issuer can withdraw the fees. - -The time of the last MFBA fees distribution for this asset is stored in the **MFBA_options** as well. - -The distribution occurs in the nearest maintenance interval after the ``latest MFBA distribution time + fee_accumulation_period. - -## Dividends Distribution Process Restrictions -Distribution must be performed starting from the user, that has the biggest share of the MFBA Asset. -Users will not receive their share of Market Fee if the amount to be transferred is less than should be accrued, . -The undistributed market fee will be returned to the asset issuer. - -# Discussion - - - -# Copyright -This document is placed in the public domain. - -# See Also -https://github.com/bitshares/bsips/blob/master/bsip-0020.md - - - -# CORE TEAM TASK LIST -- [ ] Evaluate / Prioritize Feature Request -- [ ] Refine User Stories / Requirements -- [ ] Define Test Cases -- [ ] Design / Develop Solution -- [ ] Perform QA/Testing -- [ ] Update Documentation \ No newline at end of file diff --git a/bsip-00XX Sharedrop Operation.md b/bsip-00XX Sharedrop Operation.md deleted file mode 100644 index 5240094..0000000 --- a/bsip-00XX Sharedrop Operation.md +++ /dev/null @@ -1,153 +0,0 @@ - BSIP: TBD - Title: Sharedrop operation - Authors: OpenLedgerApp - Status: Draft - Type: Protocol - Created: 2018-12-17 - Updated: 2018-12-17 - Discussion: - Worker: TBD - -A sharedrop is a giveaway of some tokens to a certain group of people, for example to all BTS holders in proportion to their holdings. - -# Abstract -We should add the ability to distribute arbitrary amount of some token (SHAREDROP token) to holders of a specific other token (STAKE token) according to the share(stake) of such tokens. -The importance of a similar solution was raised in BSIPs-19, 20, however never implemented. (link below). - - -# Motivation -By implementing this proposal, we let Asset Owners or other businesses an opportunity to distribute their profit to the holders of a specific asset in proportion of the owned amount of this asset. - -Also, usual token drops can be done via the sharedrop operation. - -# Rationale - -- Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. -- Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within BitShares. - -To make it more difficult to abuse the system dropping multiple useless tokens, there will be a vesting stake for the sharedrop operation. For example, vest 5000 bitUSD (in BTS) for 2 month to be able to do sharedrop operation. - -Sharedrop operation should also be quite expensive as well. -However, to make such an operation more lucrative for BtiShares - the sharedrop operation will send the money to each stakeholder's vesting balance. Thus making them withdraw the drop from the vesting balances. - - -# Specifications -## General workflow -First of all, there is a need to calculate transaction fee, so **dry_run_sharedrop** operation should be called on a local node to do calculations. THe results will be provided (displayed) to a user. - -Then, knowing that user has enough BTS for transaction fees and vesting money, he should call Sharedrop operation itself. Vesting specifics will be covered below. - -Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. - -## dry_run_sharedrop operation -This is a locally done operation with the following parameters: - -- Sharedrop asset -- Sharedrop amount -- Stake asset -- Minimum stake asset amount to participate in airdrop (**minimum_amount_for_drop**) -dry_run_sharedrop operation returns transaction fee for the sharedrop operation as well as if a user has enough money in his sharedrop vesting or if he should prepare additonal funds. - -This will be approximate calculation as the final calculation will be determined only during the sharedrop operation. - -The following parameters are calculated by a node and presented to the user: - -- Sharedrop operation price -- Sharedrop vesting stake -- Sharedrop vesting period - -## Sharedrop operation -Sharedrop operation should be available with the following parameters: - -- Sharedrop asset -- Sharedrop amount -- Stake asset -Minimum stake asset amount to participate in airdrop (**minimum_amount_for_drop**) -Sharedrop operation will drop the Sharedrop asset in proportion to the stake that stakeholders have to their respective vesting balances. - -Each stakeholder will then need to retrieve the sharedrop token from the vesting balance in a separate operation. - -If the amount to distribute for stakeholders is too small and cannot be distributed among stakehoders or part of stakeholders then it accumulates and is returned to the account that originated sharedrop operation. - -## Sharedrop Parameters - -### Minimum amount to participate in sharedrop. -If an asset holder has too little amount of the stake token it becomes expensive for the blockchain to do sharedrop for such a user. -So a sharedrop operation should have **minimum_amount_for_drop** property. - -### Sharedrop price -sharedrop price should be determined based on the number of accounts (stakeholders) to split the value for, as in `stakeholder_number * sharedrop_price_multiplier`, where **sharedrop_price_multiplier** is defined by the committee. - -## Sharedrop vesting stake -Sharedrop vesting stake will be a flat fee determined by the committee. It will be charged in BTS. - -It will be in BTS only and it will be held on a vesting balacne under a specific sharedrop vesting policy for the period of **sharedrop_vesting_period (in weeks)** defined by the committee. At the end of the sharedrop_vesting_period, a sharedrop originator will be able to retrieve his funds from the vesting account. - -Let's say a vesting period is 2 months. -If a sharedrop originator does another sharedrop before the vesting period is over, the **sharedrop_vesting_period** counter resets and these 2 months will start from fresh. - -### Complicated vesting cases, when the committee updates sharedrop vesting parameters. -- Vesting stake increases. In this case **dry_run_sharedrop** operation warns the user that he should have more money prepared. And then the sharedrop operation will put more money into vesting. - -- Vesting stake decreases. Then the extra money becomes instantly available for withdrawal. Balance availability is checked during vesting withdrawal operation. - -- **Sharedrop_vesting_period** decreases or increases. The new vesting period is updated during the next sharedrop operation. - -## Technical specifications -``` -struct sharedrop_result { - // cost of sharedrop - share_type fee; - // required amount on the vesting balance - share_type vesting_stake; - // money may be claimed after this time - fc::time_point_sec vesting_period; -} -``` - - -There is a function that helps to fill parameters for sharedrop operation - -``` -// function that helps to fill parameters for sharedrop operation -// returns sharedrop_result -sharedrop_result dry_run_sharedrop(asset sharedrop_asset, asset_id_type stake_asset, -share_type min_stake_asset_amount) -``` - -For sharedrop vesting balance add specific type for vesting_balance_object - -``` -struct sharedrop_vesting_policy -{ - // money may be claimed after this time - fc::time_point_sec start_claim; -} -``` - -After each sharedrop operation start_clam will be updates as start_claim =TODAY + sharedrop_vesting_period - - -# Discussion -1. Flag **allow_sharedrop** for an asset. Should we have it? -Each asset should have **allow_sharedrop** flag (TRUE/FALSE) that would either allow sharedrop to the holders of this asset or not allow it. - -2. One of the ideas is instead of making flat fee vesting for all sharedrop transactions, for each sharedrop transaction we put into vesting an amount based on the stakeholder number. And we have to put a new amount for every sharedrop transaction. -In this case, it might quickly become too expensive for some users. - - -# See Also - -https://github.com/bitshares/bsips/blob/master/bsip-0020.md - -## Copyright -This document is placed in the public domain. - -# CORE TEAM TASK LIST -- [ ] Evaluate / Prioritize Feature Request -- [ ] Refine User Stories / Requirements -- [ ] Define Test Cases -- [ ] Design / Develop Solution -- [ ] Perform QA/Testing -- [ ] Update Documentation - From d41c1aba81b7618f883c6cebea90d056f893e508 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 18:28:35 +0300 Subject: [PATCH 30/32] draft 1 --- bsip-0043.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index d368943..a309c94 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -7,11 +7,9 @@ Updated: 2018-10-19 Discussion: https://github.com/bitshares/bsips/issues/102 Worker: - -# Abstract - -When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. + # Abstract + When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. From b93a916aecd57a74bc9f9f3256454b60abf6cfe4 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 17 Dec 2018 18:29:51 +0300 Subject: [PATCH 31/32] draft1 --- bsip-0043.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index a309c94..90bd660 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -7,9 +7,11 @@ Updated: 2018-10-19 Discussion: https://github.com/bitshares/bsips/issues/102 Worker: - - # Abstract - When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. + + +# Abstract + +When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. @@ -59,4 +61,6 @@ The new modification - market fee sharing - will allow to bring in new clients f This document is placed in the public domain. # See Also -https://github.com/bitshares/bitshares-core/issues/1268 \ No newline at end of file +https://github.com/bitshares/bitshares-core/issues/1268 + +https://github.com/bitshares/bitshares-core/pull/1419 From 857ad58f9ab7f80e1481153e66aa45d45e2ac5ff Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Tue, 18 Dec 2018 16:14:19 +0300 Subject: [PATCH 32/32] updated table --- bsip-00XX Dynamic market fees.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/bsip-00XX Dynamic market fees.md b/bsip-00XX Dynamic market fees.md index 97eda5e..29d695d 100644 --- a/bsip-00XX Dynamic market fees.md +++ b/bsip-00XX Dynamic market fees.md @@ -19,17 +19,17 @@ So, instead of market fee, an asset owner can optionally set up dynamic_market_f Trade daily volume | Maker fee, % | Taker fee, % ---|---|--- -< 500 USD | 0.19% | 0.20% -\>=500 USD | 0.18% | 0.20% -\>=1K USD | 0.17% | 0.20% -\>=2.5 K USD | 0.16% | 0.19% -\>=5K USD | 0.15% | 0.18% -\>=7.5K USD | 0.14% | 0.17% -\>=10K USD | 0.1% | 0.15% -\>=15K USD | 0.075% | 0.13% -\>=20K USD | 0.05% | 0.12% -\>=25K USD | 0.025% | 0.11% -\>=50K USD | 0.01% | 0.07% +<=500 | 0.19% | 0.20% +\> 500 | 0.18% | 0.20% +\> 1K | 0.17% | 0.20% +\> 2.5K | 0.16% | 0.19% +\> 5K | 0.15% | 0.18% +\> 7.5K | 0.14% | 0.17% +\> 10K | 0.1% | 0.15% +\> 15K | 0.075% | 0.13% +\> 20K | 0.05% | 0.12% +\> 25K | 0.025% | 0.11% +\> 50K | 0.01% | 0.07% ## Motivation