-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nikhil840096 - The lossFee
is simply added to the commonData
and not reimbursed to the keeper, leading to potential losses for the keeper.
#93
Comments
We will fix it in future versions. |
lossFee
is simply added to the commonData
and not reimbursed to the keeper, leading to potential losses for the keeper.lossFee
is simply added to the commonData
and not reimbursed to the keeper, leading to potential losses for the keeper.
Escalate |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
I believe my finding regarding the
In conclusion, the absence of documentation about this issue, combined with the acknowledgment that a future function is needed to address it, strongly supports the validity of my finding. It is essential to recognize this as a medium-level issue to ensure that it is appropriately addressed in the protocol's current and future implementations. |
This should be considered as low severity issue. I hope I answered your concerns @Nikhil8400. |
By this logic mentioned here, any potential issues can be upgraded via the diamond proxy pattern to resolve issue. So I believe this is still a valid medium severity issue. |
That logic here is related to the recovery of the issue, meaning that issue is reversible without causing any impact as mentioned by @Hash01011122 . The main point here is that, loss fees are still correctly accounted for in Diamond's storage. Hence, I believe this issue does not qualify for medium severity. |
Firstly, we have to remember that historical decisions are not sources of truth. Secondly, I believe the design decision rule doesn't apply here. Not due to the reason this issue is not mentioned as a design decision, but because it leads to a loss of funds. Thirdly, the argument that the upgradeability could resolve this issue decreases the severity, but I disagree it makes the issue low. I agree with the Lead Judge that medium severity is indeed appropriate here. Planning to reject the escalation and leave the issue as it is. |
How do we possibly know that maybe a contract OOS has a function to withdraw the funds? |
But ser elfi team has admitted this issue in above comments and stated that they are going to fix this in future version link |
If there's concrete evidence there's such a function, please provide it. Otherwise, the decision remains the same, planning to reject the escalation and leave the issue as it is. |
We assumed a lot of stuff in this contest. For example settling the unsettled fees are also not in the code, they are probably in a OOS code. Would that mean if I would've submit unsettled fees can't be settled because there is no functionality would be a valid issue? "If there's concrete evidence there's such a function, please provide it" I would rather not do that because why would I be checking OOS code... |
Fair point, but in this case we also have a confirming this issue is correct. Of course, I don't say the sponsor confirming the bug or adding labels affects the validity or severity of the issue, but I believe this comment indeed confirms there is no function to withdraw funds. Hence, the decision remains the same, planning to reject the escalation and leave the issue as it is. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
nikhil840096
High
The
lossFee
is simply added to thecommonData
and not reimbursed to the keeper, leading to potential losses for the keeper.Summary
The
lossFee
is simply added to thecommonData
and not reimbursed to the keeper, leading to potential losses for the keeper.Vulnerability Detail
The processExecutionFee function is designed to calculate and handle the execution fee required by the keeper and ensure that this fee is appropriately managed between the user and the keeper. The function also addresses scenarios where the actual gas cost exceeds or falls below the user's provided execution fee. Below is the implementation of the function:
https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/main/elfi-perp-contracts/contracts/process/GasProcess.sol#L17-L41
Execution Fee Calculation:
Fee Adjustments:
https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/main/elfi-perp-contracts/contracts/process/GasProcess.sol#L22-L27
Transfer and Withdrawal Mechanisms:
https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/main/elfi-perp-contracts/contracts/process/GasProcess.sol#L28-L34
Handling Loss Fees:
as it could lead to unrecovered costs for the keeper.
https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/main/elfi-perp-contracts/contracts/process/GasProcess.sol#L38-L40
Issue:
The lossFee is simply added to the common data pool and not reimbursed to the keeper, leading to potential losses for the keeper.
Impact
Code Snippet
https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/main/elfi-perp-contracts/contracts/process/GasProcess.sol#L17-L41
Tool used
Manual Review
Recommendation
Implement a function to incentivize the keepers for there loss in execution fee.
The text was updated successfully, but these errors were encountered: