BSIP-020 Draft - "Introducing profit-sharing/dividends to Bitshares (UIA only)" - Input would be massively appreciated!

in #bitshares7 years ago (edited)

BTS

Hey,

I spoke during the 27th Bitshares hangout regarding this draft BSIP, and I previously wrote up the draft BSIP-019 which is very similar to this BSIP except focusing on market pegged assets (MPAs) instead of UIAs (User Issued Assets).

I would massively appreciate any/all input regarding this BSIP, all comments are welcome!

Shout out to @OfficialFuzzy for continuing to support the #Bitshares community and for inspiring me to take action in writing up this BSIP!

Thanks for taking the time to read this BSIP, long live Bitshares! :D

Best regards,
@CM-Steem


BSIP: #020
Title: Introducing profit-sharing/dividends to Bitshares (UIA only)
Authors: Customminer
Status: Draft
Type: Protocol
Created: 2017-06-26
Primary Discussion: https://bitsharestalk.org/index.php/topic,23981.0.html
Similar Discussions: 
Replaces: N/A
Superseded-By: N/A
Worker: No worker proposal yet - propose bounty?

Abstract

The introduction of 'profit sharing / dividends' for User Issed Assets (UIA) on the Bitshares DEX


Motivation

  • One of the major selling/marketing points of BTSX (for myself) back in 2014 was the 5% (really variable 'x' %) on 'anything' marketing. The idea that anyone could securely hold assets long term within their Bitshares wallet and potentially receive better 'interest' rates than that which FIAT banks were offering was (and remains) a powerful message. Whilst this previously applied solely to market pegged assets (MPA - bitUSD, bitCNY, bitEUR, etc), I believe that the same concepts could be extended to UIA.
  • Increasing the profitability of the BTS DEX.
  • Encouraging users to hold assets on the BTS DEX over centralized exchanges.

Rational

  • New UIAs may be created on the BTS DEX to take advantage of this functionality, driving additional fees to the reserve pool upon registration of said assets.
  • Improving the ease of performing sharedrops of UIA against BTS/MPA/UIA asset holders will likely increase the frequency of sharedrops being performed on the BTS DEX.
  • UIA sharedrops should be considered an incentive for users to hold their assets on the BTS DEX instead of on centralized exchanges, helping prevent exchanges from having a massive BTS vote weight.
  • Alternative cryptocurrencies could plausibly migrate their token distribution onto the BTS DEX to avoid maintaining their own proof-of-stake (POS) blockchain as a form of disaster recovery whilst maintaining the ability to provide interest equivelant to their prior POS blockchain.
  • Other cryptocurrency platforms offer profit-sharing/dividends functionality, such as Peerplays/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash.
  • Most (if not all) Bitcoin forks (1000's of them) have 'sendmany' functionality which enables the mass distribution of their tokens against a large quantity of users (addresses) in a single transaction; this is currently not possible within the BTS DEX (unless I'm mistaken?).

Specifications

Implementation of peerplays profit sharing mechanism for UIA

  • The Peerplays developement team developed profit-sharing code for the Graphene toolkit approximately one year ago, they have repeatedley given permission for the BTS DEX to utilise their developed profit-sharing code (case 1, case 2). A large portion of the work required for this BSIP may already be complete.

UIA Profit-Sharing/Dividend distribution methods

  • Profit-Sharing/Dividends via market fee redistribution (only if the UIA has implemented its own market fees).
  • Sharedropping additionally issued UIA tokens against UIA holders (self/other UIA).
  • Initial sharedrop distribution of new UIA against holders of any asset on the BTS DEX (sharedrop UIA-A against BTS/UIA-B/MPA holders).

Whitelist/Blacklist options

  • An optional whitelist (configurable by the UIA Issuer) could provide increased control over who is eligible to earn dividends on their UIA holdings.
  • An optional blacklist (configurable by the UIA issuer) could prevent exchanges/services from earning dividends/interest on UIA (incentivizing holding UIA on the BTS DEX over centralized exchanges).

Minimum UIA holdings for dividend eligibility

  • Users with very small UIA holdings may be eligible for dividends less than the UIA is configured for (less than the max decimal places), providing the UIA issuer the ability to set the minimum quantity of UIA to be eligible to earn dividends could counteract such an issue.
  • Increasing the minimum UIA holdings for dividend eligibility could decrease the network fees required to perform the distribution (less recipients, less fees).

UIA issuer set interest rates & target assets

  • Enable the UIA issuer to select one (or many) assets on the BTS DEX which would be eligible to receive a sharedrop allocation.
  • UIA issuer set % for each selected asset.
  • Enforce minimum interest rates to prevent creating dust (tiny transactions) or the allocation of dividends less than the UIA's max decimal places.
  • Enforce maximum interest rates to prevent attempting to issue more tokens than the max coinsupply.

Minimum UIA coin-age for dividend eligibility

  • To prevent users from only holding UIA during the dividend/sharedrop (buying shortly beforehand and selling immediately afterwards), we aught to provide the UIA issuer the ability to take the 'coin-age' of UIA holdings into account.
  • Providing the UIA issuer the ability to set a custom coin-age requirement for sharedrop allocation could provide incentives to hold assets on the BTS DEX long term.

Discussion

How is this different from BSIP-0019?

  • BSIP-0019 proposes the implementation of 'profit sharing / dividends' for MPAs, where as this BSIP references User Issued Assets (UIA).
  • BSIP-0019 redistributes network fees (% taken from referral system), where as this BSIP proposes profit-sharing via the redistribution of market fees and/or the sharedropping of additionally issued UIA.
  • BSIP-0019 requires the comittee to configure profit-sharing for MPA, where as this BSIP requires the UIA issuer to configure the profit-sharing settings for said UIA.

BSIP-020's resistance to 'yield-harvesting'

A quote from the 'Socialized yield is broken' blog post:

"Under BitShares the BitAsset holders receive a yield simply by holding BitUSD. This yield was between 1% and 5% APR on average. Unfortunately, yield harvesting can happen at any time by someone shorting to themselves to gain a very low risk return and undermining goal of encouraging people to buy and hold BitUSD. The yield was funded from transaction fees and by interest paid by shorts."

  • Rather than paying profit to shorters on demand, this BSIP proposes scheduled dividends against asset holders on the BTS DEX. Thus BSIP-020 shouldn't be vulnerable to the 'yield-harvesting' issue that was prevalent within 'Socialized Yield' unless the UIA is configured improperly by the UIA issuer.

Potentially inappropriate for Exchange Backed Assets (EBA)

  • Tokens such as OPEN.GRC which are UIA representative of real backed Gridcoins held by Openledger would not be eligible for dividends due to the fact that these tokens are backed by real cryptocurrency and do not operate a fractional reserve.
  • If the EBA provider was to purchase additional backing cryptocurrency to then distribute legitimately onto users then this would be possible, this is however highly unlikely to occur.

BTS DEX sharedrop spam?

  • A potential negative impact that BSIP-020 could have upon the BTS DEX is that there may be a large influx of users sharedropping worthless/troll tokens onto asset holders.
  • To deter this behaviour, the sharedropping of UIA-A (your example UIA) against UIA-B (my example UIA) should have a larger network fee than issuing a sharedrop of UIA-A against UIA-A holders. Likewise, sharedropping an UIA against MPA holders should

Maximum coinsupply/inflation abuse

  • If an user creates an initial coin supply of 99999999999 (current max) then attempts to issue additional tokens through newly introduced functionality, we'll need to reinforce the maximum coin supply.
  • If an user creates an UIA with a coin supply less than max but with an interest rate which would attempt to drive the coin supply greater than the maximum possibly supply we'll need to reinforce the maximum coin supply.
  • Increasing the maximum coin supply limit wouldn't solve the above problems.

Max decimal places

  • If an user holds a tiny amount of an UIA and the inflation rate is very low, then the user may be eligible for a payment lower than the max decimal places (ie 4 decimal places & 0.00001 UIA token payment). We should reinforce these maximum decimal places during dividend issuance, potentially enforcing minimum UIA holdings and minimum interest rates.

Incentivizing market making

  • We could potentially sharedrop UIA against market makers based on network statistics such as filled orders (participants & amount) or MPA collateral/debt positions.
  • Incentivizing market makers wouldn't be vulnerable to the 'yield-harvesting' that plagued 'socialized-yield', rather we may see users fake volume on illiquid trading pairs in an attempt to inflate their sharedrop allocation. To avoid this, UIA issuers performing such a market-maker sharedrop should target trading pairs with high liquidity (ultimately up to their discretion).

Automation once configured?

If an UIA is configured to inflate and distribute said newly issued tokens against holders of asset 'x' on the BTS DEX, then the UIA owner was set to either null or the committee then this would increase decentralization of said token in a manner similar to POS cryptocurrency issuance (no centralized issuer). This would potentially run into issues regarding network spam and max coinsupply/inflation abuse so perhaps it'd be worth keeping manual..

Further research

  • Who can perform this work?
  • 3rd party scripts for determining sharedrop allocation modifiers?

Summary for Shareholders

  • No worker proposal has been created yet, input from coders regarding the cost is neccessary.
  • No proposed change to current network fees.
  • UIA changes are in scope of this BSIP, not MPA.

Copyright

Peerplays created the profit-sharing functionality w/ MIT license:


See Also

BSIP-0019

Sort:  

How do I vote for this proposal?

Following u ..waiting for ur new post man ...

It's not yet a worker proposal (see the 'summary for shareholders' section), it still requires further refinement/discussion and an evaluation of feasibility prior to finding a developer capable of the work then creating a worker proposal.

Some points:

  • Yield harvesting cannot occur here because nobody can simply short a UIA into existence.
  • The problems of EBAs and max coin supply can be covered simply by requiring the dividends to exist before they are paid out.
  • The problem of decimal places does not exist, due to the way amounts are handled internally. Payouts are always rounded (down) according to the number of decimals configured for the asset. Micro-payouts are rounded to zero.
  • KISS. Coin-age and market-making incentives require statistics that we (currently) don't have, so you should leave them out of the proposal.

Do you imagine the determination of coin-age to be problematic either due to implementation and/or computationally expensive by node software?

I spent a couple hours last night writing up a BSIP on coin-age, how we go about calculating it and how the dividend system works factor in, some brief thoughts:

  • Should dividends be paid on holding assets for part of a sharedrop period (10 days of 30 days) without holding the asset at the exact moment of sharedrop?
    • If not: We could query the holders of said asset at the moment of dividend issuance (existing functionality), then calculate the coin-age for each lump of assets (individual transactions) by performing the calculation 'current_time - inbound_transaction_time'.
      • This would require additional functionality to retrieve the list of 'inbound_transaction_time' or simply the transaction id (so as to then retrieve the inbound transaction time with existing functionality) for each transaction that makes up an user's immediate asset holdings.
    • If so: we would need to evaluate the historical holders of an asset, which may involve looking back overall transaction history (filtering for chosen asset) then evaluating the coin-age accumulated; this would be computationally expensive as this may involve a serious quantity of transactions to process in the future (potentially also open to abuse if I was to spam an asset between two accounts to increase time to compute coin-age).

The problems of EBAs and max coin supply can be covered simply by requiring the dividends to exist before they are paid out.

Good point, I could add this as a per-requisite to the distribution of a dividend.

The problem of decimal places does not exist, due to the way amounts are handled internally. Payouts are always rounded (down) according to the number of decimals configured for the asset. Micro-payouts are rounded to zero.

That's good to know, so think it's safe to entirely remove the sections regarding the decimal places?

Coin-age and market-making incentives require statistics that we (currently) don't have, so you should leave them out of the proposal.

