Tadle

Summary

The TokenManager.sol contract was audited to identify potential security vulnerabilities and ensure the robustness of the code. The contract is responsible for managing token transfers, withdrawals, and maintaining a whitelist of tokens. The audit focused on common smart contract vulnerabilities, including reentrancy, improper authorization, unchecked external calls, and faulty logic.

Vulnerability Details

1. Reentrancy Attack Risk

   • Description: The withdraw function in TokenManager.sol allows for transferring tokens back to the user. However, since external calls are made before the internal state is updated, this function is susceptible to a reentrancy attack. An attacker could exploit this vulnerability to repeatedly call the withdraw function within a single transaction, draining the contract's funds.

   • Location:

     • withdraw function:

       _safe_transfer_from(_tokenAddress, capitalPoolAddr, _msgSender(), claimAbleAmount);

     • This transfer call can be exploited by a reentrancy attack before the internal state is updated.

   • Severity: Critical

2. Improper Authorization in tillIn Function

   • Description: The tillIn function allows transfers to the capital pool from the msg.sender. The function relies on onlyRelatedContracts for access control, but if the related contract or tadleFactory is compromised or poorly implemented, unauthorized access might occur, leading to unexpected behavior or loss of funds.

   • Location:

     • tillIn function:

       onlyRelatedContracts(tadleFactory, _msgSender())

   • Severity: High

3. Unchecked External Calls

   • Description: The contract makes external calls to other contracts (e.g., capital pool, wrapped native token) without proper error handling or checks. This might lead to unexpected behavior if the called contract fails or returns an error.

   • Location:

     • Calls to ICapitalPool, IWrappedNativeToken, and other contracts in tillIn, withdraw, and _transfer functions.

   • Severity: Medium

Impact

1. Reentrancy Attack Risk:

   • A successful reentrancy attack could allow an attacker to drain the contract's funds by repeatedly invoking the withdraw function before the internal state is updated. This could lead to a complete loss of all funds held in the contract.

2. Improper Authorization in tillIn Function:

   • If unauthorized entities gain access to the tillIn function, they could manipulate token transfers, potentially leading to fund loss or misallocation within the system.

3. Unchecked External Calls:

   • Failure to properly handle errors or unexpected behavior from external calls might cause the contract to behave unpredictably, potentially leading to fund losses or denial of service.

Tools Used

• Static Analysis: Tools like Slither and Mythril were used to perform a static analysis of the contract code, identifying potential vulnerabilities.

• Manual Review: The contract code was manually reviewed to identify logical errors, security vulnerabilities, and areas that require optimization.

• Test Cases: Unit tests were conducted to simulate potential attack scenarios, including reentrancy attacks, improper access, and faulty external calls.

Recommendations

1. Implement ReentrancyGuard:

   • To mitigate the reentrancy attack risk, use OpenZeppelin's ReentrancyGuard modifier on functions that make external calls, especially the withdraw function.

   • Example:

   • function withdraw( address _tokenAddress, TokenBalanceType _tokenBalanceType ) external nonReentrant whenNotPaused { // existing code... }

2. Enhance Access Control:

   • Strengthen the access control mechanism in the tillIn function by implementing more rigorous checks and validations for related contracts. Consider multi-signature (multi-sig) authorization for critical functions.

3. Add Error Handling for External Calls:

   • Ensure that all external calls, especially those involving token transfers or interactions with other contracts, have proper error handling to prevent unexpected failures or revert situations.

4. Regular Audits and Testing:

   • Regularly audit the contract and conduct extensive testing, especially after making any updates or integrating new features, to ensure ongoing security and reliability.