Author Topic: Fee Backed Assets (FBA)  (Read 7979 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12920
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Is this change actually happening or is it a proposal?
This "is" going to happen for the Stealth feature ("is" happending depends on whether shareholders approve the worker and the implicit hard fork)

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12920
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline Zapply

  • Jr. Member
  • **
  • Posts: 48
    • View Profile
  • BitShares: Zapstar

Offline Samupaha

  • Sr. Member
  • ****
  • Posts: 479
    • View Profile
  • BitShares: samupaha
What you are calling for is a model that disenfranchises the community at large or others to participate. The ultimate result of this, as we have seen demonstrated, is that the community will not support something that is integral as part of how bitshares works unless they can have at least the opportunity to participate.

How this has been demonstrated? We haven't tried this yet.

I see no reason why BTS shareholders would reject a feature if it brings more users and revenue for Bitshares. That's the goal of DAC – to get as much users as possible by offering them useful services. That's how we make the whole business profitable.

Offline bitacer

There are BTS holders with different time-preferences, some want to hold it while some do not. Look at it any way you like, savers and others. FBAs would be great way for those savers to invest their equity in. This will be a good example of a DAC.

Offline BunkerChainLabs-DataSecurityNode

I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this.

What kind of liabilities you mean? I'd like to see concrete examples so we can understand better what we are dealing here with.

On the other points, we are not necessarily on the same page here.

My central point is that FBA is a deal between Bitshares and developers/investors of a feature. Bitshares recieves the feature and developers/investors recieve the FBA.

There is no need for any kind of FBA-sale. There might be a sale of FBAs because it is funded by crowdfunding, but that should be managed by the crowdfunders. It doesn't even need to happen in these forums, it can be other forum, Kickstarter or something else. There might be a genius idea for some cryptocurrency, and the developers choose to implement it in Bitshares rather than making their own blockchain. They can design and crowdfund it in their own forum and come to us when they have a deal to propose.

This is what I meant with when I said that funding via reserve pool is too limiting. Funding doesn't need to be on the blockchain. Blockchain can be used for that, but I don't see any reason why it should be done only with Bitshares blockchain.

Privatized funding doesn't need to look anything like the worker system we now have. I think it will be a lot more efficient when there is a small group of developers/investors who handle the whole thing and don't ask much from the community. They don't have to waste time on the forums where lots of people are complaining how expensive it is, or how they want it changed, or how they are never going to use it. Instead developers/investors can design a killer feature on their own. They will of course keep all the profits, so they have great incentives to really focus on getting the feature right. They don't need to ask other people to market the feature, because they have an incentive to do it themselves.

There is a need.. which is what has facilitated this whole idea of an FBA.

What you are calling for is a model that disenfranchises the community at large or others to participate. The ultimate result of this, as we have seen demonstrated, is that the community will not support something that is integral as part of how bitshares works unless they can have at least the opportunity to participate.

I know you are saying a crowdsale should go on somewhere else, however, it will never happen so long as the community is disconnected from he entire process. What I am proposing actually will determine if there will be enough supporting votes within the community for such feature to be implemented, and also allows whatever investors are involved to supply the money needed to fulfill its completion. It can all be done on the blockchain and be open to decentralization instead of only being centralized with the maybe or maybe not of some kind of distribution taking place later.

At least thats what I understand from what you are proposing.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Samupaha

  • Sr. Member
  • ****
  • Posts: 479
    • View Profile
  • BitShares: samupaha
I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this.

What kind of liabilities you mean? I'd like to see concrete examples so we can understand better what we are dealing here with.

On the other points, we are not necessarily on the same page here.

My central point is that FBA is a deal between Bitshares and developers/investors of a feature. Bitshares recieves the feature and developers/investors recieve the FBA.

There is no need for any kind of FBA-sale. There might be a sale of FBAs because it is funded by crowdfunding, but that should be managed by the crowdfunders. It doesn't even need to happen in these forums, it can be other forum, Kickstarter or something else. There might be a genius idea for some cryptocurrency, and the developers choose to implement it in Bitshares rather than making their own blockchain. They can design and crowdfund it in their own forum and come to us when they have a deal to propose.

This is what I meant with when I said that funding via reserve pool is too limiting. Funding doesn't need to be on the blockchain. Blockchain can be used for that, but I don't see any reason why it should be done only with Bitshares blockchain.

Privatized funding doesn't need to look anything like the worker system we now have. I think it will be a lot more efficient when there is a small group of developers/investors who handle the whole thing and don't ask much from the community. They don't have to waste time on the forums where lots of people are complaining how expensive it is, or how they want it changed, or how they are never going to use it. Instead developers/investors can design a killer feature on their own. They will of course keep all the profits, so they have great incentives to really focus on getting the feature right. They don't need to ask other people to market the feature, because they have an incentive to do it themselves.

Offline BunkerChainLabs-DataSecurityNode

i would like to do it KISS - keep it simple and stupid!

in bitshares to many features are to complicated, so let us think how we can do a FBA without much overhead.

1. some people create a multikey account. could be the committee or something totally different
- they control the creation and maybe the payment if wanted
2. buyback can also be handled with this multi account or better something is coded for automation buyback

Sounds like a good version 1. :)  +5%
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
i would like to do it KISS - keep it simple and stupid!

