[BSIP 0007] More descriptive text to make it easier to read
Fabian Schuh
parent
a93c316b70
commit
a0240945ca
102
bsip-0007.md
102
bsip-0007.md
|
|
@ -4,77 +4,79 @@
|
|||
Stan Larimer <Stan@cryptonomex.com>
|
||||
Fabian Schuh <Fabian@BitShares.org>
|
||||
Status: Draft
|
||||
Type: Protocol
|
||||
Type: Informational
|
||||
Created: 2015-12-16
|
||||
Discussion: <https://bitsharestalk.org/index.php/topic,20286.0.html>
|
||||
Worker: not applicable
|
||||
|
||||
# Abstract
|
||||
|
||||
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).
|
||||
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)*.
|
||||
|
||||
Hence we propose to develop a feature for *Market based innovation*: if people
|
||||
can profit from successful features in the form of fees then it definitely helps
|
||||
BitShares become more adaptable over time. More importantly it promotes
|
||||
innovation.
|
||||
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.
|
||||
|
||||
# Motivation
|
||||
|
||||
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.
|
||||
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?
|
||||
|
||||
She naturally starts out as the owner of those revenue producing assets.
|
||||
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.
|
||||
|
||||
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
|
||||
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.)
|
||||
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.)
|
||||
|
||||
# Examples
|
||||
|
||||
## Taxi Rental
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The TAXI FPA could represent all available minutes on a network-owned fleet of
|
||||
The `TAXI` 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.
|
||||
|
||||
## Project/Feature Funding
|
||||
|
||||
In the case of [BSIP-0008](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.
|
||||
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.
|
||||
|
||||
# Regulatory issues
|
||||
|
||||
Much consultation with Cryptonomex and with several prominent and trusted
|
||||
members of the BitShares community has lead me to some preliminary conclusions
|
||||
as to how a "Privacy Mode" feature could best be implemented and used in a
|
||||
safe and timely fashion and at no risk to the BitShares Community.
|
||||
|
||||
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
|
||||
that an FBA (fee based asset) be created to fund this feature upgrade to the
|
||||
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
|
||||
purchasing shares of a `STEALTH` asset.
|
||||
purchasing shares of a FBA.
|
||||
|
||||
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
|
||||
|
|
@ -88,23 +90,33 @@ 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!
|
||||
|
||||
Once the "Privacy Mode" feature has been implemented and is available on the
|
||||
Once [BSIP-0008](bsip-0008.md) has been implemented and is available on the
|
||||
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.
|
||||
|
||||
# Management Account
|
||||
# Specifications
|
||||
|
||||
A FBA asset (such as the [STEALTH asset](bsip-0008.md)) will be issued by a
|
||||
"management account" for that particular feature as part of a hard fork. The
|
||||
initial share holders of the FBA asset have to be defined upon the hard fork.
|
||||
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.
|
||||
Since every innovation on the blockchain level has to come with a protocol
|
||||
upgrade (previsouly denoted as a *hard fork*), this upgrade can also come with a
|
||||
so called *management account* that is specific for this specific innovation or
|
||||
feature. An FBA's asset (such as the [STEALTH asset](bsip-0008.md)) can only be
|
||||
issued by this "management account" and only for that particular feature.
|
||||
|
||||
All FBA require a protocol upgrade (read: hard fork) to create the management
|
||||
account.
|
||||
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.
|
||||
|
||||
# Discussion
|
||||
|
||||
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.
|
||||
|
||||
# Copyright
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue