Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
6 tasks
clockworkgr opened this issue Jul 22, 2018 · 13 comments
Open
6 tasks
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 UX Impact flag identifying the User Interface (UX)

Comments

@clockworkgr
Copy link
Member

clockworkgr commented Jul 22, 2018

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

CORE TEAM TASK LIST

  • Evaluate / Prioritize Feature Request
  • Refine User Stories / Requirements
  • Define Test Cases
  • Design / Develop Solution
  • Perform QA/Testing
  • Update Documentation
@clockworkgr
Copy link
Member Author

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
Copy link
Member

good idea ! nice !

@abitmore
Copy link
Member

Interesting. I think there is a BSIP already.

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

@clockworkgr
Copy link
Member Author

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
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

abitmore commented Jul 22, 2018

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
Copy link
Member Author

@ryanRfox ryanRfox added 1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 UX Impact flag identifying the User Interface (UX) labels Jul 24, 2018
@ryanRfox
Copy link
Contributor

Currently BSIP 20 (UIA) and BSIP 19 (MPA) are Deferred. @xeroc may I request you to remind us of the conclusion at that time?

@clockworkgr
Copy link
Member Author

I'm guessing deferred as in to be discussed again later...does now fit the definition of later? :D

@clockworkgr
Copy link
Member Author

Bumping this. @xeroc / @ryanRfox ?

Had this request in UI too: bitshares/bitshares-ui#2458

@pmconrad
Copy link
Contributor

Related: bitshares/bsips#132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2a Discussion Needed Prompt for team to discuss at next stand up. 3b Feature Classification indicating the addition of novel functionality to the design 6 API Impact flag identifying the application programing interface (API) 6 CLI Impact flag identifying the command line interface (CLI) wallet application 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 Protocol Impact flag identifying the blockchain logic, consensus, validation, etc. 6 UX Impact flag identifying the User Interface (UX)
Projects
None yet
Development

No branches or pull requests

5 participants