SIP-402: Remove Account Cooldown Timer for Rewards Claim Function
Author | |
---|---|
Status | Approved |
Type | Governance |
Network | Ethereum, Optimism, Base & Arbitrum |
Implementor | TBD |
Release | TBD |
Proposal | Loading status... |
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.