I agree regarding market-making incentives (because it's largely a last minute addition & just a topic of discussion rather than a core proposal), however coin-age is featured in both BSIP-019 and this BSIP, without it how would we prevent users from buying immediately before the scheduled dividend then selling immediately after?

Would you propose that I create an additional BSIP specifically for tracking the 'coin-age' of BTS assets then reference said BSIP from within these two BSIPs?


Edit: Ok, writing up a draft coin-age BSIP since it's referenced by two BSIPs thus far.

Double edit: Perhaps an alternative idea to coin-age could be taking a random date within the time period set for the snapshot, then performing the sharedrop at a later date so as to encourage holding the assets throughout the month, though you could potentially hold the assets for the majority of the month and not be eligible for a dividend because you missed the snapshot..

If coin-age is essential to both, and avoids the gaming/timing problem, then it would seem to merit its adoption. Although it is possible that its technical implementation might either be tricky and/or computationally expensive. However, it merits its own elaboration.

without it how would we prevent users from buying immediately before the scheduled dividend then selling immediately after?

I wouldn't even try to prevent that. Happens all the time in traditional stock markets. A well-functioning market will take the sharedrop into account during price discovery.

It'd be great to offer the option though, since we want long term asset holders (at least for MPA) and we want to discourage 'yield-harvesting' that similarly troubled 'socialized-yield'.

Excellent discussion of the topic

Regarding the following:

"* Tokens such as OPEN.GRC which are UIA representative of real backed Gridcoins held by Openledger would not be eligible for dividends due to the fact that these tokens are backed by real cryptocurrency and do not operate a fractional reserve."

Can you clarify the significance of the fractional reserve on the reason for an EBA not being eligible?

Also, how might the code distinguish between an EBA versus another UIA?

Can you clarify the significance of the fractional reserve on the reason for an EBA not being eligible?

Sure, so the guarantee/promise that Exchange Backed Assets (EBA - such as OPEN.GRC) provide the Bitshares DEX is that behind each individual OPEN.GRC token, there is a real Gridcoin token that an user has deposited onto the BTS DEX via the Openledger gateway.

If OpenLedger was to issue additional OPEN.GRC tokens without real backing Gridcoin, then they would be operating a fractional reserve (OPEN.GRC would decrease in value less than 1 GRC per token). Openledger does not operate a fractional reserve, where as centralized exchanges potentially do.

How OPEN.GRC could be eligible for dividends:

  • Openledger could place an additional market fee (on top of their current fees) and redistribute a portion of these fees onto OPEN.GRC holders (much like they do for their OBITs holders).
  • A 3rd party UIA is sharedropped against OPEN.GRC holders.
  • Openledger buys real gridcoins, deposits them onto the BTS DEX as OPEN.GRC then sharedrops them against OPEN.GRC holders (unlikely).

Also, how might the code distinguish between an EBA versus another UIA?

The code wouldn't, it's more of a theoretical/political ineligibility than a technical limitation.

Love your work, very good post, I just made a post about how i think the best things in life are free. It has not done the best and i thought it was very good. if any 1 could check it out that would mean the world ;)

Love your work

and ideas on the BitShares platform man! I hope your ideas get looked at and incorporated into the platform by the developers.

Supporting your work fully 😎

Thanks buddy :)

I love the idea of holding UIA on decentralized BTS DEX instead of centralized exchanges because I hold some of my tokens on centralized exchanges. Now the part that speaks about how to deter investors from buying shortly before the dividend payout and selling after without this affecting the price of the tokens is what I am trying to grasp.

Now the part that speaks about how to deter investors from buying shortly before the dividend payout and selling after without this affecting the price of the tokens is what I am trying to grasp.

Let's assume that the dividend sharedrop for an example UIA was always scheduled for the 24th of each month.

If 'coin-age' (how long the UIA has been in your BTS wallet) was not taken into account, I could buy the token on the 23rd, receive the dividend on the 24th then sell it on the 25th. We would see large buy pressure immediately prior then a large sell-off afterwards, which potentially isn't healthy for the token.

We have seen this kind of behaviour in the past with sharedrops against Protoshares and Bitshares, heck Peerplays kept the sharedrop date against BTS secret & only issued a range of dates in which the sharedrop may take place as to avoid disrupting the BTS marketcap.

Grasped the optional need for coin-age now? If not, ask away :)

Okay, I totally grasp the coin-age now. This definitely will reduce short term profits because it takes into account the amount of time the coin has been in a person's BTS wallet. I believe this is even better than the secret dates because it will encourage long term holding of the tokens in the wallet. Cool!!!

Thanks for your work on this. Hoping we can get something like it added to the BTS platform.

Thanks, as am I :)

Love the idea and look forward to what comes about!

Thanks for sharing. I'm waiting for my money to be clear to buy some Bitshares.

It would greatly enhance the platform. Get someone to implement I asap!

Thanks, for the update.

good article, thanks for sharing.

Bitshares has increased fifty times since the beginning of the year, but I am a little worried about the recent decline...
bitshare.JPG

I'm not. Big things are coming for Bitshares in the near future.

The potential is great... Thanks for sharing

🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌😄😄😄😄😄😄😄😄😄😄😄😄😄😄😄😄😄😄🤔👏👏👏👏👏👏👏👏👏👏👏👏👏👏

Thank you so much for sharing this amazing information

Very Informative ! Thanks #!
It will definitely be very prominent for future fruitful Outcomes !!

I like your post is still like this