Liquid Staking

Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Submission Details
Severity: medium
Invalid

contracts/core/test/SDLPoolCCIPControllerMock.sol

The provided Solidity code is a smart contract that implements a mock controller for handling outgoing and incoming tokens in an SDL (Stable Distributed Ledger) pool. Here’s a review of potential vulnerabilities and issues:

1. Lack of Access Control on setRESDLTokenBridge Function

  • The setRESDLTokenBridge function allows anyone to set the reSDLTokenBridge address. This could lead to unauthorized users changing the bridge address, potentially leading to loss of tokens or unauthorized actions.

    Recommendation: Add an access control mechanism (like onlyOwner or onlyAdmin) to restrict who can call this function.

2. Missing Input Validation

  • The function handleIncomingRESDL does not validate the _tokenId or the _reSDLToken input. Invalid or unexpected values could lead to unintended behaviors.

    Recommendation: Implement input validation to ensure the integrity of the data being processed.

3. Unchecked External Calls

  • The contract calls the handleOutgoingRESDL and handleIncomingRESDL methods on the sdlPool contract, which are external calls. If these functions fail (for example, due to a require statement failing), it will revert, but there could still be a scenario where a failure can lead to unintended states or token lockups.

    Recommendation: Use proper error handling and ensure the sdlPool contract is secure and well-tested.

4. Reentrancy Risk

  • While there are no direct external calls made before state changes in this contract, it is good practice to consider potential reentrancy attacks, especially if sdlPool uses external calls that could be vulnerable.

    Recommendation: Consider implementing a reentrancy guard, especially if functions in sdlPool could call back into this contract.

5. Incorrect Handling of Token Transfers

  • In handleIncomingRESDL, the contract calls safeTransferFrom from sdlToken, assuming that reSDLTokenBridge is a valid and approved spender. If reSDLTokenBridge is not approved to spend tokens on behalf of the caller, the transfer will fail.

    Recommendation: Ensure that reSDLTokenBridge is correctly set up with the appropriate allowances, or handle the transfer in a way that verifies the allowance.

6. Potential for Uncontrolled Token Minting/Distribution

  • The distributeRewards function increments rewardsDistributed without any logic to actually distribute rewards, which could create confusion. This function could lead to a situation where it appears rewards are distributed without any actual token transfer or logic implemented.

    Recommendation: Implement actual reward distribution logic or remove the function if it serves no purpose.

7. Event Emissions

  • The contract does not emit events for critical actions such as setting the bridge address or distributing rewards. This could lead to difficulties in tracking actions on the blockchain.

    Recommendation: Add events to log key actions like setting the bridge address and distributing rewards.

Conclusion

Addressing the above issues can enhance the security and functionality of the contract. Implementing best practices around access control, input validation, and error handling is crucial for building robust smart contracts.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Lack of quality

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.