Closed theoreticalbts closed 7 years ago
Thanks for clarification. I have questions:
Why pay though buyback but not some kind of dividend distribution?
Because buyback is easier to implement. I have an idea for another way to do dividend distribution, but it's still under discussion internally and will likely be out-of-scope for this worker proposal.
But will (3)(transfer the issuer power) have to be done manually after the hard fork? If so it requires trust...Or we'll have 2 hard forks...
This is a cogent point. We need to add an assertion that the issuer of the buyback asset has a special authority on the asset itself (and possibly certain permission bits clear); the alternative is allowing us to manually check the assertion and withhold the second hardfork if the assertion fails because the sponsor didn't set things up properly. The net consequence is that the operations funding the FBA are effectively disabled unless / until the sponsor sets up the account correctly.
I've put together some documentation on what the process is for creating a new FBA: https://github.com/cryptonomex/graphene/wiki/Creating-a-new-FBA
This isn't really a comprehensive user's guide to FBA's, it's more an internal checklist of steps someone needs to do in the wallet in order to launch an FBA.
Leaving this ticket open to remind myself to document all the new features to support FBA's.
This issue was moved to bitshares/bitshares-core#166
In the discussion on #516 @abitmore asked:
I started to answer this question in the ticket, but realized that it's off-topic, lengthy, and high-level enough to justify its own ticket.
An FBA has these properties:
Tickets #491 and #516 are about creating a more general way to allow any account to change its authority to the representatives of the holders of some asset. #491 implements representatives by voting, but work was abandoned because it's out of spec; we'd need resources not included in the original spec to build a UI for it.
I've designed (1) and (3) to be general primitives that anyone can use to do distribution (1) and decentralized governance (3), the only part which requires system-level authority is directing the disposal of certain fees (2).
So to answer the original question, creation of an issuer account, asset, and initial distribution of FBA is done "manually" (or with scripting / API if sufficiently complicated) by the FBA sponsor. Then create a return program object (1) which is the channel through which value will flow to the FBA holders. The existing asset permission flags system and the decentralized governance system (3) allow the sponsor to transfer the issuer powers to the holders of the asset.
Anyone can do the steps outlined in the previous paragraph, but the step implementing part (2) requires a hardfork (i.e. all nodes must consent by upgrading to the new version): Direct the value generated by fees into the return program object.