RFC: Allow delegators to subsume their delegate votes.

TZIP
1

In the current voting system, only delegates are allowed to submit
proposals or cast a ballot. This TZIP proposes to spread the voting
power between delegate and delagator by allowing delegators to subsume
their delegate proposals or ballots when they disagree.

In order to maintain the current voting participation level, in a
given voting period, and without explicit action of a delegator, its
voting power is still delegated to its current delegate.

In order to increase the voting participation, this proposal allows
delegator to cast a vote even when their delegate abstains.

See the proposed draft TZIP: Draft: allow delegator votes (!175) · Merge requests · Tezos / tzip · GitLab and a draft implementation : Draft: allows delegator to submits proposals and to cast votes (!4247) · Merge requests · Tezos / tezos · GitLab

4 Likes
2

I feel that it’s important that delegator votes must be anonymous while delegate votes remain transparent.

3

The governance model we have now resembles a representative democracy, where delegates “elect” their representatives via the act of delegating.

If we break this model, and allow some votes to be set by delegates and some to be set by the bakers they are delegating too, what risk do we incur? Would it make the whole baker incentive model invalid? What reason do I have to choose any one baker over another besides the staking reward?

I’m not against this idea, I’m really just thinking out loud to help drive this discussion forward.

1 Like
4

This seems related: Draft: Vote overrides (!403) · Merge requests · Metastate / tezos · GitLab. This was apparently developed in the context of Baking Accounts, I don’t remember if this was proposed in the Baking-Account version of Florence.

5

In practise though, most people just go with a baker they feel will give them the best return via baking rewards. Dex pools like Quipuswap, also delegate to a baker. I may want to provide liquidity to a specific token for no other reason than to participate in a crunchy farm. In this scenario, its very unlikely for the XTZ holder to know who the baker is as thats far from their top priority. There are also dApps that promote certain “trusted bakers” in a dropdown or let you paste an address yourself. 9/10 times a novice user is just going to go with one of the trusted bakers.

There are a great many of situations where a baker is being given voting power, stemming from use-cases nothing to do with voting. So they aren’t really electing a representative, they are trying to 10x their money and unaware of this election in the background.

Its also not even super easy to find out your bakers voting intentions. There is no requirement for them to publish anything anywhere. Or even if they do, they are not forced to stick with it. Have a look at what happened with Everstake. They were unsure what their users wanted, so they held several social media votes. All came back in favour of voting Yay, but Everstake then said they were worried it would be controversial, so voted pass instead. Quite a bit of XTZ left in the following days, so none of those users had their votes counted in the direction they wanted.

I’m not really sure how to fix it, but I agree that the current system doesn’t work. Currently when a baker casts their vote a snapshot is taken at that moment. XTZ holders can leave, but their XTZ can’t be given to someone else until the next period. Either XTZ holders need a way to vote themselves, or bakers need to vote earlier and holders given a chance to choose a baker and the votes are not counted until the end of the period instead of being snapshot

6

Have a look at what happened with Everstake. They were unsure what their users wanted, so they held several social media votes. All came back in favour of voting Yay, but Everstake then said they were worried it would be controversial, so voted pass instead. Quite a bit of XTZ left in the following days, so none of those users had their votes counted in the direction they wanted.

I agree this is an unfortunate scenario, but that’s how governance was intended to work from the beginning. The representative of those delegates (Everstake) voted however they wanted, and as a result lost supporters (delegators). I’m not saying this is good model and we should keep using it, I’m just saying this is how it’s intended to work.

I agree that DeFi has changed things, and that the majority of new XTZ holders don’t know or care about the baker they are using on those platforms.

It seems like the real problems here are:

  • general apathy amongst tezzie holders (especially with the DeFi crowd)
  • baker/delegator communication

I don’t think a baker should ever be “bound” to vote the way they initially say they will. It’s rotten if they go back on their word, but if we let them “signal” how they will vote, and then hold them to that “signal”, we will just recreate the same problem.

Bakers could say that are going to “signal” a certain way, then “signal” a different way. In this world of “signaling”, we could punish bakers that signal one way then vote another, but we already have that functionality because delegators leave that baker and the baker loses profit as a result.

1 Like
7

This comes across to me as an attempt to grant rights without the associated responsibilities, which disrupts the incentives.

Bakers need to spend time and money maintaining baking hardware, keep baking software up to date and well-connected to the network, invest a significant amount of capital to obtain at least one roll, lock ~10% of their staking balance as bond, and risk having those bonds slashed. And that doesn’t count time or money spent on any kind of social outreach or marketing to try to attract delegators.

In return, we earn block rewards and gain voting privileges. When Arthur designed Tezos, he envisioned bakers keeping 100% of the block rewards for themselves. But in an effort to attract delegators, most bakers forward 85-95% of the block rewards to their delegators, which means the only exclusive benefit of baking is voting.

I’m wondering why bakers should have to put in all the time, effort, money, and risk, if everyone else gets all the same privileges. I don’t think getting ~6% annually in block rewards instead of ~5.5% is worth it. My funds would have far greater returns put into Liquidity Baking or other DeFi. Is it really an unfair compromise to ask delegators (the ones who care, anyway) to be more involved and conscientious about which baker they delegate to? Is it really that unfair to ask them to choose their representative and then change to a different one if they don’t like how they voted? Sure, they don’t get the immediate gratification of a vote going their way if their baker votes against their wishes. But I don’t think it’s unfair to ask them to wait a couple of weeks for their choice of a new representative to go into effect in exchange for not requiring any of the baking costs (time, effort, money) of them.

