Activity

1. Akira-Taniguchi

   added

   bugSomething isn't workingSomething isn't working

   on Jun 29, 2020
2. Akira-Taniguchi

   assigned

   aggre

   on Jun 29, 2020
3. aggre commented on Jun 29, 2020

   

   aggre

   on Jun 29, 2020

   Member

   More actions

   I noticed that Withdraw.calculateWithdrawableAmount is not necessarily an unfair value.
   The basis for that value is Lockup.getCumulativeLockedUp vs. Lockup.getCumulativeLockedUpAll ratio; That ratio is the same as the percentage of total rewards to which the Property is entitled. The holder(owner) has all of its rights until the Property balance changes. There is no question as I that.

   Now, is it wrong to set the LastCumulativeGlobalReward for the user who locked up first? I haven't organized my thoughts yet.
4. Omcodes23 commented on Mar 2, 2026

   

   Omcodes23

   on Mar 2, 2026

   More actions

   🤖 Crawly Smart Analysis

   Analysis

   Based on the issue description, it appears that there's an inconsistency in how calculateWithdrawableAmount is handling cases where getLastCumulativeGlobalHoldersPrice is 0 and a property already has a large amount of staking. Specifically, it seems that the current implementation might not be correctly updating or retrieving the value of Policy.rewards.

   Likely Root Cause

   1. Incorrect Logic for Staked Value: The logic in calculateWithdrawableAmount may not be properly accounting for the initial staked value when getLastCumulativeGlobalHoldersPrice is 0.
   2. Race Condition or Data Inconsistency: There might be a race condition where the state of Policy.rewards is not being updated correctly, leading to incorrect calculations.

   Step-by-Step Fix Plan

   1. Review calculateWithdrawableAmount Logic:

      • Ensure that the method checks if getLastCumulativeGlobalHoldersPrice is 0.
      • If it is 0, make sure that the initial staked value (Policy.rewards) is correctly retrieved and used in calculations.

   2. Update State Management:

      • Ensure that any state changes (like updating Policy.rewards) are properly synchronized to avoid race conditions.

   3. Add Debugging Statements:

      • Add logging or debugging statements before the calculation to verify the values of getLastCumulativeGlobalHoldersPrice and Policy.rewards.

   4. Write Unit Tests:

      • Write unit tests that cover scenarios where getLastCumulativeGlobalHoldersPrice is 0 and a property already has a large amount of staking.
      • Ensure these tests pass with the new implementation.

   Confidence Score

   Confidence: 0.95
   The issue seems clear enough from the description, but without direct access to the code, there's some uncertainty about the exact logic and state management. However, the symptoms suggest a straightforward fix.

   Suggested Target File Path

   file_path: contracts/WithdrawStorage.sol

   Memory key: dev-protocol/protocol#467:2020-06-29T16:48:18+00:00