Important chnages in contract should be subject to timelock

[hats-bug-reporter[bot]]

Github username: @0xmahdirostami Twitter username: 0xmahdirostami Submission hash (on-chain): 0x0824308cedfa6598773fbdd10f88d223d2906e64ba5b48a5534a0ae79f17e26e Severity: low

Description:

Title

Adding Delays for Important Changes in Contract

Description\ When making significant changes to the protocol, it's important to avoid sudden impacts on users. To avoid sudden impacts on users during significant protocol adjustments In the farm contract, the function owner_stop_farm needs a delay before taking effect. This delay allows users time to understand upcoming changes in the contract.

Impact The addition of delays for important modifications aims to safeguard users from abrupt shifts in the protocol, offering them a reasonable period to prepare and adapt to any impending changes.

Revised Code File (Optional) To implement this enhancement, a time delay mechanism (timelock) has been added for crucial changes in the contract. Specifically, for the owner_stop_farm function, a delay of 12 hours has been incorporated. This ensures that users have sufficient time to understand and adjust to proposed modifications.

 #[ink::contract]
 mod farm {
+    const TIMELOCK: u64 = 43200; // 12 HOURS

@@ -298,7 +319,13 @@ mod farm {
         fn owner_stop_farm(&mut self) -> Result<(), FarmError> {
             ensure!(self.env().caller() == self.owner, FarmError::CallerNotOwner);
             self.update()?;
-            self.end = self.env().block_timestamp();
+            self.end = self.env().block_timestamp() + TIMELOCK;

[0xmahdirostami]

Notice: This issue has minor severity, but due to the minor severity not working during the uploading time, I am submitting it as low severity.

[deuszx]

This is a conscious choice that the owner has full control over the farm. The only guarantee we give is that the owner will not be able to steal the staked tokens and the already granted rewards. The rest is up to the owner.

[deuszx]

Thank you for participation. After carefully reviewing the submission we've concluded that this issue is INVALID.

As stated, this is a conscious design choice not a vulnerability.

We hope you participate in the future audits of ink!.