Profit Sharing - supplement

[fractalnode]

I would like to supplement the existing Profit Sharing proposal #1172 with this use case.

User Story

let's assume I'm one of the leaders in a certain community. Leaders in various events issue different types of tokens (e.g. such as {living example →} BROWNIE.PTS, STEALTH, VIRGROW, SHAREBITS, ... ) and allocate them to different users according to certain criteria.
Let's assume that after a year of community existence I would like to pay certain users bonuses for their activity. This activity is reflected in the number and type of tokens held within the community. For this reason I want to send :

• 50% token A (e.g. bitUSD or any other private UIA), to users who have token B (pro-rata)
• 30% token A, to users who have token C, for less than 60 days
• 20% token A, to users who have token D, for more than 365 days

**Additional Context **

We have a platform for creating tokens and we can create a lot of types of tokens.
Let's imagine that suddenly users want to create their own tokens - they do it because they can, but what can they do with them in the GUI now?
They can send or issue a token to one account at a time.
(I am aware that larger organizations can code more activities themselves)

It seems to me that this is not enough, and the first two things I miss are:

1. Profit sharing (pro-rata), the community sees this need, that's why we've had BSIP (19 & 20 & Ability to airdrop/sharedrop/pay dividends of one asset to all holders of another. #1172) for it.

2. Sending tokens to many recipients, e.g. in the form of defined account lists in some files (maybe csv)

UI related
bitshares/bitshares-ui#1249

The name BitShares immediately brings me some associations that ignite my imagination exactly in this kind of use cases. The ICO era (I mean ETH in 2017) would be different if we had such abilities from the beginning, but it's not over yet and better late than never. Let's create Token Studio

Impacts

• maybe a new token predicate is need it associated with its maturity
• API (the application programming interface)
• CLI (the command line wallet)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• UX (the User Experience)

[pmconrad]

2. Sending tokens to many recipients,

It is already possible to bundle multiple transfers into a single transaction. It is also quite simple for someone with a little programming skill, using either one of the available client libraries or using cli_wallet API endpoints.

1. Profit sharing (pro-rata),

As your example shows, the rules for profit-sharing can be very flexible and are highly dependent on the particular use-case. It makes no sense to implement a profit-sharing framework in the core that could be configured to any imaginable use-case.

What could be done is to provide a plugin that keeps track of certain statistics that could be helpful in profit-sharing. For example, keep track of "coin-age", or dump all holders of an asset. I think this was also discussed elsewhere.