[Phase-3] HIP-10: Create a decision locking mechanism

HIP: 10
title: Create a decision locking mechanism
author: @Mads
status: Finalization
created: 2021-05-16


This proposal suggests creating a decision locking mechanism that will make decisions more difficult to reverse at a later date. This locking mechanism can either be applied to new or existing decisions.


For some decisions, we need to signal to the world and ourselves that they are very unlikely to be overturned in the future and that it would require a lot of effort to do so. One such decision would be to, for instance, lock the $UBI issuance rate to ensure that people can forecast the value of the currency, improving stability.


There would be three ways of creating a locked decision.

  1. In a new proposal, the decision can be locked immediately. A separate section, “Locking Justification”, arguing why this decision should be locked, must be included.
  2. For an existing approved proposal, the decision can be locked by creating a new proposal to lock the earlier decision.
  3. An existing locked decision can be put up for a new locking vote to increase the reversal threshold further. This new vote requires a separate proposal.

To create a valid locking proposal (cases 1-3):

  • Some version of the verb “Lock” must be included in the title of the proposal topic.

  • All minimum poll voting times are doubled both for phase-2 and phase-3.

  • In a phase-3 binding vote the word “Locking” must be prepended for the signal poll along with any other required keyword.

How locking works:

  • In a locking vote, a minimum of 60 % approval is needed, if the approval is less then the proposal fails completely.

  • If the locking threshold is exceeded then a reversal threshold is set. The reversal threshold will be the approval rate of the proposal, rounded down to the nearest 5 %. So a proposal passing at 74.5 % would later require a 70 % vote to repeal.

  • If the reversal threshold would be set to above 90 % by the above rule then it is instead set to 90 %.

  • If locked decisions exist the locking mechanism itself can only be repealed by achieving a majority corresponding to the highest reversal threshold of any locked proposal.

  • Additions and exceptions to a locked proposal can only be introduced by other locking proposals with an approval rate higher than the reversal threshold.


This implementation allows the community to make reversing a decision very hard - but not impossible. The difficulty of reversing a decision scales with the amount of agreement at an earlier time. Consideration was also to include a requirement that some quorum of voters must participate in the vote, but this was dropped since this would make the difficulty of reversing a decision too linked to user participation which may vary in unpredictable ways over time. The locking of the issuance rate is postponed, since creating a locking mechanism AND using it on something so central would be too much for one vote.



Some support for this proposal

This is a violation of HIP-4 “(that contains the proposal text as well as a link to the HIP post on the PoH Forum” as the proposal on snapshot does not include its text. Therefore the signaling proposal will not have any effect.

I have created the corrected poll and deleted the original. Clement could you please edit the first post to point to the correct link?

I have updated the post.

Moved to Phase-3.

  • Cleaned up the requirements for clearly communicating that a proposal is not only binding, but locking.
  • Added increased vote time for locking proposals.
  • Added that the locking mechanism is itself locked.

HIP-10 has passed and the locking mechanism can be used on proposals.

Hi, the proposal looks good. Can the wording between “decision” and “proposal” be clarified? Sometimes the text speaks of decision, but the specification refers to locking proposals. Are there other things to lock other than proposals? If not, then all “decision” words could be changed for “proposal” in the text.

How approval is defined here? 60% of in favour vs against? Could there be a quorum of the registry, lets say 51% of the registry population? I know there’s a discussion about this in the rationale, but the same argument is valid for having and not having a quorum level. Irreversibility of measures is a big serious issue, and without a quorum, a situation similar to this might happen (ridiculous in nature, but to prove a point):

  • A locking proposal is issued. 1000 people vote in total, 601 in favour. A 60% unlocking threshold is set.
  • An unlocking proposal is issued, for unknown reasons people are not aware or not able to vote: 8 vote in favour, 2 vote against.

How are these votes in any way equivalent? How does it reflect the representativeness of the people? I don’t have an answer to this, but maybe you could reason this with me.

I think this is a more general problem with proposals - that a vote might pass unnoticed by the people who would wish to participate. It is not specific to locking. But the locking proposals have the protection that they must run longer. It may not be enough, but at least it is better than the normal proposal passing case. The proposal should have specified that the extended time applies to unlocking as well as locking, though.

1 Like