Proposal: Max Delegate Pay = Approval Rate

[ripplexiaoshan]

I propose we make an equation like

                      Max Pay Rate= Approval Rate*2*Stability

   The principle behind this is that if one delegate gets over 50% of approval, he deserves everything, as in real company. Of course, Max Pay Rate can not exceed 100%.

However, I am against the idea that all standby delegates get pay also, because some big shareholders would vote for his own 101 delegates but doesn't contribute to network security.  Then DPOS is no different to POS. Probably only the top 50 standby delegates deserve pay, 50 backups are enough.

[fuzzy]

This is getting very interesting here ..
Just my 2btsx:

I'd like to be able to run the charity delegates at 100% payrate ... (if possible) .. i am sure the reasoning behind that is obvious, isn't it?

 This is a good point.  It can eventually block out delegates who do not receive high pay, keeping them from scaling in a way that would make it nearly impossible those at the top to be taken out of their position by someone who, for instance, is trying to run delegates and not interested in putting all their funds back into building a huge delegate "firm".

It becomes too hierarchical for my tastes.  However, seeing the delegates increased from 101 to 150 seems not too bad an idea.

[xeroc]

This is getting very interesting here ..
Just my 2btsx:

I'd like to be able to run the charity delegates at 100% payrate ... (if possible) .. i am sure the reasoning behind that is obvious, isn't it?

[sudo]

if it's possible to  Automatical  evaluate  delegate   by KPI?
Considering factors such as "delay","missinig block percent", "online time " ,"pay rate" ,"Approval Rate "at the same time
but with “weight percent” voted by btser?

[liondani]

Proposal: Max Delegate Pay = Approval Rate

It would give a motive to concentrate the marketing efforts on one delegate account for each individual...
I mean it is much more worth to have 1 strong active delegate on top 20 rank instead of more active delegates on the last spots...

[Troglodactyl]

Incentivizing delegates to pursue consensus rather than just enough support to stay in makes sense to me.  Max Delegate Pay = (Approval Rate / Highest Current Approval Rate) could provide such incentives with less startup shock.

[fuzzy]

I like delegates taking ownership for the network, giving them an economic incentive to improve participation by everyone.

I still think the game-theory behind delegates strategy is kind of backwards with weird incentives (e.g., delegates have the incentive to actively damage the network in the case of a price shock; delegates are "forced" to keep pay rates well above market value). This proposal has good intentions, but layered on top of the other backwards incentives might lead to a big problem:

If I'm running a node and I choose a 20% payrate to be my subsistence rate with 100% uptime. My vote total drops from 100% to 95%, and I have no ability to raise my rate, I now have the incentive to turn off my node. You then have to wait for enough people to vote you out, which may not happen quickly - and there is now a dead delegate for an indefinite amount of time.

I generally believe the market should sort it out:
1) delegates should be allowed to set the pay rates to whatever they want (I understand the argument against, perhaps you can allow for a publicized lag time between when it is announced and set. Give users the choice whether or not they want to vote for someone that chooses to run a dynamic operation where payrate tracks bitUSD, for example).
2) If users do not want a delegate in, they should be able to down-vote a delegate.


EDIT: For this plan to work, delegates also have to have the ability to raise their pay rate.

Actually I wouldn't have it multiply like that.   If you have a pay rate at 20% and an approval of 100% your effective pay rate will be 20%.   If you have a pay rate of 20% and approval of 21% you still get 20%.   If you have pay rate of 20% and approval of 15% then your pay rate is only 15%.

Effectively low-approval delegates cannot demand 100% pay rate.   But high approval delegates can get their pay rate.

another idea:
what about not to burn some BTSX but use them to pay standby delegates...(?)
for example If you have a pay rate of 80% and approval of 15% then:
1. your effective pay rate is 15%
2. 20% of BTSX get burnt (like before from total)
3.but  65% get spited proportional to their votes to all delegates included the standby...

I'll just say this and let it be where it is so people can at least know of the plans we were considering behind the scenes. 

We were thinking to build a platform where Delegates essentially pay registered DPOS users to help propagate their content.  "Action Points" could be purchased in bitUSD, bitYuan, bitRubles, bitGold/Silver...etc, as "donations to Beyond Bitcoin^X".  A daily purchasing cap in addition to an account total cap on "action points" would be present to keep any delegate from becoming too powerful. These work to fuel creation and sharing of content (whether educational, entertaining, pr-related...anything really). These action points can then be attached to posts that a Delegate or Sponsor Users think needs to be known by the rest of the investors and crypto community.  *I wont go into all the plans for uses of these points outside of this sphere yet* 

In the case above, using this platform, the Delegates philosophically inclined to agree to do something like what you say above would pay the community in its saved-up "action points" to propagate the content on social media.  There will be a cap to ensure users can't game the system (unless they go to the trouble of creating another account and building trust on it too).  And even links to DAC/Delegate sponsors could incentivize users to click on them by being given action points to be redeemed by a user. 

This way delegates are not forced to do any particular thing by the system.  All they have to do is get power from those who have a vested interest in the system.  We are looking for helpers in this project if anyone is interested.  There are also projects around the forums I have thought i'd like to utilize in conjunction with this (as part of the sites functionality), so I'd be interested to hear what you have to say about this within the system you are proposing if you can muster the time to explain. 

