votingPeriod in GuildVetoGovernor.sol is wrong

[c4-bot-5]

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/GuildVetoGovernor.sol#L231
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/LendingTermOffboarding.sol#L36

Vulnerability details

Impact

if we see the last 1 year data , roughly a block is mined in 12 seconds while in GuildVetoGovernor 13s/block is hardcoded

Proof of Concept

The voting period is an important factor in on-chain governance systems, and considering the 1 block / 13 secs users will only be able to vote for 155hours(6 day + 13 hours), while it's expected to be 7 days period and this can be a factor in some veto proposals where a quorum is not achieved till the very end
There are multiple instances where time is measured through 13s/block

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/GuildVetoGovernor.sol#L230

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/LendingTermOffboarding.sol#L36

Tools Used

manual review

Recommended Mitigation Steps

The voting period should be based on last year's data should be 12 secs/block instead of 13 secs/block

Assessed type

Governance

[c4-pre-sort]

0xSorryNotSorry marked the issue as sufficient quality report

[c4-pre-sort]

0xSorryNotSorry marked the issue as duplicate of #816

[c4-judge]

Trumpero changed the severity to QA (Quality Assurance)

[c4-judge]

Trumpero marked the issue as grade-b

[c4-judge]

Trumpero marked the issue as grade-c

[viraj124]

hey @Trumpero
From the C4 judging criteria it's a valid medium if the function of the protocol or its availability could be impacted especially when governance is involved hence it's clear that the voting period is very much affected by this issue

Also, the parent issue is labeled as grade A, while this one is grade c even after explaining the core issue
so can you please re-evaluate?

[Trumpero]

I believe this issue is of low severity because assets are not at risk and functionalities are not impacted, it simply represents careless documentation or natspec.

Low risk (e.g. assets are not at risk: state handling, function incorrect as to spec, issues with comments).

When an issue is downgraded to QA, it will be included in the QA report of the warden for QA point evaluation. Based on my QA judging of this contest, you don't have enough QA points to reach grade-b, so all your QA issues are labeled as grade-C

[Tri-pathi]

@Trumpero does it qualify for grade b now ? i.e after including above one, #826 and #514. QA report contains 6 valid issues now