Author Topic: Proposal to enhance delegate pay/subsidy mechanic  (Read 3318 times)

0 Members and 1 Guest are viewing this topic.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
If I understand correctly, subsidy_rate + subsidy_burn_rate should be always equal to 100, right?  But it seems not, then in which case, it will be < 100? Let's say subsidy_rate is 50%, subsidy_burn_rate is 20%, then where does the rest 30% go?

The rest is saved for the future.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline ripplexiaoshan

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 2300
    • View Profile
  • BitShares: jademont
 If I understand correctly, subsidy_rate + subsidy_burn_rate should be always equal to 100, right?  But it seems not, then in which case, it will be < 100? Let's say subsidy_rate is 50%, subsidy_burn_rate is 20%, then where does the rest 30% go?
BTS committee member:jademont

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Thoughts?

Honestly? All I see are inelegant hacks tweaking a flawed foundation.

First, I think it is a mistake to "burn" the subsidy. The way I look at it is that the DNS DAC currently has defined the total supply to be 10 billion with about 5 billion currently in a reserve fund held by the DAC. I suppose you can move (or "burn") the money by moving some of it from the reserve fund to the untouchable fund, thereby providing investors with a monotonically decreasing total maximum supply (assuming no future hard forks changing the rules), but I think that entire concept is stupid and misguided especially in this early stage when we would like to have as much of the hard-limit supply available to grow the DAC and reach its potential. In other words I think the subsidy_burn_rate variable should be zero and any parts of the transaction fees or subsidy that aren't used to pay the delegates (determined from pay_rate and subsidy_rate) should be recycled back into the reserve fund. Then, much later in the future, we can hard-fork if desired to reduce the maximum supply limit to less than 10 billion if there really isn't anything valuable to spend those shares on (which would essentially act as a huge dividend at that time, however, most of the value of that dividend would have been already factored in the price of DNS since shareholders would be expecting that max supply reducing hard-fork well in advance).

Second, everything I said in the previous paragraph isn't how I would ideally do it. I haven't been shy about discussing how I would ideally structure these systems. But the previous paragraph is IMHO a sane way of quickly restructuring the existing system if you are unwilling/unable to implement the proper foundation of delegate proposals ratified by shareholder vote.

It seems reasonable not to have a subsidy_burn variable and simply save everything and hard-fork the max supply down if that's ever deemed the right thing to do.

I agree shareholder ratification for "worker"-style expenditures/dilution is ideal.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Thoughts?

Honestly? All I see are inelegant hacks tweaking a flawed foundation.

First, I think it is a mistake to "burn" the subsidy. The way I look at it is that the DNS DAC currently has defined the total supply to be 10 billion with about 5 billion currently in a reserve fund held by the DAC. I suppose you can move (or "burn") the money by moving some of it from the reserve fund to the untouchable fund, thereby providing investors with a monotonically decreasing total maximum supply (assuming no future hard forks changing the rules), but I think that entire concept is stupid and misguided especially in this early stage when we would like to have as much of the hard-limit supply available to grow the DAC and reach its potential. In other words I think the subsidy_burn_rate variable should be zero and any parts of the transaction fees or subsidy that aren't used to pay the delegates (determined from pay_rate and subsidy_rate) should be recycled back into the reserve fund. Then, much later in the future, we can hard-fork if desired to reduce the maximum supply limit to less than 10 billion if there really isn't anything valuable to spend those shares on (which would essentially act as a huge dividend at that time, however, most of the value of that dividend would have been already factored in the price of DNS since shareholders would be expecting that max supply reducing hard-fork well in advance).

Second, everything I said in the previous paragraph isn't how I would ideally do it. I haven't been shy about discussing how I would ideally structure these systems. But the previous paragraph is IMHO a sane way of quickly restructuring the existing system if you are unwilling/unable to implement the proper foundation of delegate proposals ratified by shareholder vote.


Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
+5% ... makes sense to me

Yes, I agree to "saving up" the delegate subsidy too.  But I wonder how would a stakeholder decide if and what level of subsidy burn rate.  Would it be something easy for them?
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
+5% ... makes sense to me

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Right now:

1) Each block has a maximum possible subsidy which is a fixed % of the difference between current_shares and max_shares
2) Your pay_rate determines what % of normal transaction fees *and* what % of the subsidy you want.

This leads to us burning through the delegate subsidy very fast as nobody is taking a high pay rate.

I propose:

1) pay_rate only determines how much of "normal" transaction fees you take (the rest are burned).
2) subsidy_rate determines what % of the max possible subsidy you take.
3) subsidy_burn_rate determines what % of max possible subsidy you burn.
   so subsidy_rate + subsidy_burn_rate <= 100   


Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.