Tezos uses a Proof of Stake consensus mechanism. People who have nothing at stake shouldn’t be able to override the wishes of the people who do have something at stake.

The current method for delegators who wish to have an immediate and direct vote during voting periods is for them to become bakers themselves. That is called an incentive. We want to incentivize that behavior because having more bakers is good for decentralization and good for Tezos, especially with the changes Tenderbake is bringing in Ithaca. Granting people the rights of being a baker without requiring them to bake disincentivizes people from becoming (or remaining as) bakers, which is bad for decentralization and bad for Tezos.

In my opinion, if you want the rights then you need to take upon yourself the responsibilities as well. The long-term consequences of doing otherwise are not good.

1 Like
8

First let me say I totally agree with all your points. I like the bit I’ve quoted above because it outlines the “baking economy” so-to-speak.

The current baking economy is essentially a race to see which bakers can operate the cheapest, while also getting the most delegates, and therefore highest reward. This drives bakers to compete with each other for delegators by keeping less block rewards for themselves, and sharing those rewards with delegators to attract more delegators.

The current “baking economy” is designed for bakers to compete. One of their rewards is the right to vote.

9

It seems to me that you are implying that in an effort to remain competitive, bakers might be willing to share their right to vote with delegators similarly to how they currently share their block rewards with delegators.

I don’t disagree. Some bakers might be willing to do that.

The difference is that bakers are free to choose how much, if any, of their block rewards they are willing to share with delegators. Whereas this proposal doesn’t grant bakers a choice in how much, if any, of their votes they are willing to share with delegators.

I don’t think this will help in any way with maintaining a competitive “baking economy,” and in fact I think it may harm the ability to compete since it will just incentivize people to find the baker with the lowest fee, no matter how they vote or otherwise engage with the community.

Consider the outcome of recent events if this change had already been adopted: All the people who left PosDog or Everstake as a result of the last vote would likely not have changed their delegations. I’m sure that PosDog and Everstake, who are already two of the largest public bakers, would have liked that. But the smaller bakers, who recently saw an influx of new delegations, wouldn’t have gained that competitive advantage.

10

I think we have a slight miscommunication. I like our current model, and I personally dislike the idea of bakers not voting on behalf of all their delegators. I think it should always be the responsibility of a delegator to watch how their baker votes and change bakers accordingly.

I think we should find another way to solve the core problems at hand, which appear to be:

  • general apathy amongst tezzie holders (especially with the DeFi crowd)
  • baker/delegator communication
1 Like
11

Just spitballing some theoretical solutions:

  • general apathy amongst tezzie holders (especially with the DeFi crowd)
    ** if we prevented DeFi pools from delegation altogether that fixes this issue, but is a very extreme stance to take
  • baker/delegator communication
    ** on chain messaging may help, if wallets support it. We could also penalize non-voters (bakers that don’t vote yay, nay, or pass).
12

I think you are more correct than you realize. DeFi is a great example of when using something like ctez in place of tez would be beneficial.

1 Like
13

I’m unfamiliar with ctez, how would that work to solve the “DeFi apathy” problem? It sounds like a wrapped tez implementation, is that correct?

14

I don’t know if it would solve the apathy issue, but one of the advantages of using something like ctez (or Crunchy’s WTZ as another example) is that since it’s used as a 1:1 replacement of XTZ for DeFi apps, there’s no longer any reason to be baking these liquidity pools. DeFi participants can be free to operate how they want without needing to think about where their tez is being delegated to. Is that enough to move the needle to get more people invested in the governance process though? I don’t know. It’s an interesting thought exercise though.

15

To add to this: voting is not always considered as a perk. Some bakers may be happy to pass or abstain, assuming that “my delegators can always vote anyway if they care”.

This proposal may actually reduce participation.

1 Like
16

I think this idea moves us closer to solving the “DeFi apathy” issue, and definitely gives possible delegators more options.

My fear is that it’s up to the DeFi contract author to decide if they want to delegate the DeFi pool that’s managed within the contract. Even if some DeFi platforms take the approach to used wrapped tez, not everyone will.

If we prevent, at the protocol level, contracts from delegating to a baker, this would stop the issue. It would mean less rolls baking, but it would also mean less rolls are eligible to bake. If we reduce the rolls baking while proportionately reducing the rolls eligible to bake, I don’t think there is a security/centralization risk concern.

@murbard I would love to hear your thoughts on if the above solution would cause centralization risk.

17

It may make sense to constrain this proposal further: let delegators override a yay with a nay, or a nay with a yay. But it’s impossible to override a “pass”. This way, bakers are no less encouraged to vote than today.

If delegators don’t like their bakers vote, they can override it. They can also preemptively override before the baker votes (perhaps sending a useful signal to the baker), but the delegator’s vote won’t be counted if the baker does not vote or votes pass.

18

@nicolasochem This seems like a good way not to discourage baker to vote. I have updated the TZIP with this idea and with some security consideration raised by the implementation reviewers.

If this feature, is not consensual, would it make sense to add a toggle vote and to delay its activation until a positive toggle of at least 50% bakers?

19

In the last revision, can delegators override a Pass vote from their baker? TZIP seems to indicate so. I still think it’s important that they can only override a Yay with a Nay or a Nay with a Yay. Otherwise we will see more bakers vote Pass.

I think a toggle is unnecessary since the change is small.