Create sip-402

content/sips/sip-402.md

@@ -0,0 +1,74 @@
+---
+sip: 402
+title: Remove Account Cooldown Timer for Rewards Claim Function
+network: Ethereum, Optimism, Base & Arbitrum
+status: Draft
+type: Governance
+author: Robin (@0xrobin2192)
+created: 2024-08-02
+---
+
+## Simple Summary
+
+This proposal outlines a plan to remove the cooldown timer reset when users claim rewards.
+
+## Abstract
+
+A 24 hour cooldown on withdrawing funds exists to prevent just-in-time liquidity MEV and resets when any action is taken by a user for a given account. Currently, this timer resets when users claim rewards, which has no impact on debt balance. 
+
+This proposal seeks to add a new function `loadAccountAndPermissionNoRecording` which does not call `recordInteraction`, and replace `loadAccountAndValidatePermission` with `loadAccountAndPermissionNoRecording` in the `claimRewards` function.
+
+Note this proposal is not inclusive of PNL claims, which are representative of positive pool performance.
+
+
+## Motivation
+
+The motivation behind this SIP is to remedy poor UX, as users are frequently confused when they wait 24 hours for funds to become withdrawable, claim rewards, and then realize that their previously withdrawable funds are now locked for another 24 hours.
+
+## Specification
+
+Create a new function `loadAccountAndPermissionNoRecording` which copies the `loadAccountAndValidatePermission` function but removes the `recordInteraction(account)` call.
+
+Modify `claimRewards` function to call `loadAccountAndPermissionNoRecording` instead of `loadAccountAndValidatePermission`.
+
+
+### Rationale
+
+`loadAccountAndValidatePermission` is used elsewhere in the codebase, so a new function is needed. The simplest path forward is to copy the `loadAccountAndValidatePermission` function while removing the function call that resets the cooldown timer, `recordInteraction`.
+
+
+### Technical Specification
+
+Define the new function `loadAccountAndPermissionNoRecording` as: 
+```
+  /**
+     * @dev Loads the Account object for the specified accountId,
+     * and validates that sender has the specified permission. These
+     * are different actions but they are merged in a single function
+     * because loading an account and checking for a permission is a very
+     * common use case in other parts of the code.
+     */
+    function loadAccountAndPermissionNoRecording(
+        uint128 accountId,
+        bytes32 permission
+    ) internal returns (Data storage account) {
+        account = Account.load(accountId);
+
+        if (!account.rbac.authorized(permission, ERC2771Context._msgSender())) {
+            revert PermissionDenied(accountId, permission, ERC2771Context._msgSender());
+        }
+    }
+
+```
+
+### Test Cases
+
+Test cases will be added to the code base before release.
+
+### Configurable Values
+
+NA
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).