The provided Solidity code represents a contract named BridgeRouterFacet which seems to be a part of a larger system dealing with bridging assets. The contract has several functions that interact with external contracts, manage deposits, withdrawals, and perform various calculations. While the code uses some protective measures like the nonReentrant modifier, there are potential vulnerabilities and areas of concern that need to be addressed.
External Calls with State-Changing Operations After the Call:
Several functions make external calls to the IBridge interface and then proceed to change the state. This pattern is susceptible to reentrancy attacks.
Unchecked Return Values:
The return values of external calls to IBridge functions are not checked. If these functions revert or fail silently, the contract might behave unexpectedly.
Assumption on ETH to ZETH Conversion:
In the depositEth function, there's an assumption that 1 ETH = 1 ZETH. This might not always be the case.
Potential for Lost Funds:
In the withdrawTapp function, there's a subtraction operation on ethEscrowed without checking if the result would be negative.
Access Control:
The onlyDAO modifier is used for the withdrawTapp function. It's essential to ensure that the implementation of this modifier correctly restricts access.
Magic Numbers:
Constants like Constants.MIN_DEPOSIT are used without context.
Potential for Front-Running:
Functions like deposit can potentially be front-run by malicious actors.
Reentrancy Attack: Malicious actors could exploit the reentrancy vulnerability to withdraw more funds than they should.
Unexpected Behavior: Not checking the return values of external calls can lead to unexpected contract behavior.
Loss of Funds: Incorrect assumptions or calculations can lead to loss of funds for users or the contract itself.
Unauthorized Access: If the onlyDAO modifier is not correctly implemented, unauthorized entities might access restricted functions.
Manual Code Review: The code was manually reviewed line-by-line to identify potential vulnerabilities and areas of concern.
ReentrancyGuard: Ensure that the nonReentrant modifier is correctly implemented to prevent reentrancy attacks.
Check Effects Interaction Pattern: Ensure that state changes are made before external calls to prevent potential reentrancy attacks.
Check Return Values: Always check the return values of external calls to ensure they executed successfully.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.