As far as the transaction fees there are potentially really cool things that can be done with that.  Interested in hearing further solutions.

[Empirical1]

  I like the idea of pay being related to approval rate.
I also like the idea of paying some standby delegates something.

I think there may be other approval requirements introduced in the case of equity release anyway, but that's something that concerned me as I'd rather equity release was only directed to the delegates that had the most approval.

[Xeldal]

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I don't think its a cut and dry property rights fix

Is that shareholder really paying the delegate?  If their not making transactions their not paying anyone.  Your vote is guaranteeing all other shareholders property to pay that delegate not just your own.

Whether or not I vote for a candidate, I will still end up paying him, based on everyone else's vote.

To me this guarantee's that no delegate will receive 100% pay.  good or bad idk.

[fuzzy]

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I am also thinking that for security purposes we may need to allow more than 101 votes, perhaps 150 per slate so that voting for "standby delegates" doesn't come at the expense of reducing security of active delegates.

Listening  

[liondani]

I like delegates taking ownership for the network, giving them an economic incentive to improve participation by everyone.

I still think the game-theory behind delegates strategy is kind of backwards with weird incentives (e.g., delegates have the incentive to actively damage the network in the case of a price shock; delegates are "forced" to keep pay rates well above market value). This proposal has good intentions, but layered on top of the other backwards incentives might lead to a big problem:

If I'm running a node and I choose a 20% payrate to be my subsistence rate with 100% uptime. My vote total drops from 100% to 95%, and I have no ability to raise my rate, I now have the incentive to turn off my node. You then have to wait for enough people to vote you out, which may not happen quickly - and there is now a dead delegate for an indefinite amount of time.

I generally believe the market should sort it out:
1) delegates should be allowed to set the pay rates to whatever they want (I understand the argument against, perhaps you can allow for a publicized lag time between when it is announced and set. Give users the choice whether or not they want to vote for someone that chooses to run a dynamic operation where payrate tracks bitUSD, for example).
2) If users do not want a delegate in, they should be able to down-vote a delegate.


EDIT: For this plan to work, delegates also have to have the ability to raise their pay rate.

Actually I wouldn't have it multiply like that.   If you have a pay rate at 20% and an approval of 100% your effective pay rate will be 20%.   If you have a pay rate of 20% and approval of 21% you still get 20%.   If you have pay rate of 20% and approval of 15% then your pay rate is only 15%.

Effectively low-approval delegates cannot demand 100% pay rate.   But high approval delegates can get their pay rate.

another idea:
what about not to burn some BTSX but use them to pay standby delegates...(?)
for example If you have a pay rate of 80% and approval of 15% then:
1. your effective pay rate is 15%
2. 20% of BTSX get burnt (like before from total)
3.and 65% (will not burnt ) get split proportional to their votes to all delegates (included the standby)...
 

[bytemaster]

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?

I view it this way, for someone to get 100% pay they should have 100% approval.   Shareholders who don't approve of a candidate shouldn't have to pay that delegate.  By doing it this way we are really protecting shareholder property rights.  A vote is "consent to pay".   I think this really encourages delegates to move the network toward consensus and unite the shareholder opinions (increasing security) rather than divide opinions and decrease security. 

I am also thinking that for security purposes we may need to allow more than 101 votes, perhaps 150 per slate so that voting for "standby delegates" doesn't come at the expense of reducing security of active delegates. 

[fuzzy]

There are other solutions.  One of them would be to have delegates contribute to a site, or network of sites, where users are incentivized to learn about DACs, their Delegates and act in what they individually (or collectively) see as in the best interest of the ecosystem(s).

Does there come a point where putting these types of things in the code take away the ability of the users, and those trying to build a layer that enables them to collaborate and act in ways that dynamically provide solutions in times when quick adaptation becomes necessary? 

It becomes very easy sometimes for engineers to think that they can engineer a "perfect" solution.  To me, that is where enabling the users comes in.  Opinions?

[bytemaster]

Actually I wouldn't have it multiply like that.   If you have a pay rate at 20% and an approval of 100% your effective pay rate will be 20%.   If you have a pay rate of 20% and approval of 21% you still get 20%.   If you have pay rate of 20% and approval of 15% then your pay rate is only 15%.

Effectively low-approval delegates cannot demand 100% pay rate.   But high approval delegates can get their pay rate.

OK that's good. What happens if very few have enough votes to cover expenses? This is a problem now and possibly during price shocks

I also would like to see some way to allow delegates to get paid tracking another bit asset via dynamic payrates.

Raise fees if they cannot make enough to cover expenses.   The fees collected will go up dramatically from where they are now as trx volume and trading kicks in.

[maqifrnswa]

Actually I wouldn't have it multiply like that.   If you have a pay rate at 20% and an approval of 100% your effective pay rate will be 20%.   If you have a pay rate of 20% and approval of 21% you still get 20%.   If you have pay rate of 20% and approval of 15% then your pay rate is only 15%.

Effectively low-approval delegates cannot demand 100% pay rate.   But high approval delegates can get their pay rate.

OK that's good. What happens if very few have enough votes to cover expenses? This is a problem now and possibly during price shocks

I also would like to see some way to allow delegates to get paid tracking another bit asset via dynamic payrates.