bsips
bsips copied to clipboard
bitshares
BSIP68: Market Fee Based Asset (MFBA)
Dear BitShares Community,
We would like to introduce the Dynamic Market Fees BSIP. The purpose is to support high-volume trading and market makers. Thus making it more profitable for them. We believe it will bring more people to BitShares.
As per BitShares Core Team request we have spent some time drafting this BSIP. And here's the resulting BSIP: https://github.com/openledger/bsips/blob/bsip-mfba/bsip-00XX%20Market%20Fee%20Based%20Asset%20(MFBA).md The pull request is here: #134 The forum discussion is here: https://bitsharestalk.org/index.php?topic=27601.0
Please share your opinion. If you think it might help BitShares, please voice your opinion and vote for it, when the worker is created.
Sincerely, Denis Sokolov OpenLedger
The FBA concept as discussed on bitsharestalk.org was a way to incentivize devs to code new features. The devs get their labor investment back later from fees collected as their feature is used. It doesn't violate the Howie test if the investors are the inventors and sole recipients of proceeds from their own work. It may get sticky for people who sell STEALTH before it becomes operational, but the FBA approach should be no problem for regulators if the creators are the investors.
The implementation of FBA was funded by OnceUponaTime. Holders if the STEALTH tokens were to be the recipients of the network fees associated with that class of transactions. OnceUponaTime formed a management committee including myself and Kencode to manage operations related to this FBA, which was the first to utilize that feature. After kencode became involved to complete the work that Dan Larimer started, he discovered there was no mechanism in the FBA implementation to distribute the network fees (i.e. dividends) to the holders of the STEALTH tokens. The comments above reflect that as well.
I confirmed with both kencode and OnceUponaTime that their understanding and mine were the same, and indeed the discussions on the bitsharestalk forum were all in alignment regarding the distribution of network fees to the holders of the FBA asset (STEALTH tokens).
When kencode further investigated and found the references to a buyback scheme I asked Daniel Larimer to explain. He denied the original intention and distribution approach discussed in public and which was the basis for OnceUponaTime's generous investment, which directly funded Dan's work on implementing FBA. We were all very surprised, as no "buyback" scheme was ever discussed or disclosed to any of us, least of all the primary investor that funded the FBA implementation, OnceUponaTime.
This all occurred in the last quarter of 2015 and first quarter of 2016 as Dan Larimer was looking for ways to fund development and ultimately decided to move on to steemit.
It left a very bad taste in my mouth and put a serious dent in my respect for Dan. I DM'd him in Telegram to discuss this and voiced by disappointment for his lack of integrity in not disclosing the changes to the FBA design to OnceUponaTime.
I had totally forgotten the steemit article I wrote about this last year, where kencode described what he found in detail. I was reminded of that after reviewing my DM conversation with Dan Larimer from Nov 7th, 2017. Here is a link to that steemit article: https://steemit.com/cryptocurrency/@full-steem-ahead/re-agorise-re-agorise-the-agorise-report-c-ipfs-stealth-and-blinded-transactions-pos-systems-mobile-wallets-graphenej-20171106t173545426z
Thomas, as others mentioned FBA, we did an investigation on FBA. It seems that fee for STEALTH assets is collected. However, there does not seem to be a mechanism that splits this fee among the STEALTH stakeholders. There is a market of STEALTH asset... However, it seems quite dead now. Meaning STEALTH assets are not really valuable. I am not sure where the stealth operation fee goes now. Some of it goes to a particular account, possibly OnceUponaTime's.
In any case, even when enhanced and completed, FBA seems to be quite limited. The main limitation is that it only SHARES THE FEES COLLECTED FOR A PARTICULAR OPERATION, such as stealth transaction and it hardcodes the tie between this operation to the specific asset.
What we offer in the MFBA is an ability to tie ANY ASSET to MARKET FEES of a group of OTHER ASSETS. in this case, it's not hardcoded, but rather is determined in asset settings.
It has quite different purpose than FBA, namely split profits from market fees.
Of course, we have to be careful with having such a feature in the blockchain.
I worked with @OpenLedgerApp to establish a drafting budget for this BSIP of 10 hours. It will be paid in weeks 50-51.
Revisions will continue within this budget.
To my knowledge, buyback of STEALTH tokens from stealth operation fees was fully implemented and is working as designed. https://bitsharescan.com/account/stealth-buyback
Dividend-like payments to a large number of token holders are computationally expensive. That's the reason why STEALTH works like it does - it buys back tokens from the market (which is computationally cheap), which creates demand and drives the price up, to the benefit of all STEALTH holders.
Dividend-like payments to a large number of token holders are computationally expensive. That's the reason why STEALTH works like it does - it buys back tokens from the market (which is computationally cheap), which creates demand and drives the price up, to the benefit of all STEALTH holders.
Of course "buybacks" are different from "dividends" not only legaly but also emotionally. In the first case, the price goes up, while in the latter case, the amount goes up. Depending on juristiction, buybacks are covered in different law and may be favorable ..
Dividend-like payments to a large number of token holders are computationally expensive. That's the reason why STEALTH works like it does - it buys back tokens from the market (which is computationally cheap), which creates demand and drives the price up, to the benefit of all STEALTH holders.
We are planning to run a performance test and measure computation, in order to evaluate whether the maintenance interval can be elongated depending on token holders.
I like this BSIP as it is the consequent evolution of the Market fee sharing BSIP that is already voted in.
Market fee sharing allows the asset owner to share market_fee_reward_percent with the registrar/referrer, and now you can additionally choose to to share another % with asset holders.
Nevertheless, please streamline your wording. Are you certain you want MFBA to be a SmartCoin?
IMO the term SmartCoin is applicable here. In my understanding, it's a generalization of MPA, PM, FBA, and anything else that is based on some automatism.
The wording SmartCoin / BitAsset is exclusively reserved for crypto-collaterized, user-loaned tokens like bitUSD in my understanding.
We are planning to run a performance test and measure computation, in order to evaluate whether the maintenance interval can be elongated depending on token holders.
We have made a prototype in order to measure the performance. You can see the results here:
Please explain what exactly you're measuring there.
First impression is that processing time increases by 30%, which is not acceptable IMO.
We would like to explain the previously attached image. First of all, we want to update it with more relevant data. We have our stock-asset with the currently develop branch https://github.com/openledger/bitshares-core/commit/acf57de289aa4b43d16d5629c5d9de8a6aad9286
First of all, this graphic measures the duration of the maintenance interval, and not the work of the node as a whole. The horizontal axis shows the number of test runs, the vertical axis shows the time of the maintenance interval. Before measuring the maintenance time, the following steps are taken:
- 12000 regular accounts are created (without real actions with them, for the total load)
- 4000 user-asset is created
- 10,000 accounts are created that will produce the assets that were created in the previous step.
- Set up a new interval for maintenance, which is guaranteed not to be fulfilled during the whole trading period
- 5000 orders and 5000 counter orders are created (half with full collapse, half with incomplete)
- Waiting for the next maintenance and measure its work time.
The Red line is the result of these steps.
A testnet for this test is going to develop bitshares branch, the last commit in which [0358f286cebf83cd498a11411c84ab0aa927b689]
There are following steps for measuring the interval maintenance with implemented sharedrop:
- 100000 regular accounts are created (without real actions with them, for the total load)
- 20,000 accounts are created, which will be the owners of the stock-asset
- 4 stock asset is created, each of which has 1000 user-assets (total of 4004 assets)
- 10,000 accounts are created that will produce the assets that were created in the previous step.
- Set up a new interval for maintenance, which is guaranteed not to be fulfilled during the whole trading period
- 5000 orders and 5000 counter orders are created (half with full collapse, half with incomplete)
- Waiting for the next maintenance and measure its work time.
The Blue line shows the result of these steps. Since in this case, the logic of distribution of remuneration to stock-assets holders starts namely, 20,000 accounts, the maintenance interval execution time is increased.
We hope these explanations will answer all your questions.
5000 orders and 5000 counter orders
This is way too small IMHO.
(half with full collapse, half with incomplete)
Filled orders should be much more than unfilled. Maybe 100K filled orders and 1K unfilled orders would be OK.
We would like to put our BSIP on voting. Current prototype allows to trade and makes sharedrop operations under maintenance interval. Core-team also has some worries about computation resources.
What should we do to put this BSIP on voting?
@ryanRfox please let us know. Thanks in advance!
IMHO this BSIP lacks of technical specifications. Also it didn't mention anything about legal risks.
You have not adressed all comments. It makes no sense to define this as a separate asset type, and especially not only for SmartCoins.