-
Notifications
You must be signed in to change notification settings - Fork 4
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
santipu_ - DoS on deposits when a low savings amount is harvested #19
Comments
Escalate. This issue deserves Low severity and not Medium. In the context in the uint256 assets = Math.min(
memMarket.convertToAssets(memMarket.allowance(memProvider, address(this))),
memMarket.maxWithdraw(memProvider)
);
uint256 amount = assets.mulWadDown(providerRatio);
IERC20 providerAsset = IERC20(address(memMarket.asset()));
uint256 duration = rewards[providerAsset].duration;
if (duration == 0 || amount < rewards[providerAsset].duration) return;
memMarket.withdraw(assets, address(this), memProvider);
uint256 save = assets - amount;
if (save != 0) memMarket.deposit(save, savings); The The smaller value that Therefore, the smaller value that the Summing up, there is already an existing check to prevent the described situation in this report which makes this issue Low/Invalid. However, the recommendation of code changes must be done in order to prevent unexpected situations. |
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. |
The escalation is missing the fact that the values for
When the value of |
I understand your point of view, however, I don't think we can consider issues that depend on administrators setting parameters with nonsensical values. Doing the math again with shorter periods and a really high
Still in the case the configuration makes |
I agree with the escalation. The issue is dependent on admin values and as I understand, with a specific set of values this issue can never happen or the admin can change both duration and provider ratio to mitigate the DOS. Additionally, it requires a high exchange rate on a not active pool, which seems odd, I understand this may be possible and I'm mistaken here, but still, the admin can mitigate the issue within 7 days. Planning to accept the escalation and invalidate the issue. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
The protocol team fixed this issue in the following PRs/commits: |
The Lead Senior Watson signed off on the fix. |
santipu_
Medium
DoS on deposits when a low savings amount is harvested
Summary
The missing check in
StakedEXA::harvest
will cause a DoS for new depositors as the function will revert whenever the amount deposited back into the market (savings) is low enough to not mint any share.Root Cause
In
StakedEXA:358
there is a missing check that will cause a DoS for new depositors whenever the amount deposited back into the market (savings) is low enough to not mint any share.https://github.com/sherlock-audit/2024-07-exactly-stacking-contracts/blob/main/protocol/contracts/StakedEXA.sol#L358
Internal pre-conditions
save
amount calculated inharvest
must be low enough to not mint any share when deposited back into the market. When the market has been active for some time, it's usual that the exchange rate is quite high, causing a deposit of a few wei not to mint any share at all.External pre-conditions
harvest
directly depends on the treasury fees accrued on the underlying market. For this DoS to be persistent, themarket
specified inStakedEXA
must have low activity so that the treasury fees accrued are a low amount.Attack Path
deposit
ormint
to stake EXA tokens.deposit
ormint
function calls the internal_update
function before minting the actual shares._update
function callsharvest
to distribute the dividends from the provider market.harvest
function withdraws from the market all funds from the treasury address (provider
).save
amount is calculated based on theproviderRatio
and that amount of tokens are deposited back into the market.save
amount is low enough, the shares minted in the market will be 0, causing a revert on this line.As long as the provider market is quite inactive and the treasury fees accrued are a low amount, the
harvest
function will revert every time causing a DoS on all deposits inStakedEXA
. If the activity in the market stays low for quite some time, the DoS can be extended to more than 7 days, making this issue valid given that staking is a core protocol functionality.Impact
All stakers will experience a DoS on new deposits within the
StakedEXA
contract.PoC
No response
Mitigation
To mitigate this issue is recommended to check within the
harvest
function if the amount to deposit back into the market will mint any share at all:The text was updated successfully, but these errors were encountered: