New BSIP: voting with non-core asset, and asset-specific committee

[abitmore]

Currently only CORE can vote for certain things E.G. witnesses, workers and the committee.

It's been demanded by the community for a long time that, holders of other assets can vote with their assets, for things related to those assets.

Another thing is asset-specific committee. Currently it's able to set committee of an asset to top-N holders. I think it would be useful if the committee can be decided by voting.

Update: Example of asset-specific committee with top-N holders: https://cryptofresh.com/u/stealth-mgmt

[ebit116]

support. DAC need this.

[bangzi1001]

Support! Very useful and very powerful feature.

[xeroc]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

[abitmore]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

Sure. There are fees related to balance the situation.

[abitmore]

Just think out loud: it's possible that the blockchain charge a maintenance fee from the asset's fee pool for every vote re-tallying, and the fee can be related to quantity of holders of the asset. If no enough BTS in the fee pool, deactivate voting feature for the asset, can even deduct some BTS from fee pool in this case for the efforts done. To be fair, the asset committee can decide when to re-tally votes, but not re-tally at every maintenance interval.

[shulthz]

maybe we need set a threshold for the DAC to open this function.

[TheTaconator]

Is the idea to permit bitCNY holders to be permitted to vote on what? The market fee for bitCNY?

If they are permitted to vote on witnesses, workers, and committee, how should the their holdings be valued relative to BTS stake held by others?

Does the idea permit holders of GATEWAY.BTC be permitted to vote on witnesses, workers, and committee?

[abitmore]

Witnesses, workers, and committee, global fee schedule and etc are CORE token's business, not others'.

This proposal is about UIA business. For example, OBITS holders may like to vote for the percentage market fee rate on OPEN.X assets.

[grctest]

I like the idea - could encourage UIA usage more 👍

[sschiessl-bcp]

This would come in handy with allowing users (for a hefty fee) to create accounts that have dynamic permissions like committee, but linked to an UIA. Thoughts?

[thontron]

This is a good way to make businesses more autonomous/limit trust in single party.

We should identify the resource costs and if a fee can offer value for both businesses and stakeholders.

[cloud-8]

So holders of a UIA could vote on the UIAs fees? UIAs have fees set by the issuer for a reason, often to pay for underlying infrastructure and now the control of this will not be with the issuer anymore. Voters have an incentive to always vote to set fees to 0 and yet that may not be viable for an issuer to support anymore. Dont agree with that at all.

[pmconrad]

So holders of a UIA could vote on the UIAs fees?

Not necessarily. The UIA issuer and the account controlled by UIA holders need not be identical.

[thontron]

So there is understandably some confusion about what specific authorities would be granted in a dynamic permission account. To me the value-add comes from allowing holders of a token to vote on transfers from a main account. E.g. holders of X token could elect to transfer BTS/gateway asset from X account to another.

[thontron]

Would that be feasible computationally? It needs to go through all the holders of different assets and accumulate the respective stake.

Is the resource demand significant here? It would be good to have many dynamic permission accounts operating at a given time.

To minimize resource demand, how about limiting the potential account balances through white-listing?

[cloud-8]

So there is understandably some confusion about what specific authorities would be granted in a dynamic permission account. To me the value-add comes from allowing holders of a token to vote on transfers from a main account. E.g. holders of X token could elect to transfer BTS/gateway asset from X account to another.

So holders of a token can vote to remove assets from the ownership of another account holder? This seems very dangerous and I dont see the practical use cases for such a setup. I havent seen any gateway actually demanding this and actually it would be to detriment to the gateway, they dont want users of their assets setting fees and such or theyd go out of business, the whole point of a gateway asset is that the solvency/security of the gateway is taken into consideration when pricing the asset.

[sschiessl-bcp]

Two factors

1. Asset owner The asset owner can have dynamic permissions (multi-sig) like the committee-account (by vote) or like the stealth-account (directly by stake). The asset ownership would allow governance of the asset in all aspects just like any normal user would be able to now

2. Voting of asset holders This new asset would receive it's own mechanism to conduct votes. This is possible in two ways: Opinion vote (say yes or no to a strategic decision) and Worker Proposal (instead of payout out from refund pool, the worker proposal would issue said UIA to the worker account).

On 1. Could be restricted in whatever way the initial asset owners decide (there likely must be a central ownership first, distribute initial amounts of tokens and then upgrade the asset to being self-governed, this way also existing UIA could be upgraded). So the discussion of what or what not should be possible is not necessary in here, as everything can be decided by whoever creates the asset (full flexibility). On 2. This mimics essentially the governance system that BTS already has, just with a separate section for this UIA

[pmconrad]

First draft below. @ryanRfox please assign a number.

---

BSIP: 
Title: Elections based on non-core asset
Authors: Peter Conrad
Status: Draft
Type: Protocol
Created: 2019-10-12
Discussion: https://github.com/bitshares/bsips/issues/81

Abstract

From the beginning, the BitShares blockchain has offered the ability to vote with the core token, and to have elected accounts govern the blockchain.

For specific use-cases it can be desirable to have a similar mechanism for voting and elections where the votes are counted in relation not to BTS but to some other asset. An example might be a community of people who are interested in a specific topic.

This BSIP proposes changes that will enable elections based on dedicated assets.

Motivation

The feature has been requested from independent businesses as well as from within the community. In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance.

Rationale

There are fundamental differences between the mechanics proposed here and the mechanics already in place for BTS-based voting.

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.

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).

Furthermore, we make no distinction between voting and elections. Voting (as in making a yes/no decision) can be emulated with an election where only the votes for two designated candidates are counted and compared to each other. Depending on voting rules (to be defined externally on a case-by-case basis), the one with more votes wins, or perhaps the one with an absolute majority of eligible votes.

Specifications

1. New asset flag "voting_allowed"

A new asset flag/permission "voting_allowed" will be introduced. At the time of the hardfork, all existing UIAs will have the corresponding permission set. Future assets can have the permission set only if they are UIAs not MPAs nor PMs.

As usual with flags, the flag can be changed only if the permission is set. The permission can be unset any time, but can be set only when supply is zero.

The flag must not be used before the time of the hardfork.

2. New operation "create_elected_authority"

Note 1: Since the overall computational overhead for this voting mechanism is significant, the height of the fee should reflect this.

Note 2: The new asset flag voting_allowed is only checked for this operation. If the flag is removed from an asset, any existing elected authorities are unaffected.

Fields:

• account_id_type creator - the account to pay the fee, also the only one who can delete the authority
• asset_id_type voting_asset - the asset on which to base the voting
• unsigned_int num_members - the number of authority members to vote on if fixed, or 0 otherwise
• unsigned_int min_members - the minimum number of authority members to elect, or 0 if fixed
• unsigned_int max_members - the maximum number of authority members that can be elected, or 0 if fixed
• flat_set<account_id_type> candidates - a list of candidates eligible for voting, or empty
• optional<asset_id_type> candidate_holders - and asset that candidates must hold to be eligible for voting
• bool proxy_allowed - indicates if proxy voting is allowed
• optional<time_point_sec> vote_until - an optional ending date after which voting slates are frozen

Validation:

The operation must not be used before the time of the hardfork.

• creator must exist, must have lifetime membership, and must have sufficient balance to pay the fee.
• voting_asset must exist and must have the voting_allowed flag set.
• If num_members is 0 then min_members and max_members must both be positive.
• If num_members is positive then both min_members and max_members must equal 0.
• If candidates is not empty then
  • Its size must be greater or equal to max(num_members,min_members).
  • candidate_holders must not be present.
• If candidate_holders is present the candidates must be empty.
• vote_until, if present, must be in the future

Evaluation:

A new object type elected_authority_object is introduced. The operation creates such an object using the fields from the operation.

A new, empty authority is created. The desired number of members for the authority is set to max(num_members,min_members).

Half of the operation fee is set aside and stored in the elected_authority_object.

3. New operation "delete_elected_authority"

Fields:

• account_id_type owner - the account to pay the fee, must have created the authority
• elected_authority_id_type authority - the authority to delete

Validation:

The operation must not be used before the time of the hardfork.

• authority must exist.
• owner == authority.creator

Evaluation:

• The fee stored in authority is returned to owner.
• The elected_authority_object is deleted.
• All related objects, including the authority as well as all user votes, are also deleted.

Note: Afterwards, accounts that have the authority still referenced in its owner authority will be unable to ever change their owner again. Accounts that have the authority referenced in their active authority will be usable only by their owner authority until the active authority has been changed.

4. New operation "update_asset_vote"

Fields:

• account_id_type voter - the voting account, also pays fee
• elected_authority_id_type authority - the authority on which to vote
• unsigned_int number - the number of members the authority should have, or 0 if it is fixed
• flat_set<account_id_type> votes_to_add - a list of accounts to add to the current voting slate
• flat_set<account_id_type> votes_to_remove - a list of accounts to remove from the current voting slate
• optional<account_id_type> proxy - an optional voting proxy

Validation:

The operation must not be used before the time of the hardfork.

• authority must exist.
• voter must exist and have sufficient balance to pay the fee.
• If authority.vote_until is present, then it must be in the future.
• If authority.num_members > 0 then number must equal 0.
• If authority.num_members == 0 then authority.min_members <= number <= authority.max_members.
• For all entries in votes_to_add:
  • must exist
  • must not be present in the user's voting slate on authority
  • if authority.candidates is not empty then it must be contained therein
  • if authority.candidate_holders is present then it must own tokens of the given type
