2015-12-16 11:37:08 +00:00
|
|
|
BSIP: 0007
|
2015-12-17 09:09:48 +00:00
|
|
|
Title: Fee Backed Assets
|
|
|
|
Authors: Danial Larimer <Dan@cryptonomex.com>
|
|
|
|
Stan Larimer <Stan@cryptonomex.com>
|
2015-12-17 12:24:20 +00:00
|
|
|
Fabian Schuh <Fabian@BitShares.eu>
|
2015-12-16 11:37:08 +00:00
|
|
|
Status: Draft
|
2015-12-17 10:44:40 +00:00
|
|
|
Type: Informational
|
2015-12-16 11:37:08 +00:00
|
|
|
Created: 2015-12-16
|
2015-12-17 09:09:48 +00:00
|
|
|
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
|
|
|
|
Worker: not applicable
|
2015-12-16 11:37:08 +00:00
|
|
|
|
|
|
|
# Abstract
|
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Existing core features of the BitShares protocol are Market Pegged Assets (MPA)
|
|
|
|
and issuer backed User Issued Assets (UIA). In this proposal, we introduce
|
|
|
|
another type of asset: *Fee Backed Assets (FBA)*.
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Feed backed assets allow to propose and fund *market based* innovation by
|
|
|
|
sharing a cut of future profits generated by this particular innovation with the
|
|
|
|
people that helped fund it. Think of it as a *Kickstarter* for features.
|
|
|
|
Hence, if people can profit from successful features in the form of fees then it
|
|
|
|
can help the BitShares ecosystem to become more adaptable over time as it
|
|
|
|
promotes innovation and can pay for its development.
|
2015-12-17 09:09:48 +00:00
|
|
|
|
|
|
|
# Motivation
|
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Let's assume a developer installs a new function into the BitShares protocol
|
|
|
|
that charges fees for its service. Where should those fees go? To the developer?
|
|
|
|
To the share holders? How should a decision be made? Why would share holders vote
|
|
|
|
to fund a feature if they can't profit from it?
|
2015-12-17 09:09:48 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
The answer is to pay the profits from fees generated by the feature to holders
|
|
|
|
of a UIA that has been created for that purpose, specifically. In other words:
|
|
|
|
owners of that UIA own a portion of those revenue producing assets. This revenue
|
|
|
|
generating counterparty free asset is backed solely by the blockchain and its
|
|
|
|
user base and can be sold freely on the decentralized market.
|
2015-12-17 09:09:48 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Since they have no counterparty, they are **not a security**. They are simply
|
2015-12-17 09:09:48 +00:00
|
|
|
capital equipment, like selling a mining machine.
|
|
|
|
|
|
|
|
This new kind of digital asset trades like any of the others but has fascinating
|
|
|
|
new properties.
|
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
For every new revenue generting innovation or feature in the whole ecosystem,
|
|
|
|
there can be a new fee backed asset. Developers recoup their costs by selling
|
|
|
|
(or pre-selling) these revenue generating software devices (or keeping them to
|
|
|
|
earn the revenue they produce.)
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 09:09:48 +00:00
|
|
|
# Examples
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 09:09:48 +00:00
|
|
|
## Taxi Rental
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Let's assume we 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. Now we can resell or trade of 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.
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
The `TAXI` FPA could represent all available minutes on a network-owned fleet of
|
2015-12-17 09:09:48 +00:00
|
|
|
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.
|
2015-12-16 11:37:08 +00:00
|
|
|
|
2015-12-17 09:09:48 +00:00
|
|
|
## Project/Feature Funding
|
2015-12-16 11:37:08 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
In the case of the [Privacy Mode](bsip-0008.md), the project development can be
|
|
|
|
funded by a PRIVACY FPA that gets their owners a cut of fees produced by
|
|
|
|
transactions using that feature in the future. Every BitShares customer that
|
|
|
|
wants to gain advantages of that Privacy Mode needs to pay an increased fee for
|
|
|
|
its service. These fees are distributed among all owners of the `STEALTH` asset.
|
2015-12-17 09:09:48 +00:00
|
|
|
|
2015-12-21 13:26:47 +00:00
|
|
|
# Regulatory Issues
|
2015-12-17 09:09:48 +00:00
|
|
|
|
|
|
|
One of the first and thorniest problems we tackled is the nasty fact of
|
|
|
|
*Regulatory Risk*. There exists a vocal contingent of people who want very much
|
2015-12-21 13:26:47 +00:00
|
|
|
that an FBA (fee based asset) be created to fund a feature upgrade to the
|
2015-12-17 09:09:48 +00:00
|
|
|
BitShares blockchain. They want that everyone be thus enabled an opportunity to
|
|
|
|
participate in the fee stream originating from future use of the feature by
|
2015-12-17 10:44:40 +00:00
|
|
|
purchasing shares of a FBA.
|
2015-12-17 09:09:48 +00:00
|
|
|
|
|
|
|
The conundrum is that whoever creates the FBA and offers it to the public as a
|
|
|
|
means of participation in a fee-based income stream faces a risk of coming under
|
|
|
|
regulatory scrutiny if the project is a success (e.g. Satoshi Dice) or even if
|
|
|
|
it is not a success (through some disgruntled investor complaining to a
|
|
|
|
regulatory authority). For a more in depth look in to Regulatory Risk please see
|
|
|
|
[1,2].
|
|
|
|
|
|
|
|
If something falls within the definition of a *security* under applicable law,
|
|
|
|
it will be governed by extensive rules and regulations that can be quite complex
|
|
|
|
and expensive to comply with. And subject the issuer to a large fine/other
|
|
|
|
penalties if not complied with!
|
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Once [BSIP-0008](bsip-0008.md) has been implemented and is available on the
|
2015-12-17 09:09:48 +00:00
|
|
|
blockchain (but not before), it will be possible for future investor and
|
|
|
|
entrepreneurs to create FBAs and crowd fund new features by having a *Private
|
|
|
|
Mode account* ([BSIP-0008](bsip-0008.md)), issue the FBA from an *unknown*
|
|
|
|
jurisdiction that is presumably not subject to securities concerns.
|
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
# Specifications
|
|
|
|
|
|
|
|
Since every innovation on the blockchain level has to come with a protocol
|
2015-12-21 13:26:47 +00:00
|
|
|
upgrade (previsouly denoted as a *hard fork*), the upgrade also comes with a so
|
|
|
|
called *management account* that is specific for this specific innovation or
|
|
|
|
feature. For regulatory reasons, the blockchain itself is seen as the creator of
|
|
|
|
the asset and has the sole permission to issue new shares.
|
2015-12-17 10:44:40 +00:00
|
|
|
|
|
|
|
The initial share holders of the FBA asset have to be defined upon the hard fork
|
|
|
|
by the developers of the feature. It is left to the developers of the innovation
|
|
|
|
to derive a proper scheme to identify the initial share holders.
|
|
|
|
|
|
|
|
Most importantly, the management account will have a Multi-Signature authority
|
|
|
|
assigned to the `X` largest share holders of that account weighted proportional
|
|
|
|
to stake and will have the power to set the fee.
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
# Discussion
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-17 10:44:40 +00:00
|
|
|
Daniel Larimer: I would say that far more than Worker Proposals or anything
|
|
|
|
else, the Fee Backed Assets is incentivizing entrepreneurs to come up with
|
|
|
|
ideas, come up with features and then go and fund them and make it happen.
|
2015-12-16 13:56:42 +00:00
|
|
|
|
2015-12-21 13:26:47 +00:00
|
|
|
This proposal helps fund new features and innovations without the need to dilute
|
|
|
|
BitShares to pay for its developments. However, having the features transaction
|
|
|
|
fees be paid to the holders of the corresponding FBA results in a reduced
|
|
|
|
revenue for BitShares holders, which is only fair since they haven't funded the
|
|
|
|
feature. However, the infrastructure is still provided by BitShares and as such
|
|
|
|
a cut of the features transaction fees may be directed to the BitShares holders
|
|
|
|
by burning or reserving in the reserve funds.
|
|
|
|
|
|
|
|
The developer of a FBA-supported innovation can chose a mixed funding model and
|
|
|
|
make use of a worker to fund parts of the development. As a consequence a
|
|
|
|
higher percentage of the transcaction fees should be directed towards the
|
|
|
|
BitShares holders.
|
|
|
|
|
2015-12-16 11:37:08 +00:00
|
|
|
# Copyright
|
|
|
|
|
|
|
|
This document is placed in the public domain.
|
|
|
|
|
|
|
|
# See Also
|
|
|
|
|
2015-12-17 09:09:48 +00:00
|
|
|
* [1] https://bitsharestalk.org/index.php/topic,20499.msg264752.html#msg264752
|
|
|
|
* [2] http://www.cuttingedgecapital.com/what-is-a-security-and-why-does-it-matter/
|