Zaros Part 1

Summary

The deposit margin function may encounter inconsistencies if the deposit cap is altered between the validation and the actual deposit operation, especially in highly concurrent environments.

Vulnerability Details

Description:

The depositMargin function validates the deposit amount against a deposit cap before performing the actual deposit. However, if the deposit cap changes due to external factors after validation but before the deposit, it could result in inconsistencies or failures.

Root Cause:

The deposit cap and the amount deposited are checked and updated in separate steps without ensuring atomicity. In highly concurrent environments, another transaction might modify the deposit cap or total deposited amount between these operations.

Proof of Concept:

Consider the following scenario:

Initial State:

Deposit cap: 1000 tokens

Total deposited: 900 tokens

User A attempts to deposit 50 tokens.

Steps in depositMargin for User A:

Validation: 900 (total deposited) + 50 (amount) <= 1000 (deposit cap) passes.

Before the deposit, another transaction lowers the deposit cap to 920 tokens.

Result:

User A's deposit attempt fails because 900 + 50 > 920.

Impact

• Inconsistencies: The function might deposit more collateral than allowed if the cap is lowered between validation and deposit.

• Failures: If the cap is lowered after validation, the actual deposit might fail or revert, causing user frustration and potential system reliability issues.

Tools Used

Manual Review

Recommendations

To prevent inconsistencies due to deposit cap changes, atomic operations should be used. Here’s a modified version of depositMargin with atomic checks and updates