Ability to airdrop/sharedrop/pay dividends of one asset to all holders of another.

[clockworkgr]

As a user/asset issuer I want to have a transfer_asset_to_asset_holders API call so that I can perform airdrops/sharedrops or dividend payouts.

Additional Context (optional)

Case 1: I own asset COOLASSET and decide to airdrop 50% of the total 1000000 COOLASSET supply to holders of BTS. I issue the relevant amount to myself and use transfer_asset_to_asset_holders(500000, 'COOLASSET','BTS')

Case 2: As a gateway operator, I collect market fees on all assets I provide gateway services for. Once a month, I want to share 50% of all market fee profits to holders of my GATEWAYCOIN. So for each gateway asset, I withdraw market fees, calculate 50% profit share (e.g. say 500 GATEWAY.UIA1) and use transfer_asset_to_asset_holders(500,'GATEWAY.UIA1','GATEWAYCOIN')

I believe PBSA has already implemented most of the code needed for this in peerplays.

Referencecs

• BSIP 20 - Introducing profit-sharing/dividends to Bitshares (UIA only)
• Peerplays Profit Share Implementation (link to code needed)

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[clockworkgr]

As a side note, the same code could be called upon to allow airdrops on asset creation time.

So from a UX point of view, the user would set all his UIA parameters just like now and on the supply settings, once a max supply is entered, he can choose a "percentage_to_airdrop" (e.g. 100%), an "airdrop_target_asset" (e.g. BTS) and a future block no for the snapshot (e.g. block 30000000).

Thus creating the asset and planning the airdrop at the same time.

[cogutvalera]

good idea ! nice !

[abitmore]

Interesting. I think there is a BSIP already.

Do it at maintenance interval? Deduct (transfer/issue) fees relative to number of holders?

[clockworkgr]

Yep...a superset of the functionality is mentioned here: https://github.com/bitshares/bsips/blob/master/bsip-0020.md

So change this issue to let's get BSIP-20 done instead :)

Maintenance interval sounds good.. Doesn't seem like an operation that will ever be required to be performed instantly.

Fees based on no of holders sounds good. Although we should probably make a special allowance for/treat core token BTS differently.

[clockworkgr]

@ryanRfox you were part of the original conversation so I'm tagging you here... As you can see there already was a BSIP...I was unaware

[abitmore]

Please be aware that balance look-up impacts performance, as mentioned in #1083 (comment), utilizing more than 7% of total replay time. Balance-modify may impact performance (much) further, as we need to insert 100k objects to object database in a few seconds.

[clockworkgr]

Hence why I checked performance when submitting the issue :)

I really don't know what the impact would be. I hope it's something that can be handled. It can be a high-fee operation if needed, as long as it's possible.

[abitmore]

According to the profiling data, every modification takes around 0.000002 second, so 100K modifications can be done in 0.2 second. However, it's all time average, When we have more and more data, it could be slower and slower. In addition, the profiling data is for replay, which means undo database is disabled. On a live chain, there is big overhead (2x data copy) when doing those modifications.

Update: forgot to mention the data (0.2 second) is with asset_api functionality enabled. With PR #1099 (for issue #1083), block producers (witnesses) can disable asset_api support for better performance (1.7x - 3x speed).

[clockworkgr]

https://github.com/BunkerChainLabsInc/peerplays-profitshare