Fee Backed Assets (FBA)

[BunkerChainLabs-DataSecurityNode]

There are lots of different business models that will get the job done.

Pick one that doesn't violate any of the tests that governments routinely use to determine if something is a security.

I'm intrigued by the applicability of the Uber model for a privately operated taxi.

Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages.
Sell the cabs to the network in exchange for a set of tickets good for rental minutes on a cab.
Resell/trade those tickets on the open market.
This way, anyone can rent time on any of the limited supply of "cabs" and earn fees for performing delivery services.

So the STEALTH FPA could represent all available minutes on a network-owned fleet of robotic taxi cabs.

Buy up as many minutes of their time as you want and you have your own revenue generating business with no counter parties.

Meanwhile, the GUI for doing STEALTH transfers doesn't need to reflect any details at all about how the transfers are taking place metaphorically under the hood, whether by robotic cab or C++ function call.  They just specify the amount and destination and pay the fee and their funds are automagically teleported somewhere else. 

Poof!

Yes.. thats what I am talking about!

For housekeeping on the FBA it would just be something he committee can vote to make changes as needed.

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.

At that point the market comes online and people can buy at the rate that was set to fund the feature, and the monies collected to complete the work go into the developers bts account specified in the proposal.

Once the initial supply is sold off the developers BTS account is no longer recipient.. and only holders of the FBA actually receive payments from the transactions.

If future development or improvements need to be made a 'maintenance' proposal can be submitted that would then have more shares made of the FBA to fund it.. people will be able to buy up those shares to fund it and gain more shares of the profit.. or not participate in its development and become diluted. All fair.

All licensing associated with this format is optional according to the dev/creators specifications.

This to me would provide all the checks and balances in the process and keep it decentralized and without liability to holders.

Hope I have explained this clearly enough.

Anyone see some other way that might simplify this without compromising checks and balances or introducing liabilities?

[lovejoy]

I really like this line of thinking, and I'm curious to see it evolve.  It is a huge development for development and we need to arrive at a generally agreed upon elegant solution.

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.

[onceuponatime]

Would you be able to have funds automatically returned if a minimum isn't reached? For example, LottoShares could say if 150,000 worth of investment is not reached in 60 days, return funds to original sender.

This was my thought for how that would work in the STEALTH asset sale (remembering that I will have prepaid for the development and proceeds from sale reimburse me for that):

6. If not all of the shares offered to the community sell, then the remainder of the shares will be forwarded to me. There is therefore no question of "If they don’t all sell, offer to buy them back at the set price - i.e. refund them." They all sell by default.

[TravelsAsia]

Would you be able to have funds automatically returned if a minimum isn't reached? For example, LottoShares could say if 150,000 worth of investment is not reached in 60 days, return funds to original sender.

[luckybit]

There are lots of different business models that will get the job done.

Pick one that doesn't violate any of the tests that governments routinely use to determine if something is a security.

I'm intrigued by the applicability of the Uber model for a privately operated taxi.

Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages.
Sell the cabs to the network in exchange for a set of tickets good for rental minutes on a cab.
Resell/trade those tickets on the open market.
This way, anyone can rent time on any of the limited supply of "cabs" and earn fees for performing delivery services.

So the STEALTH FPA could represent all available minutes on a network-owned fleet of robotic taxi cabs.

Buy up as many minutes of their time as you want and you have your own revenue generating business with no counter parties.

Meanwhile, the GUI for doing STEALTH transfers doesn't need to reflect any details at all about how the transfers are taking place metaphorically under the hood, whether by robotic cab or C++ function call.  They just specify the amount and destination and pay the fee and their funds are automagically teleported somewhere else. 

Poof!

@Stan I think what we need is for you or someone like you to create a document, pamphlet, or file, which can be passed around, where people can see some examples of business ideas which can be started on Bitshares using the FBA. I think what potential entrepreneurs need right now is inspiration and ideas.

I'll put an idea out there. Why doesn't someone develop a Bitshares computer? The most secure computer design, tamper resistant, storage in the cloud? Simply take the design from: https://www.kickstarter.com/projects/designshift/orwl-the-first-open-source-hardened-computer

And modify it to have Bitshares and associated apps pre-loaded. Work with Cryptonomex on it so that witnesses can use this computer in some unique ways. Sell the Bitshares computer and reward by letting fees go to holders.

[Stan]

There are lots of different business models that will get the job done.

Pick one that doesn't violate any of the tests that governments routinely use to determine if something is a security.

I'm intrigued by the applicability of the Uber model for a privately operated taxi.

Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages.
Sell the cabs to the network in exchange for a set of tickets good for rental minutes on a cab.
Resell/trade those tickets on the open market.
This way, anyone can rent time on any of the limited supply of "cabs" and earn fees for performing delivery services.

