Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Referendum Deposit Track #73

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Referendum Deposit Track #73

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a035104
Add referendum deposit track RFC
JelliedOwl Feb 12, 2024
72f9c83
Add referendum deposit track RFC
JelliedOwl Feb 12, 2024
d0e74c4
Merge remote-tracking branch 'origin/main'
JelliedOwl Feb 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions text/0073-referedum-deposit-track.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# RFC-0073: Decision Deposit Referendum Track

| | |
| --------------- |--------------------------------------------------------------------------------|
| **Start Date** | 12 February 2024 |
| **Description** | Add a referendum track which can place the decision deposit on any other track |
| **Authors** | JelliedOwl |

## 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Motivation

There have been recent attempts to use the Kusama root track which have timed out with no decision deposit placed. Usually, these referenda have been related to parachain registration related issues.

## 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:
Copy link
Member

@ggwpez ggwpez Feb 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- [Referenda Pallet] Modify the `placeDecisionDesposit` function to additionally allow it to be called by root, with root call bypassing the requirements for a deposit payment.
- [Runtime] Add a new referendum track which can only call `referenda->placeDecisionDeposit` and the utility functions.

### Referendum track parameters - Polkadot

- **Decision deposit**: 1000 DOT
- **Decision period**: 14 days
- **Confirmation period**: 12 hours
- **Enactment period**: 2 hour
- **Approval & Support curves**: As per the root track, timed to match the decision period
- **Maximum deciding**: 10

### Referendum track parameters - Kusama

- **Decision deposit**: 33.333333 KSM
- **Decision period**: 7 days
- **Confirmation period**: 6 hours
- **Enactment period**: 1 hour
- **Approval & Support curves**: As per the root track, timed to match the decision period
- **Maximum deciding**: 10

## Drawbacks

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Testing, Security, and Privacy

Will need additional tests case for the modified pallet and runtime. No security or privacy issues.

## Performance, Ergonomics, and Compatibility
### Performance

No significant performance impact.

### Ergonomics

Only changes related to adding the track. Existing functionality is unchanged.

### Compatibility

No compatibility issues.

## Prior Art and References

- Recent discussion / referendum for an alternative way to address this issue: [Kusama Referendum 340 - Funding a Decision Deposit Sponsor](https://kusama.polkassembly.io/referenda/340)

## Unresolved Questions

Feedback on whether my proposed implementation of this is the best way to address the issue - including which calls the track should be allowed to make. Are the track parameters correct or should be use something different? Alternative would be welcome.