in bitshares to many features are to complicated, so let us think how we can do a FBA without much overhead.

1. some people create a multikey account. could be the committee or something totally different
- they control the creation and maybe the payment if wanted
2. buyback can also be handled with this multi account or better something is coded for automation buyback

Offline BunkerChainLabs-DataSecurityNode

In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.

Approval from committee members isn't enough, it has to be worker proposal. Or we could create new kind of worker proposal that is meant only for FBAs. But the point is that if the new feature will require a hardfork, it should be approved by the shareholders. Just like it is now.

I don't think that the problem of shareholders voting down FBA-proposals will last very long. It is problem only for a short period when only party that has enough skills and knowledge is Cryptonomex. When there are other developers who can be hired to implement features, they will be voted in without any problems because they don't consume any manpower from more important features that are funded by DAC.

I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this. The developers of the feature however are free to set the terms of licensing however they see fit. It's the coop setup of the whole thing that can introduce serious regulatory issues that can cause problems if not setup right. Thus you do not want a single person/company to be the holder of an FBA, you want it to be part of the decentralized network. In the end, if they want to profit from the introduction, they can always buy up as much of the FBA as they like when it gets created.

Only time committee members might need to manage an FBA would be to adjust the fees to compensate for market movement.. ie. BTS goes from 0.001 to 0.10 .. pretty sure the FBA holders would like to see some action taken on that.. and I envision this to become a regular part of committee member activity that would likely just shift all fees on a % scale easily to compensate with the market movement. This again should not be left to an individual for securities and liability reasons. We don't want a crowdfund.. we want a coop as far as how this works where regulations are concerned.

What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?

I think this is too limiting way for funding. Remember, we are trying to get privatized funding here. There can be many different kind of developers, companies, investors and crowdfunders and not all of them are interested in having the funding go through reserve pool. Simpler way is just to give them the FBA and they can do whatever they think is best and suitable for their business plan.

I think I may not have explained it clearly enough. The funds are going from the FBA sale into the reserve pool which is payout out for the Worker 1:1 with it's budget for the FBA project only after it has reached 100% of funding via the sale of the FBA initial shares issued. Anyone will be free to buy them on the DEX (though I think a better interface should be used for that initial sale). This uses our existing systems and prevents crowdfunder fraud transactions and keeps all the transactions coming from whomever is contributing coming through bitshares. It all stays on the blockchain. The payment might not need to go to the reserve pool actually though. Could just have the funds go directly to the Worker that created it. However a new mechanism would need to be created to either vest the balance until 100% funding is reached or some other parameter.

A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.

I like this method better.. it will keep our funding method for new features in the same place under Worker.

This is not only and maybe not even preferable way for funding. I predict that there will be lots of complaining in this kind of contracts. Crowdfunders want a feature and somebody says "yeah, I'll do it for 20k" and after a while they announce that "20k isn't enough, I want more".

I think easier way would be that a company or a group of developers make the feature half way ready and then announce that "we have a new feature and if you want it implemented in Bitshares, we want in exchange an FBA with these parameters". BTS shareholders don't need to know how much the feature cost to develop – all that we have to care is that will it be a good deal for Bitshares. Do we want that feature on the blockchain, how many users it could get, etc.

How good or bad the developers are will depend on the judgement of the community at large. I am rather confident they are going to be ruthless in their vetting. What you are arguing is exactly the same thing that can happen with Workers now. Has nothing to do with FBAs. If you have devs half way develop things before introducing them to the community they certainly can do that if they like.. I doubt you are going to have many developers take that risk though. It is far more likely that people interested in a particular feature are going to seek out dev resources on their own prior to rallying a fund together much like what you have seen happen with Stealth feature. Even if they start from forum and someone says they can do it for X amount like you said, the funders can decide how to handle that long before creating an FBA and perhaps ask the dev to do as you suggested in creating it half way on his/their own. That would/could all happen pre-FBA.

@rgcrypto mentioned division of funds. I agree with 20% going to the network. However, the accumulation of 20% for maintenance seems like a slush fund that is just going to be raided by.. who? Would it be enough for all those things?

I think its better to let the profits go to the funders.. have the 80% go full on to all holders.. they are free to buy and sell them as they wish in the market. If there is improvements or updates to be done it means another worker and more shares put out on that FBA feature. Existing holders can either buy them up in support, or allow others too and dilute their positions. The 20% otherwise could become a bottleneck to properly funding things.. then we have what @Samupaha said about developers coming back saying they need more money (for different reasons.. ie the fees collected in the 20% isn't enough to cover the maintenance or updates) and now no decentralized mechanism to get the job done.

In the end.. what I am suggesting in how FBAs work gives total freedom to whom ever wants to see a particular feature backed that others are likely to want to be involved with to create a worker proposal that can then be bought up by whom ever would like to participate while keeping the entire coop decentralized, sustainable, efficient,  and free of regulatory issues.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Samupaha

  • Sr. Member
  • ****
  • Posts: 479
    • View Profile
  • BitShares: samupaha
In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.

Approval from committee members isn't enough, it has to be worker proposal. Or we could create new kind of worker proposal that is meant only for FBAs. But the point is that if the new feature will require a hardfork, it should be approved by the shareholders. Just like it is now.

I don't think that the problem of shareholders voting down FBA-proposals will last very long. It is problem only for a short period when only party that has enough skills and knowledge is Cryptonomex. When there are other developers who can be hired to implement features, they will be voted in without any problems because they don't consume any manpower from more important features that are funded by DAC.

What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?

I think this is too limiting way for funding. Remember, we are trying to get privatized funding here. There can be many different kind of developers, companies, investors and crowdfunders and not all of them are interested in having the funding go through reserve pool. Simpler way is just to give them the FBA and they can do whatever they think is best and suitable for their business plan.

A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.

I like this method better.. it will keep our funding method for new features in the same place under Worker.

This is not only and maybe not even preferable way for funding. I predict that there will be lots of complaining in this kind of contracts. Crowdfunders want a feature and somebody says "yeah, I'll do it for 20k" and after a while they announce that "20k isn't enough, I want more".

I think easier way would be that a company or a group of developers make the feature half way ready and then announce that "we have a new feature and if you want it implemented in Bitshares, we want in exchange an FBA with these parameters". BTS shareholders don't need to know how much the feature cost to develop – all that we have to care is that will it be a good deal for Bitshares. Do we want that feature on the blockchain, how many users it could get, etc.

Offline rgcrypto

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
    • Cryptoctopus Blog
In the case of STEALTH for example, the distribution of fees could be:

20% goes to the network
20% in a multisig account for maintenance, upgrade or development on related products
60% goes to holders of the FBA...paid daily in BTS.  8)

This way, the feature can keep on improving and extend it's product line in order to become more and more profitable.


Offline BunkerChainLabs-DataSecurityNode

Great idea. @Stan do I understand you right, that all those features with their "feature coins" have to be approved by the shareholders still?
I assume yes. How should it work differently in Bitshares currated apps model...
So it could be that dev1 gets feature 1.1 approved (e.g. stealth tx). Then dev2 gets feature 1.2 (ring sign) approved. Then comes 1.3... With 1.3 shareholders decide to take 1.1. and 1.3 out again (not anymore part of the bitshares code).
That would be a possible cenario right?
Just thinking out loud a bit...

In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.

I maybe wrong on this point though. I think once the feature is done I think it would have to still be submitted as a Worker with no charge for the community at large to vote on it. So maybe having the initial creation process begin as a Worker that doesn't take any funds so the community can vote on support for it would allow everyone to further validate it via the blockchain prior to its creation. That just gave me an idea.... here it comes..

What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?

This means that the payout mechanism to the developer or project manager handling the dev and implementation of the new feature gets paid through the same Worker area, only the funds are coming from the FBA initial sale. I would suggest that this payout feature does not start to payout until the FBA has been fully funded (ie all share supply sold).

A 3rd party escrow/project QA (like what we are doing for Cryptonomex worker) could ensure the developers are paid according to the budget and remaining funds can then go back to the reserve.

A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.

I like this method better.. it will keep our funding method for new features in the same place under Worker.

In the end though, the FBA is STILL going to be assigned to the committee members for ongoing maintenance. I would also urge that the terms of the initial FBA in regards to income spits and terms in points be burned into the blockchain itself, with reference to some place like github where all historical versioning is recorded regarding the feature.

THIS to me will continue to work under all conditions worldwide no matter how regulatory changes come an from where. This is a coop type of funding and return that has checks and balances and no one liability source in any levels. The only liability is at on the project manager and/or developers at the time of creation to deliver. After that they have just done a job and they are done.

THIS IS AWESOME!
« Last Edit: November 28, 2015, 03:04:53 pm by BunkerChain Labs »
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Great idea. @Stan do I understand you right, that all those features with their "feature coins" have to be approved by the shareholders still?
I assume yes. How should it work differently in Bitshares currated apps model...
So it could be that dev1 gets feature 1.1 approved (e.g. stealth tx). Then dev2 gets feature 1.2 (ring sign) approved. Then comes 1.3... With 1.3 shareholders decide to take 1.1. and 1.3 out again (not anymore part of the bitshares code).
That would be a possible cenario right?
Just thinking out loud a bit...

Offline Samupaha

  • Sr. Member
  • ****
  • Posts: 479
    • View Profile
  • BitShares: samupaha
One thought I had: If a committee controlled account is not involved in the issuance of said FBA somehow... it would be wise to create a multi-sig mechanism to guard against various unfortunate events which could occur, such that should an issuer of the FBA die, or lose their owner key, or become compromised somehow, all would not be lost.  The issuer could choose a number of trusted parties with whom to vouchsafe control over the FBA.  There's probably a really uncomplicated way to achieve this, conceptually it makes sense to me, not sure of the best mechanics.  Food for thought.

What if the owner dies or loses the owner key? That would be their loss, of course, but it would also affect Bitshares.

Let's say there were a feature that charged 50 cents per transaction, and 10 c of that went to Bitshares and 40 c to owners of the FBA. If the FBA owners lost somehow the control of the FBA, then they wouldn't have anymore any incentive to market or improve the feature. Users would be paying 40 c per transaction extra for every transaction for nothing.

There are some ways to address this problem:
- Bitshares could just copy the feature (by worker) and charge only 10 c per transaction. Users would switch to use that because it was cheaper.
- Somebody else could copy the feature and issue a new FBA for it, and BTS owners would accept this because now there were somebody who had right incentives.
- FBA had to be "activated" occasionally, like every six months. If it weren't activated, it would lose the ability to get revenue from users of the feature. If somebody lost his owner keys, this would automatically deactivate his FBA. After this happening, the rest of the FBAs would be more valuable because they would get more royalties. This way the rest of the FBA owners would have incentives to market and improve the feature. If all FBAs became deactivated, their share of the transaction cost would be set to zero and users would only pay the BTS share of the cost , 10 c in this case.

I think perhaps initially though in the creation of an FBA.. having it available the same way other assets can be created might not be ideal..

I think an FBA Proposal needs to be submitted first.. make clear the parameters of what it is how it works etc.. then once that is all clear submit it to the committee to create it. If the committee members .. they can then vote to have it enabled.

I'm assuming we are talking here about features that will require a hardfork. So if there is going to be a hardfork, there will be also a worker proposal. I think it would be best occasion to issue FBA. If the worker contract is fully funded, the FBA will be issued automatically. FBA owners start to get revenue once the feature is implemented on the blockchain.