Overall design of fee-backed assets

[theoreticalbts]

In the discussion on #516 @abitmore asked:

If I understand correctly, an asset have to have an issuer/owner? Who will create these accounts if we have tons of FBA in the future?

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:

• (1) There exists a return program which pays to holders of some asset (through buyback)
• (2) System logic including the hardcoded ID of the return program directs certain fees into the return program.
• (3) Actions of the asset's issuer require the consent of some representatives of the current asset holders #491 #516.

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.

[abitmore]

Thanks for clarification. I have questions:

1. Why pay though buyback but not some kind of dividend distribution? I know that buy back is easier to implement, and more efficient to execute (by witness_node) since it don't need to scan all accounts for asset holders. But buyback is not ideal for dividend distribution imo. If I'm a FBA holder, I don't want to take risks to place a sell order on the market to let someone be able to buy my shares before the system do it. It will introduce a chance, before the system place the buy order, everyone know how much the system will buy, an opportunist could buy up enough shares and place a higher sell order instead to make an instant profit.
2. It's ok if creation of the asset issuer account and the asset is done manually, because it should be done before the hard fork, we can review the code to make sure the hard coded ID in (2) is the manually created one. But will (3)(transfer the issuer power) have to be done manually after the hard fork? If so it requires trust. Or it will be done with the hard fork code? Or we'll have 2 hard forks, one hard fork to enable (3)(transfer the issuer power), and after (3) is done manually, another hard fork to start paying?

[theoreticalbts]

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.

[theoreticalbts]

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.

[theoreticalbts]

Leaving this ticket open to remind myself to document all the new features to support FBA's.

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#166