Inflexible Motion Execution Timing and Irreversible Voting

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xf54e40f80dfb6c03ff10f2652f5c5781be11e0a1221bd8e774beff5e7c53803b Severity: medium

Description: Description\

The executeMotion() function currently reverts if the voting duration has not yet expired, even if the threshold for votes has already been reached. Once a voter casts a vote, it cannot be changed, which may be problematic if circumstances change or if the voter makes an error.

Impact

Inflexible Motion Execution Timing:

• Emergency Situations: Inability to execute motions instantly in emergencies, even if the required threshold is met.
• Delayed Decisions: Governance decisions are unnecessarily delayed until the voting period ends.

Irreversible Voting:

• Error Correction: Voters cannot correct their votes if they make a mistake.
• Dynamic Situations: Voters cannot change their votes in response to new information or changing circumstances.

Attack Scenario\

Attachments

1. Proof of Concept (PoC) File

2. Revised Code File (Optional)

[PlamenTSV]

This is based on a ton of assumption about circumstances. Imo will need more clarity, otherwise invalid, since it is simply informational.

[0xmahdirostami]

thank you @PlamenTSV , yes its invalid

[Atharv181]

@0xmahdirostami

In the executeMotion() function, the current implementation first checks whether sufficient time has passed before allowing execution, and then it checks whether the voting threshold has been achieved. But in the emergency situations where immediate execution is necessary, this time check prevents execution even if the quorum has already been reached. Shouldn't there be a way to bypass this time check if the quorum is met to allow for urgent execution?

Impact: executeMotion() delays the execution during emergency situations by requiring that a specified amount of time must pass before execution even when the quorum has been reached. This could result in missed opportunities to correct critical problems, security vulnerabilities etc.

IMO it should be considered as a medium-severity issue according to the docs of hats

[FHieser]

Both of the things you mentioned are design decision and not a bug.