BSIP-84: Token-based voting #242
Conversation
|
|
||
| BTS balances are affected by almost every operation, due to transaction fees. The voting tokens will only be affected when they are being used. | ||
|
|
||
| BTS is used in a multitude of ways, e. g. as collateral, as the counterpart in most active markets, as payment for workers and witnesses, as cashback for fees and so on. Contrarily, it is assumed that the primary purpose of the voting tokens will be voting. They are unlikely to be used as collateral. |
There was a problem hiding this comment.
Contrarily, it is assumed that the primary purpose of the voting tokens will be voting. They are unlikely to be used as collateral.
Personally I won't assume this, but the opposite.
There was a problem hiding this comment.
Hm, interesting. Anything specific you have in mind?
IMO in order to be used as collateral, a token would need to have some intrinsic value, which I don't see in a voting token.
There was a problem hiding this comment.
A voting token would not have value if it tracks the voting weight of another token well (which is hard), in that case it is a simple utility token carries one role for another token. When we have this BSIP (token-based voting), I'd expect that people would directly vote with the tokens they already have but not create new tokens only for voting, because it would be economically much cheaper.
This is also the reason that I don't agree with the MANAGER token idea proposed in BSIP83, because the new token can't track the distribution of BTS well in the long run. That idea means to privatize committee-owned smartcoins, which is something similar to STEALTH, and would divide the community.
On the other hand, there would also be use cases that a voting token is needed, e.g. if the voting weights are time-based or derived from another token.
|
|
||
| BTS is used in a multitude of ways, e. g. as collateral, as the counterpart in most active markets, as payment for workers and witnesses, as cashback for fees and so on. Contrarily, it is assumed that the primary purpose of the voting tokens will be voting. They are unlikely to be used as collateral. | ||
|
|
||
| These differences allow for various simplifications and optimizations. In particular, we propose to allow only liquid balances for voting. Because these presumably change rarely in comparison to the number of distinct balances, it is more efficient to recalculate votes on the fly instead of once per maintenance interval (see STEEM for comparison). |
There was a problem hiding this comment.
On the other hand, the simplification that only counts liquid balances does limit the potential of the feature. There could be use cases that require tokens in other forms to be counted in voting as well. I do agree to implement the simplified version first though.
|
Added some modifications requested in issue #81 comments |
MichelSantos
left a comment
MichelSantos
left a comment
There was a problem hiding this comment.
I conclude that this is technically complete
3 participants
For #81