So the STEALTH FPA could represent all available minutes on a network-owned fleet of robotic taxi cabs.

Buy up as many minutes of their time as you want and you have your own revenue generating business with no counter parties.

Meanwhile, the GUI for doing STEALTH transfers doesn't need to reflect any details at all about how the transfers are taking place metaphorically under the hood, whether by robotic cab or C++ function call.  They just specify the amount and destination and pay the fee and their funds are automagically teleported somewhere else. 

Poof!

[complexring]

How does this fit into a discussion people had a long time ago, where smart contracts would be created to each feature developer would earn from each feature they would implement? Maybe I'm confusing things? I don't know why the dev would need to sell those assets created from fees, when fees could just be paid in BTS and he could just get part of the fees.

That way people would have one more incentive to develop stuff. Referral program + earning from each use of their feature.

Don't know why there's the need to create a FBA when BTS can be used already to simplify things. And would give BTS more importance instead of splitting money through countless different assets.

This would be the same as when people buys apps on the playstore or apple store

what a fba does is allow for a better recording mechanism for those who wish to pay devs for implementing a particular feature and automatically pay out rewards to holders of a fba.  it's not so much that bts already is capable of doing this, but rather there are additional functions that are needed to simplify the bookkeeping.

so, instead of having a single entity be the private investor who reaps the rewards for funding a feature, the community that owns the fba is.  the parameters of the fba can then be adjusted accordingly and the fees collected from said feature are then used to pay back all holders of the fba, i.e. current investors of a feature, and eventually allows them to profit as the feature is continued to be used.

the risk, and the reward, are now community based, as opposed to a single entity, by those who wish to see certain features implemented immediately, or whom think they will have long-term value.

[BunkerChainLabs-DataSecurityNode]

How does this fit into a discussion people had a long time ago, where smart contracts would be created to each feature developer would earn from each feature they would implement? Maybe I'm confusing things? I don't know why the dev would need to sell those assets created from fees, when fees could just be paid in BTS and he could just get part of the fees.

That way people would have one more incentive to develop stuff. Referral program + earning from each use of their feature.

Don't know why there's the need to create a FBA when BTS can be used already to simplify things. And would give BTS more importance instead of splitting money through countless different assets.

This would be the same as when people buys apps on the playstore or apple store

I think this is springing out from market demand. Sure the other ways are possible.. but it seems to be of less interest. This all seems to be in response to what the market wants.

[Akado]

How does this fit into a discussion people had a long time ago, where smart contracts would be created to each feature developer would earn from each feature they would implement? Maybe I'm confusing things? I don't know why the dev would need to sell those assets created from fees, when fees could just be paid in BTS and he could just get part of the fees.

That way people would have one more incentive to develop stuff. Referral program + earning from each use of their feature.

Don't know why there's the need to create a FBA when BTS can be used already to simplify things. And would give BTS more importance instead of splitting money through countless different assets.

This would be the same as when people buys apps on the playstore or apple store

[BunkerChainLabs-DataSecurityNode]

My initial thought is that the liability then is in the hands of the issuer. Those that are buying are buying it with the expectation of future profit and therefore is issuing a type of security.

Perhaps the dev is in a country where this might not be the case.. but then it gets dicey in regards to who buys it where.

I think you have to remove 'she' from the equation, and let it be decentralized. She can create the FBA, set the price per share, and issue it.. and when that's done that's done. It moves to committee-member control. It can either be fully bought up and funded by the maker, or the market is open to buy it.

I think the key element here is that once the FBA is created, it really belongs to the blockchain after that. This removes all liabilities in my estimation as far as offering securities is concerned.

Thoughts?

I think a security is a security no matter how you dress it up.  And there is no point dragging in the committee members to front the deal.  If you want to stay out of trouble with the law, look at how kickstarter works.

I didn't suggest they front it.. I suggested once someone submitted it it would be passed on to them.

I think the committee is the ideal fit.. just like MPAs, FBAs are part of the network. Committee are there to oversee those things. There wouldn't really be anything for the committee to do though, except make adjustments to the fees when there was a need to do so.

Otherwise we run the risk of account abandonment (centralized issue). What if whom ever controls that account just disappeared for whatever reason? Now we got an FBA locked into the network that we can't do anything about.

Kickstarter doesn't stay out of trouble. It is regulated with all kinds of laws surrounding crowdfunding. Likewise, securities are regulated.. and this is no different.

Decentralizing the FBA is the only way to make it sustainable long term.

My 2 BTS.

[cube]

My initial thought is that the liability then is in the hands of the issuer. Those that are buying are buying it with the expectation of future profit and therefore is issuing a type of security.

