Contract fails to deliver promised returns, but doesn't lose value
Description
Brief/Intro
While allocating deposits into the Stargate strategy, the implementation removes the dust amount from the provided deposit value and only deposits the remaining amount into the strategy.However, the vault still records the full provided amount (including the removed dust) in the allocation caps mapping.
As a result, the stored allocation value becomes inaccurate, leading to a situation where the system incorrectly reports that the allocation cap has been reached even though the actual deposited amount is lower.
Vulnerability Details
To understand this behavior, let’s first examine the Vault’s allocation flow: allocate -> allocateInternal
At line 571, the value stored in change is added to caps.allocation.
Now, let’s take a closer look at the Stargate strategy:
Here we can observe that at line 47, the dust is subtracted from the provided amount before depositing into the strategy, while at line 52, the function returns the original amount (including the dust).
By combining both code snippets, we can summarize the behavior as follows:
Admin allocates:3999999999999999996
After removing dust:3999999000000000000
The _allocate function still returns 3999999999999999996, and the vault records caps.allocation = 3999999999999999996.
Even after a full deallocation, the vault still shows caps.allocation = 999999999996, which corresponds exactly to the dust amount stored in step 3.
Impact Details
Due to incorrect caps.allocation calculation, the vault reports inaccurate cap values, which can cause unexpected reverts and potential DoS during allocation.