Referendum Deposit Track #73
Conversation
# Conflicts: # text/0073-referedum-deposit-track.md
|
|
||
| ## Summary | ||
|
|
||
| The current size of the decision deposit on some tracks is too high for many proposers. As a result, those needing to use it have to find someone else willing to put up the deposit for them - and a number of legitimate attempts to use the root track have timed out. This track would provide a more affordable (though slower) route for these holders to use the root track. |
There was a problem hiding this comment.
The current size of the decision deposit on some tracks is too high for many proposers.
I think in all cases these can be proposed on the whitelisted caller track instead and be fast-tracked by the fellowship.
There was a problem hiding this comment.
However, whitelisted caller has a minimum of 5% final support level compared to 0% on other tracks. So you need at least a lot of abstentions (I think those count against the support threshold).
There was a problem hiding this comment.
I don't think everything that requires Root will go through Fellowship though, for example 457. It requires Root but it's not a "pure, neutral" call.
|
|
||
| This track would provide a route to starting a root referendum with a much-reduced slashable deposit. This might be undesirable but, assuming the decision deposit cost for this track is still high enough, slashing would still act as a disincentive. | ||
|
|
||
| An alternative to this might be to reduce the decision deposit size some of the more expensive tracks. However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda. |
There was a problem hiding this comment.
However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda.
Yes and to scare away bad proposals since they can be slashed and having a big deposit slashed is bad.
|
|
||
| ## Explanation | ||
|
|
||
| Propose to address this by adding a new referendum track ***[22] Referendum Deposit*** which can place the decision deposit on another referendum. This would require the following changes: |
There was a problem hiding this comment.
What you are asking in fact is to just reduce the deposit to 1000 DOT.
The fact that this is done through a new track does not matter i think since the Treasury does not have a counterparty risk here from being slashed.
What i mean: if 100,000 DOT from the treasury is slashed, then nobody cares. But then it loses its scare-off ability.
There was a problem hiding this comment.
It's not quite the same since the number of deciding referenda on the root track is small (I think), so I definitely wouldn't be advocating for reducing the DD there without also increasing the number which could in deciding at any one time.
There was a problem hiding this comment.
The fact that this is done through a new track does not matter
I must respectfully disagree. Placing a decision deposit directly on a referendum is permissionless whereas this RFC proposes a permissioned way to place a decision deposit via OpenGov.
A referendum that seeks to place a decision deposit is fundamentally different from a referendum that seeks to execute an action. Voting in favor of the former signals, "I want this referendum to be decided on by token holders without the disincentive of slashing" whereas voting in favor of the latter signals, "I want this action to be executed on chain." These are two very different statements. If a majority of token holders agree on the former, why shouldn't that be allowed? Isn't this supposed to be OpenGov?
The current status quo implies that no referendum should be decided on unless the decision deposit comes from some account permissionlessly. I think that is quite inflexible, especially since there are well-intentioned individuals that should be given recourse, other than the Fellowship, for placing large decision deposits.
There was a problem hiding this comment.
Maybe this is the wrong place to decide it - the Fellowship should be consulted for technical questions - not political ones. I suggest bringing it up here ASAP: polkadot-fellows/runtimes#184
RFC for adding a new track which can place decision deposits on other tracks. I'm happy to work on implementation if there's a reasonable prospect of this being accepted.