refactor(timelock): change submittedAt to validAt

[Rubilmax]

• Fixes Unpredictable timelock mechanism #267

[Jean-Grimal]

I'd rather stay with the current version though

[Rubilmax]

I'd rather stay with the current version though

But there's a bug with it, see the associated issue
What specifically don't you like about the new version? We can modify things to find a compromise

[Jean-Grimal]

I'd rather stay with the current version though

But there's a bug with it, see the associated issue What specifically don't you like about the new version? We can modify things to find a compromise

Oh yes sorry I was mistaken. I understand the issue now

[MerlinEgalite]

@Rubilmax can you update this PR please?

[MerlinEgalite]

I think the events haven't been updated though

[QGarchery]

Adding 6 tests 💪

A few minor suggestions but I like this implementation !

[Rubilmax]

Adding 6 tests 💪

A few minor suggestions but I like this implementation !

4 of them will actually be removed in #256 🫢

[StErMi]

@MerlinEgalite just to recap the changes

• the owner now cannot directly influence the timelock of existing pending proposals (already scheduled) by calling submitTimelock(newTimelock) where newTimelock > timelock
• the owner can still influence every pending proposal by executing submit*. He can also pass the very same already proposed value.
• the owner can anyway revoke the pending proposal and propose a new one (not in this PR, but there's another PR that makes the owner part of the guardian role)

PS: is there a PR that does not allow setting the same values for the current active pending proposals?
TLDR the main difference is that the duration of the timelock is stored in the pending proposal when it's created and submitTimelock(newTimelock) cannot directly influence an already scheduled pending proposal even if the timelock is instantly changed or pendingTimelock is approved.

[MerlinEgalite]

• the owner now cannot directly influence the timelock of existing pending proposals (already scheduled) by calling submitTimelock(newTimelock) where newTimelock > timelock
• the owner can still influence every pending proposal by executing submit*. He can also pass the very same already proposed value.
• the owner can anyway revoke the pending proposal and propose a new one (not in this PR, but there's another PR that makes the owner part of the guardian role)

This is exact in the current state of this PR.

PS: is there a PR that does not allow setting the same values for the current active pending proposals? TLDR the main difference is that the duration of the timelock is stored in the pending proposal when it's created and submitTimelock(newTimelock) cannot directly influence an already scheduled pending proposal even if the timelock is instantly changed or pendingTimelock is approved.

yes there's such PR here: #295