bitshares / bitshares/bsips

New BSIP: Stop STEALTH FBA fee distribution

Open
#205 23 comments 0 reactions 0 assignees View on GitHub
governance / voting profitability / fees
Dominant language
No language data
Stars
59
Forks
86
PR merge metrics
No merged PRs in 30d

Description

# Brief

This BSIP seeks for interest alignment between BTS token holders and STEALTH token holders, for a more integrated community and better growth of BitShares.

This BSIP seeks for an agreement between BTS token holders and STEALTH token holders, but not a decision made by BTS token holders only.

# Motivation

When [BSIP 8: Privacy (STEALTH) Mode](https://github.com/bitshares/bsips/blob/master/bsip-0008.md) was accepted, the BitShares community expected that STEALTH token holders would make use of *privacy (stealth) mode* to attract new users and generate more revenue for the BitShares network thus would add value to the core token of BitShares (BTS) to an extent.

However, it seems the expected benefit didn't happen (data to be added), on the contrary, BSIP 8 actually divided the community and may have negatively impacted the growth of the whole BitShares ecosystem.

According to BSIP 8, A GUI "to allow ordinary users to easily use the Privacy Mode features" is expected to be delivered by STEALTH token holders. But they failed to deliver it, although it's been more than 3 years.

The initial investor `onceuponatime` paid `45,000` USD to CryptoNomex for developing the GUI, in return, all STEALTH token was allocated to `onceuponatime`, in total `1,000,000` STEALTH. Later on `2016/04/17 00:43:33 UTC` (at block number `5323913`), `onceuponatime` transferred `800,000` STEALTH token back to `dan` whom was in charge of CryptoNomex. It's mentioned somewhere that CryptoNomex or `dan` himself refunded `onceuponatime` due to failed to deliver the GUI, in return, `onceuponatime` sent back the STEALTH token ( `dan` sent `6,000,000 BTS` to `onceuponatime` on `2016-04-17 00:37 (UTC)`, at block number `5,323,792`).

Later, on `2016/06/20 19:08:48 UTC` (at block number `7176146`), a company named *BitShares Munich* acquired `600,000` STEALTH token from `dan`, the company then made some efforts to advance development and marketing of the `privacy (stealth) mode`. However, some months later, the BitShares Munich company ran into issues and effectively became inoperational.

Now, whenever some BTS token holders suggest to use the reserve fund to develop features related to *privacy (stealth) mode* or to market it, some other BTS token holders argue that it's the STEALTH token holders' responsibility to do so because 80% of fees generated by *privacy (stealth) mode* will go to STEALTH token holders. The interest is not aligned.

# Rationale

The solution proposed in this BSIP:
* Stop distributing stealth-transfer fees to STEALTH token holders after a specified time,
* as compensation, use an amount of community-owned funds to buy back STEALTH token.

The time and the amount are to be discussed / decided by the community.

After this is done, the BTS token holders would feel more engaged when working for and investing into *privacy (stealth) mode*.

# Specification

TBD

# See also

* The first worker proposal for stealth https://bitsharestalk.org/index.php/topic,20104.0.html
* The updated worker proposal for stealth (with FBA) https://bitsharestalk.org/index.php?topic=20205.0
* STEALTH Status Update (FBA installed) https://bitsharestalk.org/index.php?topic=22138.0
* The *BitShares Munich* issues
* https://steemit.com/news/@kencode/chris4210-where-are-you
* https://steemit.com/bitshares-munich/@onceuponatime/so-what-s-been-going-on-in-bitshares-munich-part-1

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading BSIP 8 and the linked stealth worker proposals and status update to understand the existing fee-distribution arrangement. The issue's Specification is TBD, so the work is not ready until the community agrees on the timing and buyback amount and the proposal records those decisions.

Written by the indexing model from the issue text.

Assessment

Tech stack
blockchain
Domain
blockchain, documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.