• For all entries in votes_to_remove:
  • must be present in the user's voting slate on authority
• If both votes_to_add and votes_to_remove are empty then number must be different than the voter's previous choice for number, or the voter's proxy setting must change.
• If proxy is present then
  • authority.proxy_allowed must be true.
  • proxy account must exist and must have a voting slate for the authority.
  • number must equal 0 and both votes_to_add and votes_to_remove must be empty.

Evaluation:

• If proxy is not present but voter had set a proxy on this authority before
  • Subtract the voter's token balance from the old proxy's proxy token count and adjust vote tally accordingly.
  • Apply votes_to_add as described below.
• If proxy is present and voter had not set a proxy before
  • Remove all accounts from the user's own voting slate and adjust vote tally accordingly.
  • Set proxy in voting slate.
  • Add voter's balance to proxy's proxy token count and adjust vote tally accordingly.
• If proxy is present and voter had set a (different) proxy before
  • Remove old proxy and adjust vote tally accordingly (see above).
  • Set new proxy and adjust vote tally accordingly (see above).
• If proxy is not set
  • votes_to_add, votes_to_remove and number are applied to the user's voting slate.
  • Let voting_balance be the sum of the voter's token balance of the asset plus his proxy token balance.
  • The voting delta is the voting_balance for each vote to be added and for the new number, the negative voting_balance for each vote to be removed and the previous number.
  • The voting delta in votes is applied to the vote tally of authority.
  • The resulting differences in the election outcome (if any) are reflected in the respective authority object.

Note: the intent is to have vote tallying work in the same way it is currently performed when voting with BTS. The same goes for determining the number of accounts that make up the authority, unless it is fixed.

5. adjust_balance

The chain logic for adjusting account balances is modified as follows:

• For each voting slate of the balance's owner with the same asset type as is being updated:
  • If the voting slate points to a proxy, adjust the proxy's proxy token count according to the balance delta.
  • Apply the balance delta to the vote tally according to the user's (or proxy's if set) voting slate.
  • Reflect the resulting differences to the election outcome in the respective authority object.

6. account_update_operation

After the time of the hardfork, a new type of special_authority is allowed. This new type wraps an elected_authority_object.

Discussion

Risks

This BSIP has an impact on the performance of balance-changing operations. It is believed that the overall impact will be low, because only few assets will be affected.

Summary for Shareholders

This BSIP introduces new operations to allow voting and elections using other assets than BTS. Authorities based on election outcomes can be assigned to accounts. Proxy voting is not possible in these elections.

Copyright

This document is placed in the public domain.

[shulthz]

In addition, it paves the way for a to-be-proposed change to BitAsset governance, i. e. the decoupling of BitAsset management from blockchain governance

This describe is not suitable to this BSIP.

[pmconrad]

It is part of the motivation. I see no reason why this shouldn't be in there.

[shulthz]

It is part of the motivation. I see no reason why this shouldn't be in there.

This BSIP come from 26 May 2018, it is not part of the motiviton，this is for non-core asset and asset-specific committee.

the decoupling of BitAsset management from blockchain governance

This is another proposition which shouldn't be here, you can give other example simply.

[sschiessl-bcp]

Here are my thoughts:

1. num_members, min_members, max_members: Why three arguments? A fixed num_members could be reflected by min_members == max_members, couldn't it?

2. I assume creator must be voting_asset owner?

3. Can there be several elected_authoritys?

4. candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

5. The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

6. Can we also have the option to create an elected_authority that automatically uses the top X accounts according to their balance of the candidate_holders asset as the multi-sig? The number X could still be voted on.

7. Suggest to rename candidate_holders to candidates_are_holders_of. I know, long, but self-explanatory

8. Couldn't the elected_authority_object be simply an account with a special type (like STEALTH owner account)? That would facilitate the further use and open other use cases, also with the notion that it should have balances and such. The active authority could be defined like you describe above, and owner authority is the creator. If the asset owner wants to make this authority then permanent, he can remove the owner authority.

9. What is it that elected_authority_object can do to the voting_asset?

10. Why exclude PMs and MPAs?

[pmconrad]

This BSIP come from 26 May 2018, it is not part of the motiviton

The issue is from 2018. The BSIP was written a couple of days ago, with this specific application in mind.

This is another proposition which shouldn't be here, you can give other example simply.

I don't get why you insist on removing it. Mentioning it here does not create a dependency nor does it endorse BSIP 83.

[pmconrad]

num_members, min_members, max_members: Why three arguments? A fixed num_members could be reflected by min_members == max_members, couldn't it?

Yes, that would also be possible.

I assume creator must be voting_asset owner?

No. Anyone can create an authority.

Can there be several elected_authoritys?

Yes, there is no limit.

candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

Hm, do you have a use-case for this in mind? My original thought was that through this mechanism candidates could either be appointed by giving them a specific token, or exclude themselves by burning the token.

The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

Weighted by voting stake, just as with the current voting mechanism. candidate_holders only affects the voting, not the vote tallying.

Suggest to rename candidate_holders to candidates_are_holders_of. I know, long, but self-explanatory

Makes sense.

Couldn't the elected_authority_object be simply an account with a special type (like STEALTH owner account)?

The idea is the the elected authority can be used in different ways, which IMO is more generic than making the elected authority an account in itself. Note that STEALTH is also just a normal account with a special "top holders" authority.

What is it that elected_authority_object can do to the voting_asset?

Nothing per se.

The elected authority is just an object that can be used e. g. as the active authority (or owner authority) of an account. If that account owns the voting_asset, then the elected authority can control the voting asset settings, otherwise it can't.

Another use-case is that the elected authority is not used as an authority, but that its member list can be assign other tasks, e. g. price feeding as proposed in BSIP-83.

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

[shulthz]

This BSIP come from 26 May 2018, it is not part of the motiviton

The issue is from 2018. The BSIP was written a couple of days ago, with this specific application in mind.

This is another proposition which shouldn't be here, you can give other example simply.

I don't get why you insist on removing it. Mentioning it here does not create a dependency nor does it endorse BSIP 83.

This BSIP should follow the underlying objective of this issue, don't mix something in it. Give a example of Corporate Governance is very easy to understand for everybody.

You can quote this BSIP in the BSIP 83, but the intention of BSIP 83 should not appear in this BSIP for some purpose. Personal understanding of BSIP is no need to appear in BSIP.

[shulthz]

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

I think you mix personal understanding in this. You think the vote with the borrowed tokens is not make sense, but you can't deprive the right to choose of these PMs and MPAs, how to chose is their problem. You forbid this vote in this DEX, how you can forbid the borrow in other DEX or CEX?

[sschiessl-bcp]

I assume creator must be voting_asset owner?

No. Anyone can create an authority.

candidate_holders could be a amount object (asset_id and amount), which makes only holders of at least amount eligible

Hm, do you have a use-case for this in mind? My original thought was that through this mechanism candidates could either be appointed by giving them a specific token, or exclude themselves by burning the token.

As a use case, if the authority targets a governance token, you can implement something similar to a 5% hurdle in order to be eligible in participation.

The current description is that the top X accounts (according to their votes) that hold the asset defined in candidate_holders are the multi-sig for the elected_authority authority? Weighted by their votes, or equal?

Weighted by voting stake, just as with the current voting mechanism. candidate_holders only affects the voting, not the vote tallying.

Note that STEALTH is also just a normal account with a special "top holders" authority.

Can we make this special authority available as well to be created?

What is it that elected_authority_object can do to the voting_asset?

Nothing per se.

If the creator of the authority is voting_asset, we could allow a optional allowed_options argument, which allows the new authority to change certain settings of the voting_asset. Essentially, a built-in custom active granted to the elected_authority by the asset owner. Since comittee can't create generic custom active authorities, this would make sense for BitAssets.

The elected authority is just an object that can be used e. g. as the active authority (or owner authority) of an account. If that account owns the voting_asset, then the elected authority can control the voting asset settings, otherwise it can't.

Another use-case is that the elected authority is not used as an authority, but that its member list can be assign other tasks, e. g. price feeding as proposed in BSIP-83.

The idea is that you can define such an authority directly as the price-feed authority? Can it also be a white and blacklist authority?

Why exclude PMs and MPAs?

Because users can borrow tokens of these types from the blockchain, and vote with the borrowed tokens. I don't see where that would make sense.

As an example, you could create a multi-sig account that owns a BitAsset, jointly governed by BitAsset holders and committee defined list of price feeders

[sschiessl-bcp]

I also propose that the flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent.

[pmconrad]

Can we make this special authority available as well to be created?

It already is.

The idea is that you can define such an authority directly as the price-feed authority? Can it also be a white and blacklist authority?

Anything is possible, although that's outside the scope of this BSIP. E. g. using it for price feeding is proposed in BSIP-83.

I think you mix personal understanding in this.

Of course I do. When I write a BSIP, I write down my personal understanding. Then we discuss this, and change when necessary. There is no technical reason to leave out MPAs or PMs, so if you guys think they should be available too I'll add them.

[pmconrad]

If the creator of the authority is voting_asset, we could allow a optional allowed_options argument, which allows the new authority to change certain settings of the voting_asset.

I don't think that's a good idea. There are other ways to achieve the same, so there's no need to add this.

he flag voting_allowed also disables the delete operation, to allow that an assets configuration/management can be made permanent

I don't understand. Which "delete operation"?