Open code423n4 opened 1 year ago
Would like to confirm it as a doc issue.
trust1995 marked the issue as primary issue
trust1995 marked the issue as satisfactory
Vault code is adapted from Fantom whereby each block corresponds to roughly 1s. We could possibly update this for Optimism, we'd have to look more into how block.timestamp behaves with Optimism's blocks and TX indices. We could then also update the documentation accordingly. Recommend QA severity.
tess3rac7 marked the issue as disagree with severity
Seems to be meaningful enough for med severity, given it is NOT a doc issue as initially thought.
trust1995 marked issue #829 as primary and marked this issue as a duplicate of 829
trust1995 changed the severity to QA (Quality Assurance)
trust1995 marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L125 https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L418-L425
Vulnerability details
Impact
The
ReaperVaultV2::constructor
states that thelockedProfitDegradation
value expresses a time unit in blocks, however, the way it is utilized inReaperVaultV2::_calculateLockedProfit
is in terms of Unix time in seconds rather than time in blocks.Proof of Concept
The highlighted lines of code sufficiently demonstrate the issue present in the code.
Tools Used
Manual review.
Recommended Mitigation Steps
If the issue identified is simply an error in documentation, this exhibit can be regarded as "Q&A". Otherwise, if the value is incorrectly utilized / misconfigured in the
constructor
this exhibit should be considered of "medium-risk".