113 lines
4.8 KiB
Markdown
113 lines
4.8 KiB
Markdown
BSIP: 0008
|
|
Title: Fee Backed Assets
|
|
Authors: Danial Larimer <Dan@cryptonomex.com>
|
|
Stan Larimer <Stan@cryptonomex.com>
|
|
Fabian Schuh <Fabian@BitShares.org>
|
|
Status: Draft
|
|
Type: Protocol
|
|
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).
|
|
|
|
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.
|
|
|
|
# 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.
|
|
|
|
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.)
|
|
|
|
# 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.
|
|
|
|
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-0007](bsip-0007.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.
|
|
|
|
# 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.
|
|
|
|
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!
|
|
|
|
Once the "Privacy Mode" feature 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-0007](bsip-0007.md)), issue the FBA from an *unknown*
|
|
jurisdiction that is presumably not subject to securities concerns.
|
|
|
|
# Management Account
|
|
|
|
A FBA asset (such as the [STEALTH asset](bsip-0007.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.
|
|
|
|
# Copyright
|
|
|
|
This document is placed in the public domain.
|
|
|
|
# See Also
|
|
|
|
* [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/
|