Speed up proposals: discussion: 24h, voting: 48h

Proposal ID
GCx7xUZYtqkw6VNNEmFqJxBE3PMrYUDCDaCQ9yaguouL

With the temporary measures being proposed/applied, current timeframes are not effective: voting takes too much time and needs to be faster. Later, once the situation is stable again, swift lifting of the restrictions would also be great.

If passed, this would only apply for future proposals, ongoing votings are not affected

Transaction Payload

{
  "type": 12,
  "version": 2,
  "data": [
    {
      "key": "proposal_votingstart_offset",
      "type": "integer",
      "value": 1440
    },
    {
      "key": "proposal_votingend_offset",
      "type": "integer",
      "value": 4320
    },
    {
      "key": "proposal_applystart_offset",
      "type": "integer",
      "value": 4320
    },
    {
      "key": "proposal_applyend_offset",
      "type": "integer",
      "value": 5760
    },
    {
      "key": "user_propose_delay",
      "type": "integer",
      "value": 1440
    }
  ],
  "senderPublicKey": "3gQ8QUfoGQW6YVuhUv3zuqsbmxbV5F2FAuDXJqVKD6C9",
  "fee": 50000000,
  "feeAssetId": "WAVES",
  "timestamp": 1650894124283
}

How long is broadcasting period?

Definitely needed, in difficult time we need to react faster so Yes!

5760 - 4320 = 1440 = 24h

When one votation passed, at brodcast time, this will be executed in time stamp of payload, f.ex. in this case it’s 1650894124283 = Mon Apr 25 2022 13:42:04 GMT+0000

Thanks for your explanation of broadcast time counting.

I have a question about the voting of max borrowing apr 40%.
It looks like 40% changed immediately after the vote. 7 days broadcasting time(4/16~4/23) disappeared.

2 Likes

In the broadcasting period it can be broadcast at any time, surely it was broadcast just or shortly after it started. It didn’t take effect right then, because it had a time stamp for the next day

I put a post in that thread about when that time would be: “Checking timestamp, I think that this will be effective at 17 Apr 2022 6:00:00 (UTC)”. Broadcasting period started after votation at 16‑04‑2022 13:45 GMT+00 (=UTC).
I was checking on the 16th and the change was not made, so it must have been done on the 17th at that time.

On the other hand, seems that the proposal “Change USDT and USDC collateral factors to 80% and change liquidateDebtAmount to 1%” had a problem with this time stamp. It was Mon Apr 11 2022 08:25:58 GMT+00, but broadcast period didn’t start until the 17th.
I doubt that it would have been approved anyway, since the majority of votes are on the side of the accounts that it would have affected.

Having a few days to consider difficult and meaningful proposals is not a bad thing. Building in a couple days to read forum posts, consider your ideas and study to consider others ideas as well, is a great way to make sure you consider all possibilities before casting a vote. Knee jerk reactions should be avoided. I’m gonna vote no.

1 Like

When someone invests in procurement in a protocol like this it is not to be accessing it every day and counting bits, it usually takes days or weeks before they eventually give it a check or perform an operation.
We are in an anomalous and atypical situation, and it is not appropriate to rush a vote. It is not every protocol that short voting times are conceivable.
My vote is no.

2 Likes

Rushing proposals is a sure way to allow exploits to be pushed through and quick decisions do not equal smart decisions

4 Likes

There is a middle ground between governance efficiency and the risk of rushed decisions with not enough people informed before each vote takes place.

I believe 24h/48h to be a little too fast but 3d/5d would work fine I think with the right amount of publicity on Twitter/Discord/Telegram for example.

1 Like

Bad idea. Not enough time for discussion, not enough time for many people even to realize there is a voting. In 48 hours most votations wouldn’t even pass due to lack of quorum, so goes against the purpose of the proposal itself.

3 Likes

That here and who did not write here - your thoughts are nothing.

there is 1 player - who “manipulates” this whole system. and the further he goes, the more he controls her.

the last decision that continued his use of all USDD and USDC you see. now he is losing not $ 1.2 million but only $ 360,000.
3PEEsRmcWspCxhKqobvKY3axW1846AMRwzr (and today - 54300 Vires Protocol)

image

I, like 99% of users - no one here, and any of your suggestions are nothing. since 1 player has the majority of votes. And he is not interested in solving the problems that were created by his actions.

we are currently the service staff, slaves - call it what you will - this user.

he gets more and more Vires Protocol every day. and its monopoly grows.

if the decision to be offered is not beneficial to this user - he will vote no.

And the team, for some reason, pretends that we can offer something and influence it. We are calmer thinking that we can influence the situation. believe in it further.

4 Likes

This is completely true.

No matter how long the voting period is, I think that the existing practice is correct. Limiting time makes it harder for holders of “vires” tokens to participate in voting. it’s possible that bad guys will pass the vote they want, so I’m going to vote no.

1 day discussion
3 days voting

Would be better

1 Like

He hasn’t claimed his Vires, has no locked Votes. He cannot use them to vote

1 Like

Please, retract this stupid proposal.And stop doing proposals based on panic.

1 Like

If you don’t accept this proposal, evil proposal will be there for a long time.

However, by accepting this proposal, evil proposal will be rollback immidiately.

Why don’t you complain about this.

bc - 3PEEsRmcWspCxhKqobvKY3axW1846AMRwzr
because the person who is right now is a problem of the system. manipulates it as he wants and where he wants.

it has a majority of votes - and the situation today is not completely under control.
the project team has not found and found a solution for more than a month - how to withdraw their money from ordinary people.

I am sorry, but from what I see this address has no voting possibility. It may have, but currently not.