Tadle

Summary

The current implementation of the _depositTokenWhenCreateTaker function and its associated calculations could result in a user-unfriendly experience. Fees are added to the user’s deposit amount instead of being deducted from it. This design might lead to unexpected transaction failures if the user’s approval or balance doesn’t cover the total amount, including fees. Typically, fees are deducted from the deposit amount, so this approach could make the system cumbersome and confusing for users.

Vulnerability Details

In the createTaker function, tokens are transferred to a capital pool based on a specified deposit amount. The function calculates a platformFee and a tradeTax, which are then added to the deposit amount to determine the total transferAmount in the internal helper function _depositTokenWhenCreateTaker.

Expected Behavior

The user should be able to deposit a specific amount and cover all associated fees, or be clearly informed of the total required amount including fees.

Actual Behavior

The implementation adds the platformFee and tradeTax to the user’s deposit amount. If a user has only 100$ and intends to deposit these $100 but the total including fees amounts to $115 for example, the system will attempt to transfer $115. If the user only approved $100, this will cause the transaction to revert.

This can lead to:

• Unexpected Reversions: Transactions failing if the total amount exceeds the user’s approval or balance.

• User Confusion & Poor User Experience: Users may be aware of various fees in Tadle and expect them to be deducted from their deposit amount, as is typically the case. However, they might be unaware of this implementation. They could expect to deposit $100 and have all fees deducted from that amount, but instead, the system will add the fees to the deposit. This can lead to confusion and a poor user experience, as users might incur gas fees without achieving their intended result due to transaction reversion from insufficient approvals or insufficient balances. Additionally, users always will need to manually calculate the exact deposit amount to cover both the desired deposit and the fees which is very cumbersome experience for them.

Impact

1. Unexpected Transaction Failures: Users might experience transaction reverts if their approval or balance is insufficient to cover the total amount including fees. This could result in failed transactions and a confusing experience.

2. Poor User Experience: Users may not anticipate the total amount needed, leading to frustration and potential loss of trust in the system. The system's usability could be significantly impacted if users face frequent issues with transactions failing due to fee-related mismatches.

3. Inconsistent Fee Handling: The current approach of adding fees rather than deducting them from the user’s deposit can lead to inconsistencies in how fees are handled, which can make the system less intuitive and harder to use.

Tools Used

VSCode

Recommendations

Deduct fees upfront - adjust the deposit amount to account for fees before transferring the amount to the capital pool.