Perhaps the dev is in a country where this might not be the case.. but then it gets dicey in regards to who buys it where.

I think you have to remove 'she' from the equation, and let it be decentralized. She can create the FBA, set the price per share, and issue it.. and when that's done that's done. It moves to committee-member control. It can either be fully bought up and funded by the maker, or the market is open to buy it.

I think the key element here is that once the FBA is created, it really belongs to the blockchain after that. This removes all liabilities in my estimation as far as offering securities is concerned.

Thoughts?

I think a security is a security no matter how you dress it up.  And there is no point dragging in the committee members to front the deal.  If you want to stay out of trouble with the law, look at how kickstarter works. 

[complexring]

one of the ideas proposed, or at least how i understood it, was creating a worker proposal that states that a UIA and the funds the sales of this UIA would be used to pay the developer for a particular feature.  see :  https://bitsharestalk.org/index.php/topic,20207.0.html .

what stan proposes is essentially the a sophisticated version of this idea, marketed with a pretty bow (not to say that we shouldn't consider marketing when presenting ideas), but presented as his own. 

essentially, features that we want developed can be funded by fee backed assets, and over time provide income by charging shareholders who use such features. those who invest and own said fba's profit.

the reference to the origins of this idea (or at least when i first encountered it) actually included in this post.

Yes it's a good idea. I came up with a similar base concept a while ago but didn't receive any replies at the time.

Revenue sharing model to allow crowdfunding major BTS blockchain additions

BTS could potentially enjoy major blockchain improvements without having to pay for them or take the risk that they are duds by creating a revenue sharing model that incentivises external developers and investors.

Edit: Well Bitcoinfan also came up with stuff in that vein.

...

thx for the earlier reference.  difficult to track the origins of something, especially in this forum.  cheers!

[BunkerChainLabs-DataSecurityNode]

We're all familiar with counterparty free
Market Pegged Assets (MPA)
and
issuer backed
User Issued Assets (UIA).

Theoretically, there could be a third type: 
Fee Backed Assets (FBA).

A developer installs a new function that charges fees for its service and pays those fees to holders of a UIA she creates for that purpose.

She naturally starts out as the owner of those revenue producing assets.

She is free to sell them since each one is a revenue generating counterparty free asset backed solely by the blockchain.

Since they have no counterparty, they are not a security.  They are simply capital equipment, like selling a mining machine.

This new kind of digital asset trades like any of the others but has fascinating new properties.

There could be a new asset for every new revenue generating feature in the whole ecosystem.  Developers recoup their costs by selling (or pre-selling) these revenue generating software devices (or keeping them to earn the revenue they produce.)

Thoughts?

My initial thought is that the liability then is in the hands of the issuer. Those that are buying are buying it with the expectation of future profit and therefore is issuing a type of security.

Perhaps the dev is in a country where this might not be the case.. but then it gets dicey in regards to who buys it where.

I think you have to remove 'she' from the equation, and let it be decentralized. She can create the FBA, set the price per share, and issue it.. and when that's done that's done. It moves to committee-member control. It can either be fully bought up and funded by the maker, or the market is open to buy it.

I think the key element here is that once the FBA is created, it really belongs to the blockchain after that. This removes all liabilities in my estimation as far as offering securities is concerned.

Thoughts?

[Empirical1.2]

one of the ideas proposed, or at least how i understood it, was creating a worker proposal that states that a UIA and the funds the sales of this UIA would be used to pay the developer for a particular feature.  see :  https://bitsharestalk.org/index.php/topic,20207.0.html .

what stan proposes is essentially the a sophisticated version of this idea, marketed with a pretty bow (not to say that we shouldn't consider marketing when presenting ideas), but presented as his own. 

essentially, features that we want developed can be funded by fee backed assets, and over time provide income by charging shareholders who use such features. those who invest and own said fba's profit.

the reference to the origins of this idea (or at least when i first encountered it) actually included in this post.

Yes it's a good idea. I came up with a similar base concept a while ago but didn't receive any replies at the time.

Revenue sharing model to allow crowdfunding major BTS blockchain additions

BTS could potentially enjoy major blockchain improvements without having to pay for them or take the risk that they are duds by creating a revenue sharing model that incentivises external developers and investors.

Edit: Well Bitcoinfan also came up with stuff in that vein.

Personally I think blockchain based gambling is the area that's going to kickstart the revenue sharing DAC boom. So I see Augur sports betting as having a big future. Also I imagine in a few years most dice sites/gambling sites will be blockchain based too. (Using revenue sharing + referral programme + advantages of decentralization - No hit and run/seizures, provably fair, cheaper, currency stable.)

[donkeypong]

Very cool.