BSIP - Market Fee Backed Asset (MFBA)

[OpenLedgerApp]

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.

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.

Specifications

Market Fee Backed Asset Definition
New attribute of the SmartCoin - "MFBA" attribute becomes available for the users. Asset for which "MFBA" option 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.

Dividends
Market Fee, received from the 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 left for the Asset Owner.
Funds currently in the open orders will not be included in the MFBA share.

Blacklist and Whitelist
Whitelist and blacklist (configurable by the UIA Issuer) could provide control over who is eligible to earn dividends.

Dividends Distribution Process
Distribution will be performed in a set period of time. Period of time 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' "special balances" and to the MFBA Issuer "special balance".
After that MFBA holders and MFBA Issuer can claim the fees.

Dividends Distribution Process Restrictions
Distribution must be performed starting from the user, that has the biggest share of the MFBA Asset.
Users for which amount to be transferred is less, than should be accrued, will not receive their share of Market Fee.

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[xeroc]

.
Distribution of fees will be conducted automatically (in a pre-defined period of time). Such functionality is currently not available in the blockchain.

Please take a look at FeeBacked Assets, they come with tge functionality of distributing a balance to asset hokders by means of a buy backbin the internal edchange.

Also, there is a patch available in peerplays that adds dividends to graphene thru dividends-accounts. That particular feature can and imho should be used for this.

So ultimately, i would recommwnd you lookup the existing dividends proposal (code in peerplays) and adept the market fees to allow paying to the dividends accounts.

[xeroc]

This is the code I am talking about:
https://github.com/bitshares/bitshares-core/blob/master/libraries/chain/db_maint.cpp#L713

[OpenLedgerApp]

Thanks, Fabian.
We will look into the code, BSIP-20 and peerplays approach.
I assume BSIP-20 is slightly different from what we propose (it's a bit difficult to gauge because BSIP-20 description is rather vague). However, more in-depth code investigation is needed.
Denis

[xeroc]

This is the code for dividends

Please note the discussion there!

[OpenLedgerApp]

@xeroc we have looked into the code of Peerplays (BSIPs-19, 20). It is somewhat similira. I will respond a bit later.
Meanwhile, what about FBAs? I have found a lot of issues and discussions about BSIP-07(FBA) .
And I do not understand what has been done about BSIP-7? is it complete? is it just an idea? was it put on hold?
You were one of the authors. Can you tell me please?

[OpenLedgerApp]

@xeroc @abitmore We looked into FBA. It has been done a few years ago.
However, we are concerned if we can do a sharedrop or even share market fees with the FBA holders.
It looks like only 1 buyback account is getting all the fees. And these are only network fees.
Does anyone know and can explain a good use case how to use FBA in a current implementation?
We will look into code some more time tomorrow. However we do not see how we can share the money with the FBA token holders as of right now.

[OpenLedgerApp]

We have done more investigation. ANd here are our results:

FBA

1. whereas FBA looks like cover a similar thing as MFBA, every FBA issued requires a hardfork in our understanding.
2. Moreover, FBA only allows income from a specific transaction. And MFBA allows income from market fee of a particular asset.
3. ANd right now we have not found a mechanism that distributes money from buyback account to FBA asset holders. There is supposed to be one, but we have not seen it.
   All of the above, make FBA quite unusable for sharedrop or distribution of market fees.

Peerplays code, BSIP-19. -20

Here are the findings and the conclusion of the investigation done with PeerPlays code.

1. This code was done for the very outdated version of BitShares.
2. It has not been tested. So we have no idea about code quality or even if we are able to compile and run it at all.
3. It cover sharedrop only, no market fee distribution among asset holders.

So to bring this code to BitShares we would need to do the following pieces:

1. Understand the code fully
2. Check if it works
3. Move the code to BitShares
4. Update it to the recent version of BitShares
5. Update the functionality to add Market Fee distribution
6. Write tests for both sharedrop and market fee distribution
7. Test

**So taking all of the above into account, it makes it quite a big hassle and a significant effort to bring this code over to BitShares at present time. **

Also, BSIP-43 https://github.com/bitshares/bsips/blob/master/bsip-0043.md
is almost done. The proposed MFBA worker can be significantly based on the BSIP-43 vesting distribution code base, making it much easier to implement.

Current ideas

So at this point I would like to offer 2 things to the community:

1. Implement MFBA as a way to automatically distribute market fee profit to asset holders as it was described in the proposal above. Take some ideas from BSIP-19,20 if needed.

2. Implement Sharedrop transaction for holders of a particular asset.
   As a mechanism against dropping shitcoins we could have a minimum stake in BTS with some vesting time. For example, to do a sharedrop one would need to vest an equivalent of $10000 in BTS for a couple of months.

We can implement 1 or 2 - depending on the voting and discussion within the community.
Also, implementing both would be only marginally more expensive than implementing only one of them.

What do you guys think?
Denis

[ThomasFreedman]

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

[nutelina]

Knowing BitShares from summer 2017 I'd expect smartcoins like bitUSD etc. to have this feature resp. the core token BTS. My logic would suggest paying holders of BTS or bitUSD fees when they are traded, the reason is the risk for holding on to BTS collateral for bitUSD should be rewarded.

[xeroc]

It looks like only 1 buyback account is getting all the fees. And these are only network fees.
Does anyone know and can explain a good use case how to use FBA in a current implementation?

You simply claim the other fees and send them to the FBA/dividends account. The funds will be distributed automatically.

[ThomasFreedman]

BM left the project before the FBA feature could be completed and tested. Looks like you get the honors now. Since the whole buy back scheme was pretty much only in his head, it's up to devs to work out the details of how this should work.

[OpenLedgerApp]

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.

[OpenLedgerApp]

Moved to the BSIP PR:
#134
I will answer there.
Denis

[ThomasFreedman]

Yes, I see differences and they are dangerous for USA market. That was why original FBA concept was limited to disbursement to ONLY those investors that funded development and not beyond, so ot couldn't be seen as a violation of SEC regulations like Howie test. No violation if risk is limited to your own speculation / investment and not others funds.

Unfortunately you're right, STEALTH token is pretty much dead now. Once no longer holds many STEALTH tokens if any. Kencode is focused on PalmPay. He has contributed to stealth tech, but hasn't been pushing it too much of late. I believe chris4210 holds lots of STEALTH now from his hostile takeover of BlockPay.

As you implement MFBA I highly recommend you integrate whitelist feature with it to limit application to specific people. Probably should have KYC too (I can't believe I'm recommending that, but only to save entire ecosystem from being a target to USA - SEC).

I see utility of your MFBA, but I also see the risks, risks FBA avoided.

Glad to see your involvement in furthering ecosystem tho. Carry on with caution.